Update glossary syntax

Author: Dan Costello

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

@@ -20,23 +20,23 @@ Accessors can be configured to access either live or soft-deleted data. Soft-del
 
 ## How Accessors Work
 
-1. Data, <<glossary:consent>>s and <<glossary:purpose>>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>> API
-3. Several access policies are evaluated for each user record, using the data passed in <<glossary:context>> and data in the user object:
+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).
    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>>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](https://docs.userclouds.com/docs/protect-a-column-with-defaults). 
 
 ## Structure of an Accessor
 
-At creation time, each accessor is associated with a user record <<glossary:selector>>, a set of <<glossary:column>>s, a set of <<glossary:data transformer>>s, a <<glossary:purpose>> and an <<glossary:access policy>>.
+At creation time, each accessor is associated with a user record <Glossary>selector</Glossary>, a set of <Glossary>column</Glossary>s, a set of <Glossary>data transformer</Glossary>s, a <Glossary>purpose</Glossary> and an <Glossary>access policy</Glossary>.
 
-- The user record <<glossary:selector>> 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>>s used in the selector. Since UserClouds does not store consents for <<glossary:system column>>s, they can be referenced in the selector regardless of accessor purpose / user consents.
+- 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>>, 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](https://docs.userclouds.com/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

content/docs/(data-access)/definitions/mutators-write-apis.mdx

@@ -8,28 +8,28 @@ updatedAt: "Tue Sep 10 2024 16:09:35 GMT+0000 (Coordinated Universal Time)"
 ---
 ## Introduction
 
-Mutators are configurable APIs that allow a client to write data to the User Store. Mutators (setters) can be thought of as the complement to <glossary:accessor>s (getters). Mutators serve two functions: 
+Mutators are configurable APIs that allow a client to write data to the User Store. Mutators (setters) can be thought of as the complement to <Glossary>accessor</Glossary>s (getters). Mutators serve two functions: 
 
 - Storing sensitive user data in the store
-- Storing user <<glossary:consent>>s to data processing <<glossary:purpose>>s alongside that data
+- Storing user <Glossary>consent</Glossary>s to data processing <Glossary>purpose</Glossary>s alongside that data
 
 ## How Mutators Work
 
 Writing data and consents through mutators involves several key steps:
 
 1. The initiating application or client sends a request to write data. This request includes: 
-   1. An array of <<glossary:SelectorValues>>, to be evaluated by the mutator's <<glossary:selector>> 
-   2. Client context data to be evaluated by the mutator's <<glossary:access policy>>
+   1. An array of <Glossary>SelectorValues</Glossary>, to be evaluated by the mutator's <Glossary>selector</Glossary> 
+   2. Client context data to be evaluated by the mutator's <Glossary>access policy</Glossary>
    3. User data 
    4. User consents
-2. Utilizing the provided <<glossary:SelectorValues>>, the mutator's selector identifies the relevant user records to be updated. For a detailed explanation, visit our [selector documentation](https://docs.userclouds.com/docs/selectors).
-3. Two access policies are applied to each selected user record: the global baseline policy for mutators (learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies)) and the mutator's own <<glossary:access policy>> composition. This step may involve evaluating the provided client context or any user-specific data already present in the User Store to determine if the write operation is permitted for each selector user record. 
+2. Utilizing the provided <Glossary>SelectorValues</Glossary>, the mutator's selector identifies the relevant user records to be updated. For a detailed explanation, visit our [selector documentation](https://docs.userclouds.com/docs/selectors).
+3. Two access policies are applied to each selected user record: the global baseline policy for mutators (learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies)) and the mutator's own <Glossary>access policy</Glossary> composition. This step may involve evaluating the provided client context or any user-specific data already present in the User Store to determine if the write operation is permitted for each selector user record. 
 4. For those records that pass the access policy check, the mutator proceeds to validate and transform the incoming data to ensure it meets the required standards
 5. Finally, the processed data, along with the associated user consents, are securely stored in the User Store
 
 ## Structure of a Mutator
 
