diff --git a/docs/data-ai/ai/deploy.md b/docs/data-ai/ai/deploy.md
index e129e82e9e..b7c7ae66c3 100644
--- a/docs/data-ai/ai/deploy.md
+++ b/docs/data-ai/ai/deploy.md
@@ -9,14 +9,6 @@ description: "The Machine Learning (ML) model service allows you to deploy machi
aliases:
- /how-tos/train-deploy-ml/
- /services/ml/
- - /registry/ml/
- - /services/ml/upload-model/
- - /services/ml/edit/
- - /ml/edit/
- - /manage/data/upload-model/
- - /manage/ml/upload-model/
- - /ml/upload-model/
- - /services/ml/ml-models/
---
The Machine Learning (ML) model service allows you to deploy [machine learning models](/data-ai/ai/deploy/#deploy-your-ml-model) to your machine.
@@ -74,5 +66,5 @@ For other use cases, consider [creating custom functionality with a module](/ope
{{< alert title="Add support for other models" color="tip" >}}
ML models must be designed in particular shapes to work with the `mlmodel` [classification](/operate/reference/services/vision/mlmodel/) or [detection](/operate/reference/services/vision/mlmodel/) model of Viam's [vision service](/operate/reference/services/vision/).
-See [ML Model Design](/operate/reference/advanced-modules/mlmodel-design/) to design a modular ML model service with models that work with vision.
+See [ML Model Design](/registry/advanced/mlmodel-design/) to design a modular ML model service with models that work with vision.
{{< /alert >}}
diff --git a/docs/dev/reference/glossary/part.md b/docs/dev/reference/glossary/part.md
index 489facb829..d8d6c73332 100644
--- a/docs/dev/reference/glossary/part.md
+++ b/docs/dev/reference/glossary/part.md
@@ -1,7 +1,7 @@
---
title: Part
id: part
-full_link: /operate/reference/architecture/parts/
+full_link: /architecture/parts/
short_description: A single-board computer, desktop, laptop, or other computer running viam-server, the hardware components attached to it, and any services or other resources running on it.
---
diff --git a/docs/dev/reference/glossary/resource.md b/docs/dev/reference/glossary/resource.md
index 1406db8a2e..64908efa2f 100644
--- a/docs/dev/reference/glossary/resource.md
+++ b/docs/dev/reference/glossary/resource.md
@@ -17,4 +17,4 @@ Resources are individual, addressable elements of a machine.
Each part has local resources and can also have resources from another {{< glossary_tooltip term_id="remote-part" text="remote">}} machine part.
The capabilities of each resource are exposed through the part’s API.
-Each resource on your machine implements either one of the [existing Viam APIs](/dev/reference/apis/), or a [custom interface](/operate/reference/advanced-modules/#new-api-subtypes).
+Each resource on your machine implements either one of the [existing Viam APIs](/dev/reference/apis/), or a [custom interface](/registry/advanced/#new-api-subtypes).
diff --git a/docs/dev/reference/sdks/use-extra-params.md b/docs/dev/reference/sdks/use-extra-params.md
index 7442384e89..522bbfa21c 100644
--- a/docs/dev/reference/sdks/use-extra-params.md
+++ b/docs/dev/reference/sdks/use-extra-params.md
@@ -90,7 +90,7 @@ If passing an object of type `nil`, you must specify `nil` in the method call or
## Define
-If `extra` information must be passed to a resource, it is handled within a new, _modular_ resource model's [custom API](/operate/get-started/other-hardware/) wrapper.
+If `extra` information must be passed to a resource, it is handled within a new, _modular_ resource model's [custom API](/registry/) wrapper.
{{%expand "Click for instructions on defining a custom model to use extra params" %}}
diff --git a/docs/operate/get-started/other-hardware/cpp-module.md b/docs/operate/get-started/other-hardware/cpp-module.md
index 60afd3f6f7..a9dbab0724 100644
--- a/docs/operate/get-started/other-hardware/cpp-module.md
+++ b/docs/operate/get-started/other-hardware/cpp-module.md
@@ -70,7 +70,7 @@ If you want to write a module to add support to a new type of component or servi
- If you are working with a component that doesn't fit into any of the existing component APIs, you can use the [generic component](/operate/reference/components/generic/) to build your own component API.
- If you are designing a service that doesn't fit into any of the existing service APIs, you can use the [generic service](/operate/reference/components/generic/) to build your own service API.
-- It is also possible to [define an entirely new API](/operate/reference/advanced-modules/create-subtype/), but this is even more advanced than using `generic`.
+- It is also possible to [define an entirely new API](/registry/advanced/create-subtype/), but this is even more advanced than using `generic`.
Most module use cases, however, benefit from implementing an existing API instead of `generic`.
{{% /alert %}}
diff --git a/docs/operate/reference/advanced-modules/_index.md b/docs/operate/reference/advanced-modules/_index.md
deleted file mode 100644
index 7cb6059986..0000000000
--- a/docs/operate/reference/advanced-modules/_index.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: "Advanced Modular Resources"
-linkTitle: "Advanced Modules"
-type: docs
-tags:
- [
- "server",
- "rdk",
- "extending viam",
- "modular resources",
- "components",
- "services",
- ]
-description: "Some usage may require you to define new APIs or deploy custom components using a server on a remote part"
-aliases:
- - /program/extend/
- - /modular-resources/advanced/
- - /registry/advanced/
-date: "2022-01-01"
-# updated: "" # When the content was last entirely checked
-toc_hide: true
----
-
-Some use cases may require advanced considerations when designing or deploying modular resources.
-Depending on your needs, you may wish to define an entirely new API subtype, deploy a custom component using a server on a {{< glossary_tooltip term_id="remote-part" text="remote" >}} {{< glossary_tooltip term_id="part" text="part" >}}, or design a custom ML model.
-
-## New API subtypes
-
-The [component APIs](/dev/reference/apis/#component-apis) and [service APIs](/dev/reference/apis/#service-apis) provide a standard interface for controlling common hardware components and higher level functionality.
-If your use case aligns closely with an existing API, you should use that API to program your new resource.
-
-If you want to use most of an existing API but need just a few other functions, you can use the `DoCommand` endpoint together with [extra parameters](/dev/reference/sdks/use-extra-params/) to add custom functionality to an existing resource {{< glossary_tooltip term_id="subtype" text="subtype" >}}.
-
-Or, if your resource does not fit into an existing resource subtype, you can use one of the following:
-
-- If you are working with a component that doesn't fit into any of the existing [component APIs](/dev/reference/apis/#component-apis), you can use the [generic component](/operate/reference/components/generic/) to build your own component API.
-- If you are designing a service that doesn't fit into any of the existing [service APIs](/dev/reference/apis/#service-apis), you can use the [generic service](/dev/reference/apis/services/generic/) to build your own service API.
-
-Both generic resources use the [`DoCommand`](/dev/reference/apis/components/generic/#docommand) endpoint to enable you to make arbitrary calls as needed for your resource.
-
-Alternatively, you can also [define a new resource subtype and an API for that subtype](/operate/reference/advanced-modules/create-subtype/) if none of the above options are a good fit for your use case.
-
-## Custom components as remotes
-
-Running {{< glossary_tooltip term_id="modular-resource" text="modular resources" >}} on the computer directly connected to your components is the preferred way of managing and controlling custom components.
-
-However, if you are unable to use modular resources because you need to host `viam-server` on a non-Linux system or have an issue with compilation, you may need to [implement a custom component and register it on a server configured as a remote](/operate/reference/advanced-modules/custom-components-remotes/) on your machine.
-
-## Design a custom ML model
-
-When working with the [ML model service](/dev/reference/apis/services/ml/), you can deploy an [existing model](/data-ai/ai/deploy/) or [train your own model](/data-ai/ai/train/).
-
-However, if you are writing your own {{< glossary_tooltip term_id="module" text="module" >}} that uses the ML model service together with the [vision service](/dev/reference/apis/services/vision/), you can also [design your own ML model](/operate/reference/advanced-modules/mlmodel-design/) to better match your specific use case.
diff --git a/docs/operate/reference/advanced-modules/create-subtype.md b/docs/operate/reference/advanced-modules/create-subtype.md
deleted file mode 100644
index b2e468da4f..0000000000
--- a/docs/operate/reference/advanced-modules/create-subtype.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Define a New Resource Subtype"
-linkTitle: "New API Subtype"
-weight: 30
-type: "docs"
-tags: ["rdk", "extending viam", "modular resources", "API"]
-description: "Define a custom API for a resource that does not fit into existing component or service subtypes."
-no_list: true
-aliases:
- - /extend/modular-resources/create/create-subtype/
- - /modular-resources/advanced/create-subtype/
- - /registry/advanced/create-subtype/
-date: "2022-01-01"
-# updated: "" # When the content was last entirely checked
----
-
-You can define a new, custom {{< glossary_tooltip term_id="resource" text="resource" >}} _{{< glossary_tooltip term_id="subtype" text="subtype" >}}_ API if:
-
-- You have a {{% glossary_tooltip term_id="resource" text="resource" %}} that does not fit into any of the existing {{< glossary_tooltip term_id="component" text="component" >}} or {{< glossary_tooltip term_id="service" text="service" >}} subtypes.
-- You have a resource that could fit into an existing subtype, but you want to define an API with different methods and messages than the ones in the existing [APIs](/dev/reference/apis/) for that subtype.
-
-{{% alert title="Tip" color="tip" %}}
-
-If you want to use most of an existing API but need just a few other functions, try using the `DoCommand` endpoint and [extra parameters](/dev/reference/sdks/use-extra-params/) to add custom functionality to an existing subtype.
-For example, if you have a [sensor](/operate/reference/components/sensor/) and you want to define a `Calibrate` method, you can use `DoCommand`.
-
-If your use case uses only `DoCommand` and no other API methods, you can define a new model of [generic component](/operate/reference/components/generic/) or [generic service](/operate/reference/services/generic/).
-
-{{% /alert %}}
-
-## Define your new resource API
-
-Viam uses [protocol buffers](https://protobuf.dev/) for API definition.
-
-To define a new subtype, you need to define the methods and messages of the new API in [protobuf](https://github.com/protocolbuffers/protobuf), write code in Python or Go to implement the higher level server and client functions required, and generate all necessary [protobuf module files](https://buf.build/docs/generate/usage/).
-The following steps guide you through this process in more detail:
-
-1. Decide whether your custom subtype is a {{< glossary_tooltip term_id="component" text="component" >}} or a {{< glossary_tooltip term_id="service" text="service" >}}.
- If it provides an interface to control hardware, it is a component.
- If it provides higher-level functionality, it is a service.
-1. Choose a name for your subtype.
- For example, `gizmo`.
-
- Determine a valid {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet" >}} based on your subtype name.
- You can figure out the {{< glossary_tooltip term_id="model-namespace-triplet" text="model namespace triplet" >}} later when you [create a model that implements your custom API](/operate/get-started/other-hardware/).
-
- {{< expand "API namespace triplet and model namespace triplet example" >}}
-
- The `viam-labs:audioout:pygame` model uses the repository name [audioout](https://github.com/viam-labs/audioout).
- It implements the custom API `viam-labs:service:audioout`:
-
- ```json
- {
- "api": "viam-labs:service:audioout",
- "model": "viam-labs:audioout:pygame"
- }
- ```
-
- For your custom API, your API namespace triplet might be `your-org-namespace:component:gizmo` where `your-org-namespace` is your organization namespace, found in your org settings page in the Viam app.
-
- {{< /expand >}}
-
-1. Create a directory for your module.
- Within that, create a directory called src.
-
- {{% alert title="Tip" color="tip" %}}
-
- If you are writing your module using Python, you can use this [module generator tool](https://github.com/viam-labs/generator-viam-module) to generate stub files for the new API as well as a new {{< glossary_tooltip term_id="module" text="module" >}} that implements the new API.
-
- {{% /alert %}}
-
-1. Define your new API:
-
- - [Write the proto](https://protobuf.dev/programming-guides/proto3/) methods in a `.proto` file inside your src/proto directory.
- For reference:
- - [Example modular component proto file](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/src/proto/gizmo.proto)
- - [Example modular service proto file](https://github.com/viam-labs/speech-service-api/blob/main/src/proto/speech.proto)
- - [Built-in Viam resource proto files](https://github.com/viamrobotics/api/tree/main/proto/viam)
- - And define the proto methods in a protobuf-supported language such as Python or Go in a file called `api.py` or `api.go`, respectively.
- - [Example component in Python](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/src/gizmo/api.py)
- - [Example service in Python](https://github.com/viam-labs/speech-service-api/blob/main/src/speech_service_api/api.py)
-
-1. In the root directory of your module, you need to generate some configuration files.
- You will typically need the following three files for most modules, though different files are required for some advanced use cases.
- See the [Buf documentation](https://buf.build/docs/generate/usage/) for instructions.
-
- - [buf.yaml](https://buf.build/docs/configuration/v1/buf-gen-yaml/)
- - [buf.gen.yaml](https://buf.build/docs/configuration/v1/buf-gen-yaml/)
- - [buf.lock](https://buf.build/docs/configuration/v1/buf-lock/)
-
-1. In the /src/ directory of your module, use the protobuf compiler to [generate](https://buf.build/docs/tutorials/getting-started-with-buf-cli/#generate-code) all other necessary protocol buffer code, based on the `.proto` file you wrote.
-
- - [Example generated files for a Python-based service](https://github.com/viam-labs/speech-service-api/tree/main/src/proto).
- The `buf.` files were generated.
- The speech.proto was manually written.
-
-## Next steps
-
-{{< cards >}}
-{{% manualcard link="/operate/get-started/other-hardware/" %}}
-
-Implement your API
-
-Now that your resource API is defined, create a new model that implements your new API.
-
-{{% /manualcard %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/advanced-modules/custom-components-remotes.md b/docs/operate/reference/advanced-modules/custom-components-remotes.md
deleted file mode 100644
index 561eff6f69..0000000000
--- a/docs/operate/reference/advanced-modules/custom-components-remotes.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: "Add Custom Components as Remote Machine Parts"
-linkTitle: "Custom Components as Remote Parts"
-weight: 99
-type: "docs"
-tags: ["server", "sdk"]
-aliases:
- - /program/extend/sdk-as-server/
- - /program/extend/custom-components-remotes/
- - /extend/custom-components-remotes/
- - /modular-resources/advanced/custom-components-remotes/
- - /registry/advanced/custom-components-remotes/
-description: "If you are unable to use modular resources, you can implement custom components and register them on a server configured as a remote of your machine."
-date: "2022-01-01"
-# updated: "" # When the content was last entirely checked
----
-
-Running {{< glossary_tooltip term_id="modular-resource" text="modular resources" >}} on the computer directly connected to your components is the preferred way of managing and controlling custom components.
-
-However, if you are unable to use [modular resources](/operate/get-started/other-hardware/) because you need to host `viam-server` on a non-Linux system or have an issue with compilation, you can use a [Viam SDK](/dev/reference/sdks/) to code a custom resource implementation, host it on a server, and add it as a [remote part](/operate/reference/architecture/parts/) of your machine.
-
-Once you have coded your custom component and configured the remote servers, you can control and monitor your component with the Viam SDKs, like any other component.
-
-To show how to create a custom resource, the following example creates an arm as a custom component and registers the new arm model with a Viam SDK.
-Then you can control it as part of your machine with the same [API methods](/dev/reference/apis/components/arm/#api) available for [arm models built into the RDK](/operate/reference/components/arm/#configuration).
-
-## Instructions
-
-To add a custom resource as a [remote part](/operate/reference/architecture/parts/):
-
-{{< tabs >}}
-{{% tab name="Go" %}}
-
-1. Code a new model of a built-in resource type.
- You can do this by creating a new interface that implements required methods.
- The new model must implement any functions of the built-in resource type marked as required in its [RDK API definition](/dev/reference/apis/).
-2. Register the custom component on a new gRPC server instance and start the server.
-3. Add the server as a [remote part](/operate/reference/architecture/parts/) of your machine.
-4. (Optional) [Configure a process](/manage/reference/processes/) to launch this remote server to ensure the remote server is always running alongside the rest of your machine.
-
-Each remote server can host one or many custom components.
-
-{{% /tab %}}
-{{% tab name="Python" %}}
-
-{{< alert title="Tip" color="tip" >}}
-For more detailed instructions, see the full example in the [Python SDK documentation](https://python.viam.dev/examples/example.html#subclass-a-component).
-{{< /alert >}}
-
-1. Code a new model of a built-in resource type.
- You can do this by subclassing a built in resource type like `sensor` or `arm`.
- The new model must implement any methods of the built-in resource type marked as required in its [RDK API definition](/dev/reference/apis/).
-1. Register the custom component on a new gRPC server instance and start the server.
- You can do this with the [`viam.rpc` library](https://python.viam.dev/autoapi/viam/rpc/index.html) by creating a new `rpc.server.Server` instance.
-1. Add the server as a [remote part](/operate/reference/architecture/parts/) of your machine.
-1. (Optional) [Configure a process](/manage/reference/processes/) to launch this remote server to ensure the remote server is always running alongside the rest of your machine.
-
-Each remote server can host one or many custom components.
-
-{{% /tab %}}
-{{% /tabs %}}
-
-{{% alert title="Important" color="note" %}}
-
-You must define all methods belonging to a built-in resource type when defining a new model.
-Otherwise, the class will not instantiate.
-
-- If you are using the Python SDK, raise an `NotImplementedError()` in the body of functions you do not want to implement or put `pass`.
-- If you are using the Go SDK, return `errUnimplemented`.
-- Additionally, return any values designated in the function's return signature, typed correctly.
-
-{{% /alert %}}
diff --git a/docs/operate/reference/advanced-modules/mlmodel-design.md b/docs/operate/reference/advanced-modules/mlmodel-design.md
deleted file mode 100644
index 9bf5d62446..0000000000
--- a/docs/operate/reference/advanced-modules/mlmodel-design.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: "Design your ML Models for Vision"
-linkTitle: "ML Model Design"
-weight: 60
-type: "docs"
-tags: ["data management", "ml", "model training", "vision"]
-description: "Design your ML Model service to work with Viam's vision services."
-icon: true
-images: ["/services/icons/ml.svg"]
-date: "2022-01-01"
-# updated: "" # When the content was last entirely checked
-# SME: Bijan Haney
-aliases:
- - /registry/advanced/mlmodel-design/
----
-
-The [Machine Learning (ML) model service](/data-ai/ai/deploy/) allow you to deploy machine learning models to your smart machine.
-Vision services, like [an `"mlmodel"` detector](/dev/reference/apis/services/vision/#detections) or [classifier](/dev/reference/apis/services/vision/#classifications), enable your machines to identify and classify objects in images with the deployed models' predictions.
-
-The two services work closely together, with the vision service relying on the deployed ML model to make inferences.
-If you are [designing your own ML Model service](/data-ai/ai/deploy/), you must try to make your ML models' shapes match the input and output tensors the `mlmodel` vision service expects to work with if you want the two services to coordinate in classification or detection.
-
-To be able to use a deployed ML model, the `mlmodel` vision service checks for descriptions of these characteristics in the [metadata](/dev/reference/apis/services/ml/#metadata) of the model, as defined in [the Python SDK](https://python.viam.dev/autoapi/viam/gen/service/mlmodel/v1/mlmodel_pb2/index.html#viam.gen.service.mlmodel.v1.mlmodel_pb2.Metadata).
-For an example of this, see [Example Metadata](#example-metadata).
-
-## Input tensor: `input_info` in metadata
-
-For both [classification](/dev/reference/apis/services/vision/#classifications) and [detection](/dev/reference/apis/services/vision/#detections) models, the vision service sends a single input tensor to the ML Model with the following structure:
-
-- One input tensor called `"image"` with type `uint8` or `float32` and shape `(1, height, width, 3)`, with the last channel `3` being the RGB bytes of the pixel.
-- If image `height` and `width` are unknown or variable, then `height` and/or `width` `= -1`. During inference runtime the image will have a known height and width.
-
-## Output tensors: `output_info` in metadata
-
-Data can be returned by the ML model in many ways, due to the variety of machine learning models for computer vision.
-The vision service will try to take into account many different forms of models as specified by the metadata of the model.
-If the model does not provide metadata, the vision service will make the following assumptions:
-
-For [classifications](/dev/reference/apis/services/vision/#classifications):
-
-- The model returns 1 tensor, called `"probability"` with shape `(1, n_classifications)`
-- The data is floating point numbers representing probability, between `0` and `1`.
-- If the data is not between `0` and `1`, the vision service computes a softmax over the data, resulting in floating point numbers between `0` and `1` representing probability.
-
-For [detections](/dev/reference/apis/services/vision/#detections):
-
-- The model returns 3 tensors
- 1. `"Location"`: the bounding boxes
- - Shape: `(1, n_detections, 4)`
- - Bounding boxes each have shape `(xmin, ymin, xmax, ymax)`
- - Bounding boxes are the proportion of where the box corner is in the image, using a number between `0` and `1`.
- 2. `"Category"`: the labels on the boxes
- - Shape: `(1, n_detections)`
- - Integers representing the index of the label.
- 3. `"Score"`: The confidence scores of the label
- - Shape: `(1, n_detections)`
- - Floating point numbers representing probability, between `0` and `1`.
-
-For labels:
-
-- Many computer vision models have an associated 'labelfile.txt' that lists the class labels associated with the model.
- To get those labels associated with the model, currently the vision service looks at the first element of the `output_info` list in the ML models' metadata and checks for a key called `"labels"` in its `"extra"` struct.
- The value of that key should be the full path to the label file on the machine.
- See [Example Metadata](#example-metadata) for an example of this.
-
- ```sh {class="command-line" data-prompt="$"}
- label_path = ml_model_metadata.output_info.extra["labels"]
- ```
-
-### Example metadata
-
-For example, a TF lite detector model that works with the vision service is structured with the following [metadata](/dev/reference/apis/services/ml/#metadata):
-
-```json {class="line-numbers linkable-line-numbers"}
-name: "EfficientDet Lite0 V1"
-type: "tflite_detector"
-description: "Identify which of a known set of objects might be present and provide information about their positions within the given image or a video stream."
-input_info {
- name: "image"
- description: "Input image to be detected. The expected image is 320 x 320, with three channels (red, blue, and green) per pixel. Each value in the tensor is a single byte between 0 and 255."
- data_type: "uint8"
- shape: 1
- shape: 320
- shape: 320
- shape: 3
- extra {
- }
-}
-output_info {
- name: "location"
- description: "The locations of the detected boxes."
- data_type: "float32"
- extra {
- fields {
- key: "labels"
- value {
- string_value: "/Users//.viam/packages/.data/ml_model/effdet0-1685040512967/effdetlabels.txt"
- }
- }
- }
-}
-output_info {
- name: "category"
- description: "The categories of the detected boxes."
- data_type: "float32"
- associated_files {
- name: "labelmap.txt"
- description: "Label of objects that this model can recognize."
- label_type: LABEL_TYPE_TENSOR_VALUE
- }
- extra {
- }
-}
-output_info {
- name: "score"
- description: "The scores of the detected boxes."
- data_type: "float32"
- extra {
- }
-}
-output_info {
- name: "number of detections"
- description: "The number of the detected boxes."
- data_type: "float32"
- extra {
- }
-}
-```
diff --git a/docs/operate/reference/module-configuration.md b/docs/operate/reference/module-configuration.md
index 28b4c2e841..8b1ff7a2d8 100644
--- a/docs/operate/reference/module-configuration.md
+++ b/docs/operate/reference/module-configuration.md
@@ -77,7 +77,7 @@ The following properties are available for modular resources:
| ---- | ---- | --------- | ----------- |
| `attributes` | object | Sometimes **Required** | Any configuration attributes for your model Check the module's GitHub Readme for information about available configuration attributes for a resource. |
| `name` | string | **Required** | What you want to name this instance of your modular resource. |
-| `namespace` | string | **Required** | The namespace of the API (the first part of the {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet">}}). This will be `rdk` unless the module implements a [custom, non-standard API](/operate/reference/advanced-modules/). |
+| `namespace` | string | **Required** | The namespace of the API (the first part of the {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet">}}). This will be `rdk` unless the module implements a [custom, non-standard API](/registry/advanced/). |
| `type` | string | **Required** | The {{< glossary_tooltip term_id="subtype" text="subtype">}} of the API (the third part of the {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet">}}). |
| `model` | string | **Required** | The full {{< glossary_tooltip term_id="model-namespace-triplet" text="model namespace triplet">}} of the modular resource's {{< glossary_tooltip term_id="model" text="model" >}}. |
| `depends_on` | array | Optional | The `name` of components you want to confirm are available on your machine alongside your modular resource. Often a [board](/operate/reference/components/board/). Unnecessary if you coded [implicit dependencies](/operate/reference/viam-server/#dependency-management). |
diff --git a/docs/operate/reference/services/slam/cloudslam/_index.md b/docs/operate/reference/services/slam/cloudslam/_index.md
index f03b37b512..4af4920abf 100644
--- a/docs/operate/reference/services/slam/cloudslam/_index.md
+++ b/docs/operate/reference/services/slam/cloudslam/_index.md
@@ -431,7 +431,7 @@ The following attributes are available for `viam:cloudslam-wrapper:cloudslam`
| `api_key` | string | **Required** | An [API key](/manage/manage/access/) with location owner or higher permission. |
| `api_key_id` | string | **Required** | The associated API key ID with the API key. |
| `organization_id` | string | **Required** | The organization ID of your [organization](/dev/reference/glossary/#organization). |
-| `location_id` | string | **Required** | The location ID of your [location](/dev/reference/glossary/#location). |
+| `location_id` | string | **Required** | The location ID of your [location](/dev/reference/glossary/#location/). |
| `machine_id` | string | **Required** | The machine ID of your [machine](/dev/reference/apis/fleet/#find-machine-id). |
| `machine_part_id` | string | Optional | The machine part ID of your [machine part](/dev/reference/apis/fleet/#find-machine-id). Used for local package creation and updating mode. |
| `viam_version` | string | Optional | The version of viam-server to use with CloudSLAM. Defaults to `stable`. |