diff --git a/docs/samples/configuration/context-based/README.md b/docs/samples/configuration/context-based/README.md
index bda98d824..2ae3f3285 100644
--- a/docs/samples/configuration/context-based/README.md
+++ b/docs/samples/configuration/context-based/README.md
@@ -10,7 +10,7 @@ There are two different line configurations, the scope of the instance determine
 
 [Symphony property expressions](../../../symphony-book/concepts/unified-object-model/property-expressions.md#functions) allow for retrieval of the evaluation context.  
 
-1. Define the configurations, using a name that will be part of the instance scope.  See [line1](./catalogs/line1.yml) and [line2](.catalogs/line2.yml).
+1. Define the configurations, using a name that will be part of the instance scope.  See [line1](./catalogs/line1.yml) and [line2](./catalogs/line2.yml).
 
 1. Set a scope on the instances.  See [instance-line1](./instances/instance-line1.yml) and [instance-line2](./instances/instance-line2.yml).
 
diff --git a/docs/samples/k8s/e2e/docs/build-local-recognition-container.md b/docs/samples/k8s/e2e/docs/build-local-recognition-container.md
index 25d3ae1ab..537bad3ac 100644
--- a/docs/samples/k8s/e2e/docs/build-local-recognition-container.md
+++ b/docs/samples/k8s/e2e/docs/build-local-recognition-container.md
@@ -1,5 +1,5 @@
 # Building Local Face Recognition Container
-The local recognition container is based on [DeepStack](https://www.deepstack.cc/). This document explains how the local face recognition container is built. 
+The local recognition container is based on [DeepStack](hhttps://deepstack.readthedocs.io/en/latest/index.html). This document explains how the local face recognition container is built. 
 > **NOTE**: To set up demo environment, you can use a pre-built Docker image: ```hbai/face-detection```.
 
 ## Setting up build environment
diff --git a/docs/symphony-book/api/_overview.md b/docs/symphony-book/api/_overview.md
index a5ab04f5a..e4417d542 100644
--- a/docs/symphony-book/api/_overview.md
+++ b/docs/symphony-book/api/_overview.md
@@ -14,4 +14,4 @@ For more details, see:
 * [Solutions API](./solutions-api.md)
 * [Targets API](./targets-api.md)
 
-You can find an Open API definition of Symphony API in [Sypmhony.openapi.yaml](./Symphony.openapi.yaml).
+You can find an Open API definition of Symphony API in [symphony-api-openapi.yaml](./symphony-api-openapi.yaml).
diff --git a/docs/symphony-book/api/api.md b/docs/symphony-book/api/api.md
index 83f2fc49a..644333423 100644
--- a/docs/symphony-book/api/api.md
+++ b/docs/symphony-book/api/api.md
@@ -15,4 +15,4 @@ For more details, see:
 * [Targets API](./targets-api.md)
 * [Solution Containers API](./solutioncontainers-api.md)
 
-You can find an Open API definition of Symphony API in [Sypmhony.openapi.yaml](./Symphony.openapi.yaml).
+You can find an Open API definition of Symphony API in [symphony-api-openapi.yaml](./symphony-api-openapi.yaml).
diff --git a/docs/symphony-book/api/targets-api.md b/docs/symphony-book/api/targets-api.md
index 512e41558..a66bc3c63 100644
--- a/docs/symphony-book/api/targets-api.md
+++ b/docs/symphony-book/api/targets-api.md
@@ -68,7 +68,7 @@
   |Parameter| Value|
   |--------|--------|
   | `{target name}` | name of the target |
-  | `[<with-binding>]` | (option) add a [role binding](../concepts/unified-object-model/target.md#role-bindings). Currently supported binding is `staging`, which binds container operations to a [staging provider](../providers/staging_provider.md)|
+  | `[<with-binding>]` | (option) add a [role binding](../concepts/unified-object-model/target.md#role-bindings). Currently supported binding is `staging`, which binds container operations to a [staging provider](../providers/target-providers/staging_provider.md)|
 
 * **Headers:**
 
diff --git a/docs/symphony-book/build_deployment/apim.md b/docs/symphony-book/build_deployment/apim.md
index 43a1bace4..32cfd806d 100644
--- a/docs/symphony-book/build_deployment/apim.md
+++ b/docs/symphony-book/build_deployment/apim.md
@@ -2,4 +2,4 @@
 
 It may be preferable to deploy Symphony API behind an [API Management Service](https://azure.microsoft.com/products/api-management) for static IP and domain names, automatic certificate binding, and monitoring.
 
-You can use the [OpenAPI V3 Yaml](../api/Symphony.openapi.yaml) to help you to create APIM configuration.
+You can use the [OpenAPI V3 Yaml](../api/symphony-api-openapi.yaml) to help you to create APIM configuration.
diff --git a/docs/symphony-book/build_deployment/deploy.md b/docs/symphony-book/build_deployment/deploy.md
index d509c21c8..7e680b70d 100644
--- a/docs/symphony-book/build_deployment/deploy.md
+++ b/docs/symphony-book/build_deployment/deploy.md
@@ -34,7 +34,7 @@ Symphony's [job manager](../managers/_overview.md) invokes Symphony's reconcile
 
 ### State stores
 
-Most Symphony components are stateless, with exception of the [instance manager](../managers/instance-manager.md). The instance manager uses a state store to remember the last deployment it has successfully applied. When you have multiple instance managers running (by scaling out the solution vendor), they need to use a shared state store instead of the in-memory state store.
+Most Symphony components are stateless, with exception of the [instance manager](../managers/_overview.md). The instance manager uses a state store to remember the last deployment it has successfully applied. When you have multiple instance managers running (by scaling out the solution vendor), they need to use a shared state store instead of the in-memory state store.
 
 In addition to the default in-memory store (which doesn't scale beyond a single process), Symphony also supports an HTTP-proxy store through which you can connect to [most of the popular databases](https://docs.dapr.io/reference/components-reference/supported-state-stores/) via [Dapr](https://dapr.io/).
 
diff --git a/docs/symphony-book/build_deployment/microk8s.md b/docs/symphony-book/build_deployment/microk8s.md
index 5e6eaaf78..ef6819452 100644
--- a/docs/symphony-book/build_deployment/microk8s.md
+++ b/docs/symphony-book/build_deployment/microk8s.md
@@ -40,7 +40,7 @@ If you're running these steps on a Mac device, skip ahead to the [MacBook](#macb
    microk8s.start
    ```
 
-> **NOTE:** See instructions [here](https://ubuntu.com/tutorials/install-microk8s-on-windows#2-installation) to install MicroK8s on Windows.
+> **NOTE:** See instructions [here](https://microk8s.io/docs/install-windows) to install MicroK8s on Windows.
 
 ### 2. Install crictl (optional - for Akri)
 
diff --git a/docs/symphony-book/build_deployment/windows_agent.md b/docs/symphony-book/build_deployment/windows_agent.md
index b446a611a..43e730061 100644
--- a/docs/symphony-book/build_deployment/windows_agent.md
+++ b/docs/symphony-book/build_deployment/windows_agent.md
@@ -1,3 +1,3 @@
 TODO: Document instructions to configure a Windows-based Symphony agent
 
-related content: [Sideload apps provider for Windows 10 and XBOX](../providers/win10_sideload_provider.md)
\ No newline at end of file
+related content: [Sideload apps provider for Windows 10 and XBOX](../providers/target-providers/win10_sideload_provider.md)
\ No newline at end of file
diff --git a/docs/symphony-book/concepts/unified-object-model/property-expressions.md b/docs/symphony-book/concepts/unified-object-model/property-expressions.md
index fcfaddaf8..7c568d362 100644
--- a/docs/symphony-book/concepts/unified-object-model/property-expressions.md
+++ b/docs/symphony-book/concepts/unified-object-model/property-expressions.md
@@ -1,6 +1,6 @@
 # Property expressions
 
-Symphony solution [components](./solution.md#componentspec) and campaign stages can use property expressions in their property values, wrapped in `${{}}`. Property expressions are evaluated at the solution [vendor](../vendors/_overview.md) level, which means that they are evaluated immediately once they arrive at the Symphony API surface. Hence, none of the [managers](../managers/_overview.md) or [providers](../providers/_overview.md) need to worry about (or be aware of) the expression rules. When authoring Symphony artifacts, a user can use these expressions in their solution documents.
+Symphony solution [components](./solution.md#componentspec-schema) and campaign stages can use property expressions in their property values, wrapped in `${{}}`. Property expressions are evaluated at the solution [vendor](../../vendors/_overview.md) level, which means that they are evaluated immediately once they arrive at the Symphony API surface. Hence, none of the [managers](../../managers/_overview.md) or [providers](../../providers/_overview.md) need to worry about (or be aware of) the expression rules. When authoring Symphony artifacts, a user can use these expressions in their solution documents.
 
 In general, Symphony attempts to parse the property values as strings whenever possible. Only when Symphony detects clear and valid arithmetical expressions and function calls will it try to evaluate them first before the string evaluation. This means that Symphony is mostly tolerable to syntax errors in expressions and will treat those as string literals. For example, `"10/2"` is interpreted as a division, while `"10/0"` is treated as a string because otherwise it's a divide-by-zero error.
 
diff --git a/docs/symphony-book/concepts/unified-object-model/solution.md b/docs/symphony-book/concepts/unified-object-model/solution.md
index a6aa4e2b4..51ef0a9c7 100644
--- a/docs/symphony-book/concepts/unified-object-model/solution.md
+++ b/docs/symphony-book/concepts/unified-object-model/solution.md
@@ -2,7 +2,7 @@
 
 You can assemble components from different artifact formats into an orchestrated application model using Symphony’s `solution` object.
 
-A [solution](../concepts/unified-object-model/solution.md) describes an application. It consists of a list of [components](../concepts/unified-object-model/solution.md#componentspec), which can be a container, a Helm chart, a Kubernetes artifact file, a security policy, a firmware, or anything else. Instead of forcing artifacts to adopt the Symphony [component](../concepts/unified-object-model/solution.md#componentspec) artifact format, Symphony allows existing application artifacts to be directly embedded into Symphony solutions.
+A [solution](../../concepts/unified-object-model/solution.md) describes an application. It consists of a list of [components](../../concepts/unified-object-model/solution.md#componentspec-schema), which can be a container, a Helm chart, a Kubernetes artifact file, a security policy, a firmware, or anything else. Instead of forcing artifacts to adopt the Symphony [component](../../concepts/unified-object-model/solution.md#componentspec-schema) artifact format, Symphony allows existing application artifacts to be directly embedded into Symphony solutions.
 
 When modeling a microservice application, components are assumed to be independent from each other. However, in many legacy applications there are implicit or explicit dependencies among components. Symphony allows you to attach optional dependencies to components to build up a dependency tree. When Symphony deploys the solution, it walks the dependency tree and ensures that components are deployed in the correct order.
 
@@ -30,7 +30,7 @@ Solution objects, `solution.solution.symphony`, define an intelligent edge solut
 
 ### Dependencies
 
-When Symphony deploys a solution, it sorts all solution components by their dependencies so that [providers](../providers/_overview.md) that allow ordering can apply the components in order.
+When Symphony deploys a solution, it sorts all solution components by their dependencies so that [providers](../../providers/_overview.md) that allow ordering can apply the components in order.
 
 Circular references are not allowed.
 
diff --git a/docs/symphony-book/concepts/unified-object-model/target.md b/docs/symphony-book/concepts/unified-object-model/target.md
index 7dc74568a..6f332e6a4 100644
--- a/docs/symphony-book/concepts/unified-object-model/target.md
+++ b/docs/symphony-book/concepts/unified-object-model/target.md
@@ -1,10 +1,10 @@
 # Target
 
-A `target` in Symphony is an endpoint to which Symphony `components` can be deployed. A target can be a server, a PC, a mobile device, a cluster, or any other endpoints that support the Symphony [provider interface](../../providers/provider_interface.md). When a target is registered, Symphony allows a full-stack description of all software components, policies, and configurations that are required on the target, and Symphony uses its state-seeking mechanism to make sure that the target is configured properly.
+A `target` in Symphony is an endpoint to which Symphony `components` can be deployed. A target can be a server, a PC, a mobile device, a cluster, or any other endpoints that support the Symphony [provider interface](../../providers/target-providers/provider_interface.md). When a target is registered, Symphony allows a full-stack description of all software components, policies, and configurations that are required on the target, and Symphony uses its state-seeking mechanism to make sure that the target is configured properly.
 
 ![target](../../images/target.png)
 
-Symphony ships a number of providers out-of-box to support various target types. Any symphony is extensible with either [native providers](../../providers/_overview.md#provider-types) (that come with Symphony builds), [script providers](../../providers/script_provider.md), or [standalone providers](../../providers/standalone_providers.md)
+Symphony ships a number of providers out-of-box to support various target types. Any symphony is extensible with either [native providers](../../providers/_overview.md#provider-types) (that come with Symphony builds), [script providers](../../providers/target-providers/script_provider.md), or [standalone providers](../../providers/standalone_providers.md)
 
 ## Components
 
diff --git a/docs/symphony-book/configuration-management/serve-configurations.md b/docs/symphony-book/configuration-management/serve-configurations.md
index bb8e2e7c7..4507139a0 100644
--- a/docs/symphony-book/configuration-management/serve-configurations.md
+++ b/docs/symphony-book/configuration-management/serve-configurations.md
@@ -75,7 +75,7 @@ GET /catalogs/registry/<id>?filterType=label&filterValue=app==my-app,shit==night
 ```
 > **NOTE:** Query parameters are not URL-encoded in the above sample for clarity. Your query parameters should be URL-encoded.
 
-See [state provider](../providers/state-providers/README.md) for more details on filters.
+See [state provider](../providers/state-providers/_overview.md) for more details on filters.
 
 ### Retrieve specific portions
 
diff --git a/docs/symphony-book/dev-guide/_overview.md b/docs/symphony-book/dev-guide/_overview.md
index 671acb8ca..6fd4ad1b1 100644
--- a/docs/symphony-book/dev-guide/_overview.md
+++ b/docs/symphony-book/dev-guide/_overview.md
@@ -31,7 +31,7 @@ The Symphony repo lacks automatic CI/CD pipelines, gated check-ins, and automate
 
 A common task of extending Symphony is to write or modify a [provider](../providers/_overview.md), especially a [target provider](../providers/target-providers/target_provider.md).
 
-A target provider implements the [target provider interface](../providers/provider_interface.md).
+A target provider implements the [target provider interface](../providers/target-providers/provider_interface.md).
 
 To create a new provider:
 
diff --git a/docs/symphony-book/get-started/deploy_prometheus_k8s.md b/docs/symphony-book/get-started/deploy_prometheus_k8s.md
index 1ae85f9b9..f255f17d4 100644
--- a/docs/symphony-book/get-started/deploy_prometheus_k8s.md
+++ b/docs/symphony-book/get-started/deploy_prometheus_k8s.md
@@ -58,7 +58,7 @@ spec:
         inCluster: "true"   
 ```
 
-The `inCluster` property is set to `true` because the resource is being created in the cluster where Symphony has been installed. For more information on the Kubernetes provider, see [providers.target.k8s](../providers/k8s_provider.md).
+The `inCluster` property is set to `true` because the resource is being created in the cluster where Symphony has been installed. For more information on the Kubernetes provider, see [providers.target.k8s](../providers/target-providers/k8s_provider.md).
 
 This YAML file is also available at [docs/samples/k8s/hello-world/target.yaml](../../samples/k8s/hello-world/target.yaml).
 
diff --git a/docs/symphony-book/hosts/_overview.md b/docs/symphony-book/hosts/_overview.md
index 30b983406..5f03052a0 100644
--- a/docs/symphony-book/hosts/_overview.md
+++ b/docs/symphony-book/hosts/_overview.md
@@ -63,4 +63,4 @@ docker run --rm -it  -v /configuration/file/path/on/host:/config -e CONFIG=/conf
 
 ## Scale out the host
 
-When you run multiple host instances behind a load balancer, and if you have [managers](../managers/overview.md) who use a state store, you need to choose a shared state store that is accessible by all instances. Symphony currently doesn't have a shared state store provider other than a HTTP state provider that can be configured together with sidecars like [Dapr](https://dapr.io/). It's expected some native shared state store provider (like Redis) will be added in future versions.
+When you run multiple host instances behind a load balancer, and if you have [managers](../managers/_overview.md) who use a state store, you need to choose a shared state store that is accessible by all instances. Symphony currently doesn't have a shared state store provider other than a HTTP state provider that can be configured together with sidecars like [Dapr](https://dapr.io/). It's expected some native shared state store provider (like Redis) will be added in future versions.
diff --git a/docs/symphony-book/providers/_overview.md b/docs/symphony-book/providers/_overview.md
index 2d612d4f0..ec4b5671c 100644
--- a/docs/symphony-book/providers/_overview.md
+++ b/docs/symphony-book/providers/_overview.md
@@ -9,7 +9,7 @@ Common provider types include:
 * Proxy, like [HTTP proxy](./http_proxy_provider.md) and [MQTT proxy](./mqtt_proxy_provider.md)
 * [Reference](./reference_provider.md)
 * [Target](./target-providers/target_provider.md)
-* [Staging](./staging_provider.md)
+* [Staging](./target-providers/staging_provider.md)
 * Certificate
 * Probe
 * Pub-Sub
diff --git a/docs/symphony-book/providers/http_proxy_provider.md b/docs/symphony-book/providers/http_proxy_provider.md
index d4755ab80..3f7609023 100644
--- a/docs/symphony-book/providers/http_proxy_provider.md
+++ b/docs/symphony-book/providers/http_proxy_provider.md
@@ -12,6 +12,5 @@ For example, you can proxy provider operations to a Windows machine, and your pr
 
 ## Related topics
 
-* [Provider interface](./provider_interface.md)
 * [Write a Python-based Provider](./python_provider.md)
 * [Scenario: Deploy a Linux container with a WUP frontend](../scenarios/linux-with-uwp-frontend.md)
diff --git a/docs/symphony-book/providers/mqtt_proxy_provider.md b/docs/symphony-book/providers/mqtt_proxy_provider.md
index 784bc3c08..a0d99d567 100644
--- a/docs/symphony-book/providers/mqtt_proxy_provider.md
+++ b/docs/symphony-book/providers/mqtt_proxy_provider.md
@@ -20,6 +20,5 @@ For example, you can proxy provider operations to a Windows machine, and your pr
 
 ## Related topics
 
-* [Provider interface](./provider_interface.md)
 * [Write a Python-based provider](./python_provider.md)
 * [Scenario: Deploy a Linux container with a WUP frontend](../scenarios/linux-with-uwp-frontend.md)
diff --git a/docs/symphony-book/providers/python_provider.md b/docs/symphony-book/providers/python_provider.md
index 7d816a76d..eafb98669 100644
--- a/docs/symphony-book/providers/python_provider.md
+++ b/docs/symphony-book/providers/python_provider.md
@@ -16,7 +16,7 @@ An out-of-process provider is expected to handle the following routes:
 | `/needsupdate` | GET | If an update is needed (returns `200`) or not (returns `500`) |
 | `/needsremove`| GET | if a deletion is needed (returns `200`) or not (returns `500`)|
 
-In the [provider interface](./provider_interface.md) definition, the `NeedsUpdate()` method and the `NeedsRemove()` method take two component arrays as parameters. In the REST interface, the two arrays are combined into a single JSON object:
+The `NeedsUpdate()` method and the `NeedsRemove()` method take two component arrays as parameters. In the REST interface, the two arrays are combined into a single JSON object:
 
 ```json
 {
diff --git a/docs/symphony-book/providers/target-providers/http_provider.md b/docs/symphony-book/providers/target-providers/http_provider.md
index 048098b56..4d5bdb1f9 100644
--- a/docs/symphony-book/providers/target-providers/http_provider.md
+++ b/docs/symphony-book/providers/target-providers/http_provider.md
@@ -13,7 +13,7 @@ Deployment is considered successful if the web hook returns a `200` response.
 | `Properties[http.body]` | HTTP body<sup>1</sup> |
 | `Properties[http.method]` | HTTP method, default is `POST` |
 
-1: You can use a few replacement functions in the body string, including `$instance()`, `$solution()` and `$target()`, which correspond to the current [Instance](../concepts/unified-object-model/instance.md) name, the current [Solution](../concepts/unified-object-model/solution.md) name and the current [Target](../concepts/unified-object-model/target.md) name.
+1: You can use a few replacement functions in the body string, including `$instance()`, `$solution()` and `$target()`, which correspond to the current [Instance](../../concepts/unified-object-model/instance.md) name, the current [Solution](../../concepts/unified-object-model/solution.md) name and the current [Target](../../concepts/unified-object-model/target.md) name.
 
 The HTTP provider can’t reconstruct the current state, so it always reports its current state as null when asked. This means that the http web hook will be periodically invoked (because the current state remains unknown). Hence, the corresponding web hook is required to be **idempotent** to avoid unwanted side effects.
 
diff --git a/docs/symphony-book/providers/target-providers/k8s_provider.md b/docs/symphony-book/providers/target-providers/k8s_provider.md
index 372a57c14..0f928b29f 100644
--- a/docs/symphony-book/providers/target-providers/k8s_provider.md
+++ b/docs/symphony-book/providers/target-providers/k8s_provider.md
@@ -14,7 +14,7 @@ The K8s target provider supports three deployment strategies:
 
 The K8s provider maps a **ComponentSpec** to a `Deployment.Spec.Template.Spec.Containers[i]` (referred to as `Container` in the following tables). When the single pod strategy is used, **InstanceSpec** metadata is mapped to K8s deployment attributes; for other cases, **ComponentSpec** metadata is used.
 
-![K8s Provider Single Pod Strategy](../images/k8s-provider-single-pod-strategy.png)
+![K8s Provider Single Pod Strategy](../../images/k8s-provider-single-pod-strategy.png)
 
 | Symphony instance object | K8s deployment |
 |--------|--------|
diff --git a/docs/symphony-book/providers/target-providers/script_provider.md b/docs/symphony-book/providers/target-providers/script_provider.md
index 6b08b08d9..046cac0ba 100644
--- a/docs/symphony-book/providers/target-providers/script_provider.md
+++ b/docs/symphony-book/providers/target-providers/script_provider.md
@@ -2,7 +2,7 @@
 
 _(last edit: 6/26/2023)_
 
-The script provider enables you to extend Symphony with scripts like Bash scripts and PowerShell scripts. Because Symphony's built-in providers are compiled into the Symphony binary, using a new provider needs a new Symphony version. Symphony [HTTP proxy provider](./http_proxy_provider.md) or Symphony [MQTT proxy provider](./mqtt_proxy_provider.md), on the other hand, allows a provider to be externalized as a sidecar. However, this requires you to host a web server that implements the provider REST API. The script provider offers the most flexibility without needing an extra sidecar.
+The script provider enables you to extend Symphony with scripts like Bash scripts and PowerShell scripts. Because Symphony's built-in providers are compiled into the Symphony binary, using a new provider needs a new Symphony version. Symphony [HTTP proxy provider](../http_proxy_provider.md) or Symphony [MQTT proxy provider](../mqtt_proxy_provider.md), on the other hand, allows a provider to be externalized as a sidecar. However, this requires you to host a web server that implements the provider REST API. The script provider offers the most flexibility without needing an extra sidecar.
 
 Symphony interacts with the script provider through a staging folder. For example, when Symphony deploys a solution instance, it writes the deployment spec to a file and passes the file name to the script as a parameter. The script is expected to pick up and process the file.
 
diff --git a/docs/symphony-book/providers/target-providers/staging_provider.md b/docs/symphony-book/providers/target-providers/staging_provider.md
index 1d9d6d351..e51cbf740 100644
--- a/docs/symphony-book/providers/target-providers/staging_provider.md
+++ b/docs/symphony-book/providers/target-providers/staging_provider.md
@@ -1,6 +1,6 @@
 # Staging provider
 
-Staging provider allows [components](../concepts/unified-object-model/solution.md#componentspec) to be recorded on an [Target](../concepts/unified-object-model/target.md) object without being deployed to the actual target. This allows components to be **staged** and retrieved later, such as by a polling agent. 
+Staging provider allows [components](../../concepts/unified-object-model/solution.md#componentspec-schema) to be recorded on an [Target](../../concepts/unified-object-model/target.md) object without being deployed to the actual target. This allows components to be **staged** and retrieved later, such as by a polling agent. 
 
 ## Provider configuration
 
diff --git a/docs/symphony-book/providers/target-providers/target_provider.md b/docs/symphony-book/providers/target-providers/target_provider.md
index 4b4fd039b..da00f918f 100644
--- a/docs/symphony-book/providers/target-providers/target_provider.md
+++ b/docs/symphony-book/providers/target-providers/target_provider.md
@@ -17,7 +17,7 @@ A target provider interacts with a specific system to carry out state seeking ac
 | `providers.target.kubectl`| Deploy K8s YAML docs using `kubectl` |
 | `providers.target.mock`| A mock provider to be used in manager unit tests |
 | `providers.target.mqtt`| Delegate state-seeking actions to a remote management plane over MQTT |
-| `providers.target.proxy`<sup>1</sup>| Delegate state-seeking actions to a remote management plane over HTTP or MQTT<br><br>[HTTP proxy provider](./http_proxy_provider.md)<br>[MQTT proxy provider](./mqtt_proxy_provider.md) |
+| `providers.target.proxy`<sup>1</sup>| Delegate state-seeking actions to a remote management plane over HTTP or MQTT<br><br>[HTTP proxy provider](../http_proxy_provider.md)<br>[MQTT proxy provider](../mqtt_proxy_provider.md) |
 | `providers.target.script`| Delegate state-seeking actions to external Bash/Powershell scripts<br><br>[Script provider](./script_provider.md) |
 | `providers.target.staging`| Stage solution component on the target objects<sup>2</sup>|
 | `providers.target.win10`| Sideload Windows apps using [WinAppDeployCmd](https://learn.microsoft.com/windows/uwp/packaging/install-universal-windows-apps-with-the-winappdeploycmd-tool). |
diff --git a/docs/symphony-book/providers/target-providers/win10_sideload_provider.md b/docs/symphony-book/providers/target-providers/win10_sideload_provider.md
index d5f7ab6c6..25f485e1b 100644
--- a/docs/symphony-book/providers/target-providers/win10_sideload_provider.md
+++ b/docs/symphony-book/providers/target-providers/win10_sideload_provider.md
@@ -55,4 +55,4 @@ You also need to import the application signing certificate. Please contact your
 
 ## Create Symphony target
 
-Because Symphony control plane usually runs on a Linux-based Kubernetes cluster, it uses a proxy provider to talk to the Windows-based Symphony agent you just configured. For more information, see [HTTP proxy provider](./http_proxy_provider.md) or [MQTT proxy provider](./mqtt_proxy_provider.md)
+Because Symphony control plane usually runs on a Linux-based Kubernetes cluster, it uses a proxy provider to talk to the Windows-based Symphony agent you just configured. For more information, see [HTTP proxy provider](../http_proxy_provider.md) or [MQTT proxy provider](../mqtt_proxy_provider.md)
diff --git a/docs/symphony-book/security/authorization.md b/docs/symphony-book/security/authorization.md
index 17dea9026..b216e188d 100644
--- a/docs/symphony-book/security/authorization.md
+++ b/docs/symphony-book/security/authorization.md
@@ -56,7 +56,7 @@ Multiple levels of role-based access control (RBAC) can be applied to Symphony:
 
 * Symphony REST API has RBAC control based on claims in authorization tokens
 * Kubernetes RBAC can be applied to Kubernetes resources
-* When a particular [provider](../providers/providers.md) is used, the provider is subject to authentication and authorization mechanisms reinforced by the connected system.
+* When a particular [provider](../providers/_overview.md) is used, the provider is subject to authentication and authorization mechanisms reinforced by the connected system.
 
 Kubernetes RBAC and provider configuration are out of scope of this document. This section covers how to configure Symphony REST API RBAC.
 
diff --git a/docs/symphony-book/vendors/_overview.md b/docs/symphony-book/vendors/_overview.md
index 04a4b634b..ac47b6f44 100644
--- a/docs/symphony-book/vendors/_overview.md
+++ b/docs/symphony-book/vendors/_overview.md
@@ -4,7 +4,7 @@ A vendor defines a chunk of API. You can consider each vendor a nano service, wh
 
 ## Vendor configuration
 
-Vendors are configured as part of the [host configuration file](../hosts/_overview.md#host-configuration), under the `vendors` array under the top-level `api` element. The following example shows an example of a simple `vendors.echo` vendor, which returns a string when invoked:
+Vendors are configured as part of the [host configuration file](../hosts/_overview.md#host-configurations), under the `vendors` array under the top-level `api` element. The following example shows an example of a simple `vendors.echo` vendor, which returns a string when invoked:
 
 ```json
 {
diff --git a/test/localenv/README.md b/test/localenv/README.md
index 2204886dc..45547dd99 100644
--- a/test/localenv/README.md
+++ b/test/localenv/README.md
@@ -216,13 +216,13 @@ CI integration tests can be run locally with the following command:
 mage test:up
 ```
 
-See [integration test README](../test/integration/README.md) for more details.
+See [integration test README](../integration/README.md) for more details.
 
 # Unit tests
 
 ## Perquisites for running unit tests
 
-In [k8s](../k8s) and [api](../api) folder, we could run unit tests.
+In [k8s](../../k8s) and [api](../../api) folder, we could run unit tests.
 
 To run unit tests, we need to
 
@@ -238,4 +238,4 @@ sudo apt-get install jq
 go env -w CGO_ENABLED=1
 go env CGO_ENABLED
 ```
-Then go to [k8s](../k8s) or [api](../api), run ```mage test``` to launch unit tests.
\ No newline at end of file
+Then go to [k8s](../../k8s) or [api](../../api) folder, run ```mage test``` to launch unit tests.
\ No newline at end of file