-At creation time, each mutator is associated with a user record <<glossary:selector>>, a set of <<glossary:column>>s, a set of <<glossary:data transformer>>s and an <<glossary:access policy>>.
+At creation time, each mutator is associated with a user record <Glossary>selector</Glossary>, a set of <Glossary>column</Glossary>s, a set of <Glossary>data transformer</Glossary>s and an <Glossary>access policy</Glossary>.
 
 - The record selector is a SQL-like clause that specifies which records the mutator should edit data for, based on an array of values that are passed at execution time.
 - The columns indicate which data field the mutator will edit.

content/docs/(data-access)/definitions/transformers-1.mdx

@@ -17,8 +17,8 @@ Transformers allow you to retain select structure and information from the raw d
 
 Transformers are executed in two places:
 
-- Each <<glossary:accessor>> (read path) is associated with a transformer per column, dictating how the data in that column is obscured or minimized when the accessor is called
-- When a <<glossary:token>> is created, a data transformer is specified to dictate how the token should be generated from the raw data (and therefore what information, if any, should be retained in the token)
+- Each <Glossary>accessor</Glossary> (read path) is associated with a transformer per column, dictating how the data in that column is obscured or minimized when the accessor is called
+- When a <Glossary>token</Glossary> is created, a data transformer is specified to dictate how the token should be generated from the raw data (and therefore what information, if any, should be retained in the token)
 
 In addition, column default transformers provide a way to consistently apply transformations across all accessors that extract data from specific columns:
 

content/docs/(data-access)/how-to-guides/create-an-access-policy.mdx

@@ -22,7 +22,7 @@ Access policies and templates are managed under the Access Rules element in the
 
 Policy templates are parametrizable functions that can be parametrized to create access policies. To create a policy template, go to the Policies page and click Create Policy Template. 
 
-**1 Create your <<glossary:access policy template>>**
+**1 Create your <Glossary>access policy template</Glossary>**
 
 Specify a name, a description and a javascript function for your policy. The javascript function may optionally accept parameters, which you can test below. 
 
@@ -41,7 +41,7 @@ Use the "Test Your Draft" card at the bottom of the page to test your policy tem
 
 To create a new access policy, click "Create Policy" from the Policies page, accessible from the sidebar of UserClouds Console. You can create the new policy by writing a new policy or template from scratch in this interface, by composing existing policies with AND / OR logic, or both. 
 
-**2 Set your <<glossary:access policy>> name and description**
+**2 Set your <Glossary>access policy</Glossary> name and description**
 
 Next, add a name and a description for your policy.
 

content/docs/(data-access)/how-to-guides/edit-existing-user-data.mdx

@@ -9,9 +9,9 @@ updatedAt: "Tue Feb 27 2024 01:42:13 GMT+0000 (Coordinated Universal Time)"
 UserClouds stores two types of information for every user: 
 
 - **User data** such as their name, email or phone number
-- **User consents**: for each column, UserClouds also stores a set of user <<glossary:consent>>s, indicating which data processing purposes a user has consented to for that column of data
+- **User consents**: for each column, UserClouds also stores a set of user <Glossary>consent</Glossary>s, indicating which data processing purposes a user has consented to for that column of data
 
-You can update both data and consents using <<glossary:mutator>>s. Mutators are advanced write APIs. They  enforce access policies, receive inbound data, normalize it, and save it to the specified record(s) and column(s) in the User Store.
+You can update both data and consents using <Glossary>mutator</Glossary>s. Mutators are advanced write APIs. They  enforce access policies, receive inbound data, normalize it, and save it to the specified record(s) and column(s) in the User Store.
 
 UserClouds automatically code-generates an SDK so that calling mutators is as simple as calling any other function in your codebase. 
 

content/docs/(data-access)/how-to-guides/edit-existing-user-data/create-a-mutator.mdx

@@ -8,7 +8,7 @@ updatedAt: "Fri Jun 28 2024 22:49:35 GMT+0000 (Coordinated Universal Time)"
 ---
 ## Introduction
 
