fix broken markdown links

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).
 

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

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).

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).

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:**
 

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.

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/).
 

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)
 

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)
+related content: [Sideload apps provider for Windows 10 and XBOX](../providers/target-providers/win10_sideload_provider.md)

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.
 

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.
 

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
 

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
 

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:
 

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).
 

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.

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

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)

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)

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
 {

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.
 

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 |
 |--------|--------|

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.
 

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