Dash to colon

Dan Costello · Dan Costello · commit 1269d4a38ee6 · 2025-06-02T14:46:38.000-07:00
diff --git a/content/docs/guides/(data-access)/definitions/access-policies.mdx b/content/docs/guides/(data-access)/definitions/access-policies.mdx
@@ -20,7 +20,7 @@ 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](/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.
+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.
 
 ![Access policies give you central, fine-grained control over sensitive data access. Policies can evaluate purpose, identity, permissions, location, expiration timelines, rate limits and more.](/assets/images/flow-chart.webp)
 
diff --git a/content/docs/guides/(data-access)/definitions/selectors.mdx b/content/docs/guides/(data-access)/definitions/selectors.mdx
diff --git a/content/docs/guides/(data-access)/definitions/transformers.mdx b/content/docs/guides/(data-access)/definitions/transformers.mdx
@@ -52,12 +52,12 @@ A transformer consists of:
 
 - `Name`
 - `Description`
-- `id` - a unique transformer identifier, which can be used as a reference when creating accessors and tokens
+- `id`: a unique transformer identifier, which can be used as a reference when creating accessors and tokens
 - `Input Type`
 - `Output Type`
-- `Transform Type` - as described above
-- `Transform Function` - a transform function with the signature `func(data Object, parameters Object) (Token | error)`
-- `Transform Parameters` - a static JSON object (not containing un-encoded PII) that is available at runtime, allowing you to parameterize and reuse functions like "obfuscate all but the first X letters of these emails"
+- `Transform Type`: as described above
+- `Transform Function`: a transform function with the signature `func(data Object, parameters Object) (Token | error)`
+- `Transform Parameters`: a static JSON object (not containing un-encoded PII) that is available at runtime, allowing you to parameterize and reuse functions like "obfuscate all but the first X letters of these emails"
 
 ![The PreserveCommonValue parameter allows you to optionally preserve common email domains (like gmail.com). Rare domains, like userclouds.com, will be obscured.](/assets/images/parameters.webp)
 
diff --git a/content/docs/guides/(data-access)/how-to-guides/create-a-transformer.mdx b/content/docs/guides/(data-access)/how-to-guides/create-a-transformer.mdx
@@ -48,7 +48,7 @@ To create a transformer in UserClouds, go to the Policies page, accessible from
 
     - **An input data type** for the transformer (string, timestamp etc)
     - **An output data type** for the transformer (string, timestamp etc)
-    - **A transform type** - for more info on these, see
+    - **A transform type**: for more info on these, see
     - **A transform function**, which will receive raw data _as a string_ and return the transformed data
     - _(Optional)_ **A set of parameters** for that function, which allows you to rapidly create transformers with parallel logic
 
diff --git a/content/docs/guides/(data-access)/how-to-guides/edit-existing-user-data/execute-a-mutator.mdx b/content/docs/guides/(data-access)/how-to-guides/edit-existing-user-data/execute-a-mutator.mdx
@@ -23,11 +23,11 @@ When calling the ExecuteMutator API directly you pass:
 - An array of <Glossary>SelectorValues</Glossary>, which are used to parameterize the mutator's <Glossary>selector</Glossary> to define which users should be edited
 - Optional client <Glossary>context</Glossary> data, which may be referred to by the mutator access policy
 - `RowData`, a mapping from mutator column name to a `ValueAndPurposes` record, which captures any requested data or consent changes for that column. `ValueAndPurposes` contains the following attributes, each of which will be explained more fully in the context of FullUpdates and PartialUpdates below:
-  - `Value` - used for FullUpdates
-  - `ValueAdditions` - used for PartialUpdates
-  - `ValueDeletions` - used for PartialUpdates
-  - `PurposeAdditions` - used for FullUpdates and PartialUpdates
-  - `PurposeDeletions` - used for FullUpdates and PartialUpdates
+  - `Value`: used for FullUpdates
+  - `ValueAdditions`: used for PartialUpdates
+  - `ValueDeletions`: used for PartialUpdates
+  - `PurposeAdditions`: used for FullUpdates and PartialUpdates
+  - `PurposeDeletions`: used for FullUpdates and PartialUpdates
 
 ## What happens when you execute a mutator
 
diff --git a/content/docs/guides/(data-tokenization)/definitions/token-access-policies.mdx b/content/docs/guides/(data-tokenization)/definitions/token-access-policies.mdx
@@ -6,14 +6,14 @@ hidden: false
 createdAt: "Thu Aug 03 2023 22:20:54 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Fri Jun 28 2024 22:26:13 GMT+0000 (Coordinated Universal Time)"
 ---
+
 Token Access Policies control the circumstances in which a <Glossary>token</Glossary> can be <Glossary>resolve</Glossary>d. Practically, access policies are functions that receive <Glossary>context</Glossary> data and return true or false according to whether access is allowed or denied. The context can be sent from either the server or the client.
 
 Access policies allow you to govern token resolution centrally, even giving you the ability to modify contracts on data use after the data is shared.
 
 ![Access policies give you central, fine-grained control and visibility over sensitive data access. Policies can evaluate purpose, identity, authorization, location, expiration timelines and more.](/assets/images/flow-chart.webp)
 
-
-Access policies can be as simple as "always allow resolution" to complex evaluations including locations, credentials and purpose. A well-formed access policy can receive <Glossary>context</Glossary> about who is requesting the raw data, when, where and for what purpose. It will evaluate this context against the user’s consents, local laws and the company’s security settings, to determine whether access is permitted. 
+Access policies can be as simple as "always allow resolution" to complex evaluations including locations, credentials and purpose. A well-formed access policy can receive <Glossary>context</Glossary> about who is requesting the raw data, when, where and for what purpose. It will evaluate this context against the user’s consents, local laws and the company’s security settings, to determine whether access is permitted.
 
 ## Examples
 
@@ -30,9 +30,9 @@ Let’s look at four possible access policies applied to a phone number token, t
 
 An access policy consists of a tuple of (ID, function, parameters)
 
-- `id` - as described above
-- `function` - a function with the signature `func(token Token, parameters Object, context Object)`, where context is passed in from the `ResolveToken()` call.
-- `parameters` - a static JSON object (not containing PII) that is available at runtime, allowing you to parameterize and reuse functions like "allow access only from IP range X-Y"
+- `id`: as described above
+- `function`: a function with the signature `func(token Token, parameters Object, context Object)`, where context is passed in from the `ResolveToken()` call.
+- `parameters`: a static JSON object (not containing PII) that is available at runtime, allowing you to parameterize and reuse functions like "allow access only from IP range X-Y"
 
 ## Managing access policies
 
diff --git a/content/docs/guides/(data-tokenization)/definitions/token-transformers.mdx b/content/docs/guides/(data-tokenization)/definitions/token-transformers.mdx
@@ -32,9 +32,9 @@ Let’s look at four possible transformers, to see how transformers work.
 
 A transformer consists of a tuple of (ID, function, parameters)
 
-- `id` - a unique transformer identifier, which can be used as a reference when creating tokens
-- `function` - a transform function with the signature `func(data Object, parameters Object) (Token | error)`
-- `parameters` - a static JSON object (not containing un-encoded PII) that is available at runtime, allowing you to parameterize and reuse functions like "obfuscate all but the first X letters of these emails"
+- `id`: a unique transformer identifier, which can be used as a reference when creating tokens
+- `function`: a transform function with the signature `func(data Object, parameters Object) (Token | error)`
+- `parameters`: a static JSON object (not containing un-encoded PII) that is available at runtime, allowing you to parameterize and reuse functions like "obfuscate all but the first X letters of these emails"
 
 ## Managing transformers
 
diff --git a/content/docs/guides/(deployment)/managing-configuration.mdx b/content/docs/guides/(deployment)/managing-configuration.mdx
@@ -16,7 +16,7 @@ updatedAt: "Tue Jul 30 2024 19:06:01 GMT+0000 (Coordinated Universal Time)"
 There are two easy ways to run `ucconfig`:
 
 - **Download a Pre-packaged Binary:**
-    - Download from the Releases page. Note: On macOS, you will likely need to grant an exception to allow the binary to run.
+    - Download from the Releases page. _Note: On macOS, you will likely need to grant an exception to allow the binary to run._
 - **Run with Docker:**
     - `docker run userclouds/ucconfig [ucconfig args described below...]`
     - Note: `docker run` may require additional flags to share environment variables or files with the container. See example commands in the Usage section.
@@ -155,10 +155,10 @@ resources:
 
 ```
 
-- If a resource has the same UUID in all of your tenants (e.g., you used `ucconfig` to create all resources in all your tenants), then specifying **`__DEFAULT` is sufficient, and you do not need to specify the ID for every tenant. `ucconfig` will use the **`__DEFAULT` key to match live tenant resources to manifest entries.
+- If a resource has the same UUID in all of your tenants (e.g., you used `ucconfig` to create all resources in all your tenants), then specifying `__DEFAULT` is sufficient, and you do not need to specify the ID for every tenant. `ucconfig` will use the `__DEFAULT` key to match live tenant resources to manifest entries.
 - However, if a resource exists with different UUIDs in different tenants (e.g., you already manually created an email column in your staging and production tenants, so they ended up with different IDs), you should list each ID here to ensure that `ucconfig` will match the correct live resources.
 
-When creating a new resource, `ucconfig` will create it with the`__DEFAULT` UUID.
+When creating a new resource, `ucconfig` will create it with the `__DEFAULT` UUID.
 
 ### Functions
 
diff --git a/content/docs/guides/(deployment)/set-up-guides/eks-set-up-guide.mdx b/content/docs/guides/(deployment)/set-up-guides/eks-set-up-guide.mdx
@@ -27,7 +27,7 @@ This guide assumes that you are generally familiar with helm usage and have your
 2. **Create AWS IAM role for the UserClouds software to use.**
    The IAM role should use EKS IRSA
    The following AWS permissions are required by the Userclouds software:
-    1. Access to AWS secrets manager - for the DB password mentioned in the previous section. The Userclouds software will also write some secrets to the AWS Secrets manager (mostly DB credentials for databases created on the RDS instance)
+    1. Access to AWS secrets manager: for the DB password mentioned in the previous section. The Userclouds software will also write some secrets to the AWS Secrets manager (mostly DB credentials for databases created on the RDS instance)
 3. **Add the UserClouds helm chart repo**
    helm repo add userclouds [https://userclouds.github.io/helm-charts](https://userclouds.github.io/helm-charts)
 4. **Ensure your Kubernetes cluster has a secret to authenticate to container registry**
diff --git a/content/docs/guides/(deployment)/set-up-guides/vpc-peering-set-up-guide.mdx b/content/docs/guides/(deployment)/set-up-guides/vpc-peering-set-up-guide.mdx
@@ -18,4 +18,4 @@ Peering VPCs is currently a manual process involving several steps:
 3. Create a peering request by following the AWS instructions here.
 4. UserClouds’ infrastructure team will accept the request
 5. Configure the appropriate route tables to ensure data is routed correctly across the peering connection
-6. \_(optional) \_Configure internal DNS to point across the VPC peering connection. If you aren’t already running internal DNS, UserClouds can repoint our public DNS to make this work.
+6. _(optional)_ Configure internal DNS to point across the VPC peering connection. If you aren’t already running internal DNS, UserClouds can repoint our public DNS to make this work.
