docs: fix small typos found in .md files

CONTRIBUTING.md

@@ -31,7 +31,7 @@ Bug and security fixes are _always_ welcome and take the highest priority, see o
 - Base commits on top of latest `pre-draft` branch
 
 ### Signing the CLA for Contributions to the Specification
-If you have not yet signed the Individual CLA, or your organization has not yet signed the Corporate CLA, or if your account has not yet been authorized by your organization to contribute to Margo, the [LFX EasyCLA bot](https://easycla.lfx.linuxfoundation.org/#/) will prompt you to follow the appriopriate steps to authorize your contribution. 
+If you have not yet signed the Individual CLA, or your organization has not yet signed the Corporate CLA, or if your account has not yet been authorized by your organization to contribute to Margo, the [LFX EasyCLA bot](https://easycla.lfx.linuxfoundation.org/#/) will prompt you to follow the appropriate steps to authorize your contribution. 
 
 To ensure your contribution is covered before you make a pull request or to sign the CLA, open a PR at https://github.com/margo/EasyCLA.
 

system-design/index.md

@@ -8,7 +8,7 @@ Find out more about the Margo initiative and how to become engaged at [margo.org
 
 > **Disclaimer**
 
-This is a commit *snapshot* rendering of the of work-in-progress Margo Specification draft from the repository [=@=reponame=@=](https://github.com/=@=reponame=@=), commit `=@=commit=@=`.
+This is a commit *snapshot* rendering of the work-in-progress Margo Specification draft from the repository [=@=reponame=@=](https://github.com/=@=reponame=@=), commit `=@=commit=@=`.
 
 Do not attempt to implement this version of the Specification or reference this version as authoritative in any way!
 

system-design/specification/margo-management-interface/deployment-status.md

@@ -46,15 +46,15 @@ POST /api/v1/clients/{clientId}/deployments/{deploymentId}/status
 | Fields      | Type            | Required?       | Description     |
 |-----------------|-----------------|-----------------|-----------------|
 | state      | string    | Y    | Current state of the overall deployment. The state value MUST be one the following options: pending, installing, installed, removing, removed, failed. The overall deployment status MUST reflect the most severe of the components states, following this precedence: failed > removing > installing > pending > removing > installed.|
-| error      | Error    | N    | Element that defines the overall installation error if one occured. See the [Error Attributes](#error-attributes) section below.|
+| error      | Error    | N    | Element that defines the overall installation error if one occurred. See the [Error Attributes](#error-attributes) section below.|
 
 #### Component Attributes
 
 | Attribute       | Type            | Required?       | Description     |
 |-----------------|-----------------|-----------------|-----------------|
 | name      | string    | Y    | Name of the deployment component, inherited via the deployment specification |
 | state     | string    | Y    | The component's current deployment state of the component. MUST be one of the following options: pending, installing, installed, removing, removed, failed |
-| error     | Error    | N    | Element that defines the components installation error if one occured. See the [Error Attributes](#error-attributes) section below.  |
+| error     | Error    | N    | Element that defines the components installation error if one occurred. See the [Error Attributes](#error-attributes) section below.  |
 
 > Note: The components array MUST contain one entry for each "component" defined in the referenced ApplicationDeployment manifest. 
 
@@ -66,7 +66,7 @@ POST /api/v1/clients/{clientId}/deployments/{deploymentId}/status
 | source    | string    | Y    | Identifies the source of the error. It is set to the device id, with its full hierarchy if applicable, of the device generating the error, or to the component name of the component generating the error. |
 | message   | string    | Y    | Associated error message that provides further details to the WFM about the error that was encountered. |
 
-When the error is generated by a see-thru [gateway](../../concepts/gateways/gateways.md), the source attribute of the error structure MUST be set to the gateway device id, with its full hierachy if applicable.
+When the error is generated by a see-thru [gateway](../../concepts/gateways/gateways.md), the source attribute of the error structure MUST be set to the gateway device id, with its full hierarchy if applicable.
 
 When the error is not generated by a see-thru gateway, the source of the `status.error` attribute MUST be set to the name of the deployment as defined in the `metadata.name` attribute of the application deployment manifest. 
 
@@ -82,7 +82,7 @@ When the error is not generated by a see-thru gateway, the source of the `compon
 | 102        | Child device unreachable | Id of the gateway | The gateway cannot establish a connection with the child device. |
 | 103        | Autonomous placement not supported | Id of the gateway | The gateway is not capable of autonomously selecting the child-device for the deployment. |
 
-When the error used is a reserved code for a gateway-generated error, the `source` attribute MUST be set to the id of the gateway, with its full hierachy if applicable.
+When the error used is a reserved code for a gateway-generated error, the `source` attribute MUST be set to the id of the gateway, with its full hierarchy if applicable.
 
 ## Example Deployment Status Manifest Request
 

system-design/specification/margo-management-interface/device-client-onboarding.md

@@ -5,7 +5,7 @@ In order for the Workload Fleet Management software to manage the edge device's
 
 ## Onboarding Sequence
 
-- The end user provides the the Workload Fleet Management web service's root URL to the device's management client
+- The end user provides the Workload Fleet Management web service's root URL to the device's management client
 - The device's management client downloads the Workload Fleet Manager's public root CA certificate using the [Certificate API](../../specification/margo-management-interface/certificate-api.md)
 - Context and trust is established between the device's management client and the Workload Fleet Management web service
 - The device's management client uses the [Onboarding API](../../specification/margo-management-interface/device-client-onboarding.md) to onboard with the Workload Fleet Management service by providing its X.509 certificate

system-design/specification/observability/publishing-workload-observability-data.md

@@ -10,6 +10,6 @@ Workload suppliers SHOULD NOT expect their workloads to be auto-instrumented by
 
 A workload supplier MAY choose an observability framework other than OpenTelemetry but it MUST be self-contained within the deployment of their workload. If an alternative approach is taken, it is NOT recommended workload suppliers publish their observability data outside the device by using any other means other than the Open Telemetry collector. If the workload supplier chooses to export data without using the OpenTelemetry collector they MUST NOT do this without the end user's approval.
 
-> **Note:** See the [workload observability overview](../../overview/workload-observability.md) page for more information about workload observablity.
+> **Note:** See the [workload observability overview](../../overview/workload-observability.md) page for more information about workload observability.
 >
 > **Action:** We may need to address in some form legacy workloads that are not currently using open telemetry and don't want to migrate their workload to use it.