Update relative links

Author: Dan Costello

content/docs/(authorization)/Overview/modelling-hierarchy-with-attribute-types.mdx

@@ -12,7 +12,7 @@ In this article, you will learn how to model relationships and arbitrarily deep
 - **Organizational structures** where users can be members of different teams
 - **Social structures** like families and friends of friends
 
-The article assumes you know what <Glossary>object</Glossary>, <Glossary>edge</Glossary>s, <Glossary>attribute</Glossary>s and <Glossary>permission</Glossary>s are. For more detail, see our [Key Concepts](https://docs.userclouds.com/docs/key-concepts-1) article.
+The article assumes you know what <Glossary>object</Glossary>, <Glossary>edge</Glossary>s, <Glossary>attribute</Glossary>s and <Glossary>permission</Glossary>s are. For more detail, see our [Key Concepts](/docs/key-concepts-1) article.
 
 ## Attribute Scopes
 

content/docs/(authorization)/how-to-guides/1-design-your-model.mdx

@@ -56,4 +56,4 @@ Attributes are defined at the edge type level, so all edges of a given type shar
 - They pass a permission from one user or group to another (<Glossary>inherit</Glossary> attributes)
 - They propagate a permission down a hierarchy of nested objects, like folders and files (<Glossary>propagate</Glossary> attributes)
 
-For more intro on attributes, see [Modelling Hierarchy with Attribute Scopes](https://docs.userclouds.com/docs/modelling-hierarchy-with-attribute-types).
+For more intro on attributes, see [Modelling Hierarchy with Attribute Scopes](/docs/modelling-hierarchy-with-attribute-types).

content/docs/(authorization)/how-to-guides/2-populate-the-graph.mdx

@@ -12,7 +12,7 @@ updatedAt: "Fri Aug 04 2023 18:42:07 GMT+0000 (Coordinated Universal Time)"
 Once you have designed the structure of your model, it's time to build your database of <Glossary>object</Glossary>s and <Glossary>edge</Glossary>s in UserClouds. This can be done in two steps:
 
 - (a) Migrate over from a pre-existing identity system
-- (b) Implement UserClouds's APIs to [populate the graph with objects](https://docs.userclouds.com/reference/post_authz-objects) and [edges](https://docs.userclouds.com/reference/post_authz-edges) on an ongoing basis
+- (b) Implement UserClouds's APIs to [populate the graph with objects](/reference/post_authz-objects) and [edges](/reference/post_authz-edges) on an ongoing basis
 
 If you are building your product or user base from scratch, you will skip straight to part (b).
 
@@ -24,6 +24,6 @@ _Docs coming soon! For help migrating over from your existing AuthZ system, plea
 
 ## B. Implement Write APIs in your software
 
-Maintaining your authorization graph is simple with UserClouds's CRUD APIs. These allow you to [create Objects](https://docs.userclouds.com/reference/post_authz-objects) and [Edges](https://docs.userclouds.com/reference/post_authz-edges) programmatically in your application.
+Maintaining your authorization graph is simple with UserClouds's CRUD APIs. These allow you to [create Objects](/reference/post_authz-objects) and [Edges](/reference/post_authz-edges) programmatically in your application.
 
-For more information on the APIs for Authorization, check out our [Authorization API Docs](https://docs.userclouds.com/reference/post_authz-objects).
+For more information on the APIs for Authorization, check out our [Authorization API Docs](/reference/post_authz-objects).

content/docs/(authorization)/how-to-guides/3-run-permissions-checks.mdx

@@ -6,7 +6,7 @@ hidden: false
 createdAt: "Thu Aug 03 2023 23:22:50 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Thu Jun 06 2024 17:25:04 GMT+0000 (Coordinated Universal Time)"
 ---
-Once you have populated UserClouds with your types, objects and edges, UserClouds is ready to be the source-of-truth for permissions. To implement <Glossary>permission</Glossary>s in your system, all you need to do is add UserClouds's [Permission Check APIs](https://docs.userclouds.com/reference/get_authz-checkattribute) in the appropriate places in your software.
+Once you have populated UserClouds with your types, objects and edges, UserClouds is ready to be the source-of-truth for permissions. To implement <Glossary>permission</Glossary>s in your system, all you need to do is add UserClouds's [Permission Check APIs](/reference/get_authz-checkattribute) in the appropriate places in your software.
 
 - **CheckAttribute** answers the question: does user X have permission Y on object Z?
 - **ListAttributes** receives a source object ID and target object ID. It returns a list of attributes that the source object has on the target object.

content/docs/(authorization)/illustrative-examples/b2b2c-marketplace.mdx

@@ -6,7 +6,7 @@ hidden: false
 createdAt: "Wed Nov 22 2023 20:16:42 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Wed Jun 19 2024 16:57:24 GMT+0000 (Coordinated Universal Time)"
 ---
-This article explains how to design a graph-based authorization model for a B2B2C marketplace. The article assumes you are familiar with our [Key Concepts](https://docs.userclouds.com/docs/key-concepts-1) and [Attribute Scopes](https://docs.userclouds.com/docs/modelling-hierarchy-with-attribute-types).
+This article explains how to design a graph-based authorization model for a B2B2C marketplace. The article assumes you are familiar with our [Key Concepts](/docs/key-concepts-1) and [Attribute Scopes](/docs/modelling-hierarchy-with-attribute-types).
 
 There are four steps to design a model:
 

content/docs/(authorization)/illustrative-examples/edtech-platform.mdx

@@ -6,7 +6,7 @@ hidden: false
 createdAt: "Thu Aug 03 2023 23:30:24 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Wed Jun 19 2024 16:57:02 GMT+0000 (Coordinated Universal Time)"
 ---
-This article explains how to design a graph-based authorization model for Slack. The article assumes you are familiar with our [Key Concepts](https://docs.userclouds.com/docs/key-concepts-1) and [Attribute Scopes](https://docs.userclouds.com/docs/modelling-hierarchy-with-attribute-types).
+This article explains how to design a graph-based authorization model for Slack. The article assumes you are familiar with our [Key Concepts](/docs/key-concepts-1) and [Attribute Scopes](/docs/modelling-hierarchy-with-attribute-types).
 
 There are four steps to design a model:
 

content/docs/(authorization)/illustrative-examples/slack.mdx

@@ -6,7 +6,7 @@ hidden: false
 createdAt: "Thu Aug 03 2023 23:29:52 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Thu Feb 06 2025 05:14:29 GMT+0000 (Coordinated Universal Time)"
 ---
-This article explains how to design a graph-based authorization model for Slack. The article assumes you are familiar with our [Key Concepts](https://docs.userclouds.com/docs/key-concepts-1) and [Attribute Scopes](https://docs.userclouds.com/docs/modelling-hierarchy-with-attribute-types#attribute-types).
+This article explains how to design a graph-based authorization model for Slack. The article assumes you are familiar with our [Key Concepts](/docs/key-concepts-1) and [Attribute Scopes](/docs/modelling-hierarchy-with-attribute-types#attribute-types).
 
 There are four steps to design a model:
 

content/docs/(data-access)/definitions/access-policies.mdx

@@ -18,8 +18,8 @@ Access Policies are executed in three places in UserClouds:
 
 In addition, two special types of access policies are available:
 
-- **Column Default Access Policies**: These policies are associated with specific columns and are applied by default to all reads that extract data from those columns. They ensure consistent application of access rules for sensitive data, such as automatically applying a role check to the SSN column. They can be overridden for individual accessors. Learn more [here](https://docs.userclouds.com/docs/protect-a-column-with-defaults).
-- **Global Baseline Access Policies**: These policies are applied by default to all reads, providing a consistent security baseline. For example, a global policy might always require a valid token or restrict access to trusted IP addresses. They cannot be overridden. Learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies).
+- **Column Default Access Policies**: These policies are associated with specific columns and are applied by default to all reads that extract data from those columns. They ensure consistent application of access rules for sensitive data, such as automatically applying a role check to the SSN column. They can be overridden for individual accessors. Learn more [here](/docs/protect-a-column-with-defaults).
+- **Global Baseline Access Policies**: These policies are applied by default to all reads, providing a consistent security baseline. For example, a global policy might always require a valid token or restrict access to trusted IP addresses. They cannot be overridden. Learn more [here](/docs/apply-global-protection-policies).
 
 Access policies provide central, fine-grained control over sensitive data access. They can evaluate purpose, identity, authorization, location, , and more. They can range from simple "always allow resolution" policies to complex evaluations.
 
@@ -190,7 +190,7 @@ const params = {};  // No specific parameters needed for this example
 
 ## checkAttribute
 
-The `checkAttribute` function runs a permission check against the UserClouds authorization graph. If you are using UserClouds for authorization as a service, this can verify if a user has the necessary permissions. In short, it asks whether a given object (usually a user) has an attribute (e.g. "can-read" or "is-admin") on another object (which could be just about any entity in your system). You can read more about this in the [Authorization Documentation](https://docs.userclouds.com/reference/get_authz-checkattribute).
+The `checkAttribute` function runs a permission check against the UserClouds authorization graph. If you are using UserClouds for authorization as a service, this can verify if a user has the necessary permissions. In short, it asks whether a given object (usually a user) has an attribute (e.g. "can-read" or "is-admin") on another object (which could be just about any entity in your system). You can read more about this in the [Authorization Documentation](/reference/get_authz-checkattribute).
 
 ### Example
 
@@ -232,7 +232,7 @@ function policy(context, params) {
 
 UserClouds has several built-in access policies for common use cases, like role-based and time-based expiration of data. However you can also create custom policies, in two ways:
 
-- Call the [CreateAccessPolicy API](https://docs.userclouds.com/reference/post_tokenizer-policies-access)
+- Call the [CreateAccessPolicy API](/reference/post_tokenizer-policies-access)
 - Compose a new policy from existing policies and parametrizable templates in the UserClouds Console
 
 To learn more about creating access policies, see our How to Guide on Creating Access Policies.

content/docs/(data-access)/definitions/accessors-read-apis.mdx

@@ -12,7 +12,7 @@ Accessors are configurable APIs that allow a client to retrieve data from the us
 
 As an example of data minimization, you might configure an accessor called `GetPhoneCountryCodeForAnalytics` that returns the country code of a user's phone number when called, instead of the raw phone number. This reduces the sensitivity of the data outside your store, minimizing your surface area for an attack and simplifying compliance.
 
-Accessors can be configured to access either live or soft-deleted data. Soft-deleted data is data that has been deleted but is temporarily retained for a narrow set of purposes, e.g. fraud investigations. See [Data Lifecycle](https://docs.userclouds.com/docs/data-lifecycle) for more details.
+Accessors can be configured to access either live or soft-deleted data. Soft-deleted data is data that has been deleted but is temporarily retained for a narrow set of purposes, e.g. fraud investigations. See [Data Lifecycle](/docs/data-lifecycle) for more details.
 
 ## What Accessors Do
 
@@ -23,11 +23,11 @@ Accessors can be configured to access either live or soft-deleted data. Soft-del
 1. Data, <Glossary>consent</Glossary>s and <Glossary>purpose</Glossary>s are stored inside the safety layer boundary (either in UserClouds User Store or an owned-and-operated database like RDS)
 2. Data consumers request access by sending context, like purpose or identity, to a use-case specific <Glossary>accessor</Glossary> API
 3. Several access policies are evaluated for each user record, using the data passed in <Glossary>context</Glossary> and data in the user object:
-   1. **Global baseline policy for accessors**: Applied to ensure baseline security. Learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies).
-   2. **Column-default access policies**: Column default policies for all columns accessed by the accessor are applied, unless overridden. Learn more [here](https://docs.userclouds.com/docs/protect-a-column-with-defaults).
+   1. **Global baseline policy for accessors**: Applied to ensure baseline security. Learn more [here](/docs/apply-global-protection-policies).
+   2. **Column-default access policies**: Column default policies for all columns accessed by the accessor are applied, unless overridden. Learn more [here](/docs/protect-a-column-with-defaults).
    3. **Accessor-specific access policy composition**: Applied in addition to the above policies.
 4. User data is further filtered according to whether the users have consented to the accessor's data processing purpose.
-5. For records where access is granted, the accessor's <Glossary>data transformer</Glossary>s transform each column of the outbound data, minimizing the data for the given use case. If no transformer is specified for a given column, the column's default transformer is used. Learn more [here](https://docs.userclouds.com/docs/protect-a-column-with-defaults). 
+5. For records where access is granted, the accessor's <Glossary>data transformer</Glossary>s transform each column of the outbound data, minimizing the data for the given use case. If no transformer is specified for a given column, the column's default transformer is used. Learn more [here](/docs/protect-a-column-with-defaults). 
 
 ## Structure of an Accessor
 
@@ -36,12 +36,12 @@ At creation time, each accessor is associated with a user record <Glossary>selec
 - The user record <Glossary>selector</Glossary> is a SQL-like clause that specifies which records the accessor should return data for, based on an array of values that are passed at execution time. The accessor's response will only include users that have consented to the accessor's purpose for all non-<Glossary>system column</Glossary>s used in the selector. Since UserClouds does not store consents for <Glossary>system column</Glossary>s, they can be referenced in the selector regardless of accessor purpose / user consents.
 - The columns indicate which data fields the accessor will retrieve.
 - Each column is associated with a transformer, which tokenizes, minimizes or otherwise obscures the outbound data from that column.
-- The purpose is selected from your company's list of data processing purposes. This indicates what the accessor will be used for, e.g. marketing. The accessor will run a <Glossary>purpose check</Glossary>, filtering out user records and data for which the user has not consented to the specified purpose across all columns. The accessor's response will only include users that have consented to the accessor's purpose for all columns being retrieved, and all non-system columns used in the selector. Learn more [here](https://docs.userclouds.com/docs/purpose-and-consent).
+- The purpose is selected from your company's list of data processing purposes. This indicates what the accessor will be used for, e.g. marketing. The accessor will run a <Glossary>purpose check</Glossary>, filtering out user records and data for which the user has not consented to the specified purpose across all columns. The accessor's response will only include users that have consented to the accessor's purpose for all columns being retrieved, and all non-system columns used in the selector. Learn more [here](/docs/purpose-and-consent).
 - The access policy determines the circumstances in which the data can be retrieved. Access policies run on each user record and filter out user records which fail the access policy.
 
 ## Learn More
 
 For more info on accessors, see:
 
-- [Creating an accessor](https://docs.userclouds.com/docs/create-an-accessor)
-- [Executing an accessor](https://docs.userclouds.com/reference/post_userstore-api-accessors)
+- [Creating an accessor](/docs/create-an-accessor)
+- [Executing an accessor](/reference/post_userstore-api-accessors)

content/docs/(data-access)/definitions/index.mdx

@@ -8,10 +8,10 @@ updatedAt: "Fri Apr 05 2024 22:17:29 GMT+0000 (Coordinated Universal Time)"
 ---
 This section is designed to give you a deep understanding of the core concepts in UserClouds Safety Layer:
 
-- [Access Policies](https://docs.userclouds.com/docs/access-policies) control the circumstances in which data can be accessed or edited
-- [Data Transformers](https://docs.userclouds.com/docs/transformers) allow you to manipulate and minimize data
-- [Selectors](https://docs.userclouds.com/docs/selectors) are SQL-like clauses that specify which records to retrieve or edit
-- [Accessors](https://docs.userclouds.com/docs/accessors-read-apis) are custom read APIs that allow a client to retrieve data from User Store
-- [Mutators](https://docs.userclouds.com/docs/mutators-write-apis) are custom write APIs that allow a client to send data to User Store
+- [Access Policies](/docs/access-policies) control the circumstances in which data can be accessed or edited
+- [Data Transformers](/docs/transformers) allow you to manipulate and minimize data
+- [Selectors](/docs/selectors) are SQL-like clauses that specify which records to retrieve or edit
+- [Accessors](/docs/accessors-read-apis) are custom read APIs that allow a client to retrieve data from User Store
+- [Mutators](/docs/mutators-write-apis) are custom write APIs that allow a client to send data to User Store
 
 Click the link below to begin.