-Mutators are configurable APIs that allow a client to update data in the User Store. Mutators (write APIs) can be thought of as the complement to <<glossary:accessor>>s (read APIs). Mutators are intended to capture and store a user's consented <<glossary:purpose>>s alongside their sensitive data. Purposes are passed in context at execution time. 
+Mutators are configurable APIs that allow a client to update data in the User Store. Mutators (write APIs) can be thought of as the complement to <Glossary>accessor</Glossary>s (read APIs). Mutators are intended to capture and store a user's consented <Glossary>purpose</Glossary>s alongside their sensitive data. Purposes are passed in context at execution time. 
 
 Mutators do not create users: they only add or edit values associated with existing users. You can create a user via the [CreateUserWithMutator](https://docs.userclouds.com/reference/post_userstore-api-users)  call. 
 
@@ -31,7 +31,7 @@ Mutator names are used in your codebase (to call the API) and in your audit log
 
 ### 2. Choose which records and columns the mutator will write data to
 
-Next, pick the user records and <<glossary:column>>s the mutator will return data for. Specify the user records by writing a <<glossary:selector>>, a SQL-like clause, like `{id} = ANY(?) OR {Email} LIKE ?`. In selectors, each ? represents a parameter that is passed in an array, at execution time. This parameter can be a single value, or an array of possible values. For more info on selectors, see [Selectors](https://docs.userclouds.com/docs/selectors).
+Next, pick the user records and <Glossary>column</Glossary>s the mutator will return data for. Specify the user records by writing a <Glossary>selector</Glossary>, a SQL-like clause, like `{id} = ANY(?) OR {Email} LIKE ?`. In selectors, each ? represents a parameter that is passed in an array, at execution time. This parameter can be a single value, or an array of possible values. For more info on selectors, see [Selectors](https://docs.userclouds.com/docs/selectors).
 
 When creating a user via the `CreateUserWithMutator` API, you should use the selector `{id} = ?`. For more info on creating users in User Store, see Create a User. 
 
@@ -42,7 +42,7 @@ Add columns by selecting from the dropdown and clicking "Add Column".
 
 ### 3. Define how the mutator should normalize inbound data
 
-Next, you must define how the mutator will normalize each column's data on the way into the store. Choose one <<glossary:data normalizer>> per column, using the dropdowns in each row of the columns table (see picture above). Any transformer of type PassThrough or Transform may be used as a normalizer, but tokenizing transformers cannot be used as normalizers. If no normalization is desired or required, a PassThrough normalizer should be used.
+Next, you must define how the mutator will normalize each column's data on the way into the store. Choose one <Glossary>data normalizer</Glossary> per column, using the dropdowns in each row of the columns table (see picture above). Any transformer of type PassThrough or Transform may be used as a normalizer, but tokenizing transformers cannot be used as normalizers. If no normalization is desired or required, a PassThrough normalizer should be used.
 
 Only normalizers with an output type that exactly matches the column's data type may be used. For example: 
 
@@ -54,10 +54,10 @@ For more information on transformers, see [Transformers](https://docs.userclouds
 
 ### 4. Define the circumstances in which the mutator can be used
 
-Finally, select an <<glossary:access policy>> for the mutator. The access policy controls whether the whether a given write attempt (execute mutator call) is allowed. The simplest access policy always returns true (write permitted). It is possible to create much more fine-grained policies. In this interface, you can:
+Finally, select an <Glossary>access policy</Glossary> for the mutator. The access policy controls whether the whether a given write attempt (execute mutator call) is allowed. The simplest access policy always returns true (write permitted). It is possible to create much more fine-grained policies. In this interface, you can:
 
 - Choose a single, pre-existing policy
-- Choose and parametrize a pre-existing <<glossary:access policy template>>
+- Choose and parametrize a pre-existing <Glossary>access policy template</Glossary>
 - Write and parametrize a new policy template
 - Compose a new policy by taking any of the above actions multiple times and combining those policies with AND or OR logic