diff --git a/technical-reports/format/aliases.md b/technical-reports/format/aliases.md
index dddff0d4..eab54835 100644
--- a/technical-reports/format/aliases.md
+++ b/technical-reports/format/aliases.md
@@ -1,4 +1,4 @@
-# Aliases / references
+# Aliases / References
 
 Instead of having explicit values, tokens can reference the value of another token. To put it another way, a token can be an alias for another token. This spec considers the terms "alias" and "reference" to be synonyms and uses them interchangeably.
 
@@ -6,35 +6,440 @@ Aliases are useful for:
 
 - Expressing design choices
 - Eliminating repetition of values in token files (DRYing up the code)
+- Creating semantic relationships between tokens
+- Maintaining consistency across related values
 
-For a design token to reference another, its value MUST be a string containing the period-separated (`.`) path to the token it's referencing enclosed in curly brackets.
+## Reference Syntax
 
-For example:
+Design tokens support two distinct syntaxes for referencing content within token files:
+
+### Curly Brace Syntax (Token References)
+
+The curly brace syntax is specifically designed for referencing **complete token values** and always resolves to the `$value` property of the target token.
+
+<aside class="example">
+
+```json
+{
+  "colors": {
+    "blue": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0, 0.4, 0.8],
+        "hex": "#0066cc"
+      },
+      "$type": "color"
+    }
+  },
+  "semantic": {
+    "primary": {
+      "$value": "{colors.blue}",
+      "$type": "color"
+    }
+  }
+}
+```
+
+</aside>
+
+In this example, `{colors.blue}` resolves to the entire color object `{"colorSpace": "srgb", "components": [0, 0.4, 0.8], "hex": "#0066cc"}`.
+
+**Important:** Curly brace references can ONLY target complete tokens (objects with `$value` properties), not individual properties within token values or arbitrary document locations.
+
+### JSON Pointer Syntax (Required Support)
+
+For advanced use cases requiring access to specific properties within token values or other parts of the document structure, tokens MUST support JSON Pointer notation as defined by [[rfc6901]], using the `$ref` property. Tools implementing this specification MUST support JSON Pointer syntax.
 
 <aside class="example">
 
 ```json
 {
-  "group name": {
-    "token name": {
-      "$value": 1234,
+  "colors": {
+    "blue": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0, 0.4, 0.8],
+        "hex": "#0066cc"
+      },
+      "$type": "color"
+    }
+  },
+  "semantic": {
+    "primary": {
+      "$ref": "#/colors/blue/$value",
+      "$type": "color"
+    },
+    "primaryHue": {
+      "$ref": "#/colors/blue/$value/components/0",
       "$type": "number"
     }
+  }
+}
+```
+
+</aside>
+
+In this example:
+
+- `"$ref": "#/colors/blue/$value"` is equivalent to `"{colors.blue}"`
+- `"$ref": "#/colors/blue/$value/components/0"` accesses just the red component (0) of the blue color
+
+**Key Differences:**
+
+| Aspect            | Curly Brace `{token}`     | JSON Pointer `$ref`         |
+| ----------------- | ------------------------- | --------------------------- |
+| **Targets**       | Complete tokens only      | Any document location       |
+| **Implicit path** | Always appends `/$value`  | Explicit full path required |
+| **Use case**      | Token-to-token references | Property-level references   |
+| **Syntax**        | `{group.token}`           | `#/group/token/$value`      |
+
+## Reference Resolution
+
+When a tool needs the actual value of a token it MUST resolve the reference - i.e. lookup the token being referenced and fetch its value. Tools SHOULD preserve references and therefore only resolve them whenever the actual value needs to be retrieved. For instance, in a [=design tool=], changes to the value of a token being referenced by aliases SHOULD be reflected wherever those aliases are being used.
+
+### Resolution Algorithms
+
+**For Curly Brace References:**
+
+1. **Parse reference:** Extract token path from `{group.token}`
+2. **Split path:** Convert to segments `["group", "token"]`
+3. **Navigate to token:** Find the target token object
+4. **Validate token:** Ensure target has `$value` property
+5. **Return token value:** Extract and return the `$value` content
+6. **Check for cycles:** Maintain stack of resolving references
+
+**For JSON Pointer References:**
+
+1. **Parse JSON Pointer:** Extract path segments from `#/path/to/target`
+2. **Traverse document:** Navigate through each path segment
+3. **Apply JSON Pointer rules:**
+   - Numeric segments in array contexts become array indices
+   - All segments in object contexts become property names
+   - Handle escaped characters (`~0`, `~1`)
+4. **Validate target:** Ensure the final target exists and is accessible
+5. **Return value:** Extract and return the resolved value
+
+### Chained References
+
+Aliases MAY reference other aliases. In this case, tools MUST follow each reference until they find a token with an explicit value.
+
+<aside class="example">
+
+```json
+{
+  "base": {
+    "primary": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0, 0.4, 0.8],
+        "hex": "#0066cc"
+      },
+      "$type": "color"
+    }
   },
-  "alias name": {
-    "$value": "{group name.token name}"
+  "semantic": {
+    "brand": {
+      "$value": "{base.primary}"
+    },
+    "link": {
+      "$value": "{semantic.brand}"
+    }
   }
 }
 ```
 
 </aside>
 
-When a tool needs the actual value of a token it MUST resolve the reference - i.e. lookup the token being referenced and fetch its value. In the above example, the "alias name" token's value would resolve to 1234 because it references the token whose path is `{group name.token name}` which has the value 1234.
+In this example, `{semantic.link}` resolves to the same color value as `{base.primary}` by following the chain: `semantic.link` → `semantic.brand` → `base.primary`.
+
+### Circular References
+
+Circular references are not allowed. If a design token file contains circular references, then the value of all tokens in that chain is unknown and an appropriate error or warning message SHOULD be displayed to the user.
+
+<aside class="example">
+
+```json
+{
+  "a": { "$value": "{b}" },
+  "b": { "$value": "{c}" },
+  "c": { "$value": "{a}" } // Creates circular reference: a → b → c → a
+}
+```
+
+</aside>
+
+Tools MUST detect and report this as an error affecting all tokens in the circular chain.
+
+## Property-Level References
+
+JSON Pointer syntax enables references to specific properties within composite tokens, not just entire token values. This enables fine-grained reuse of token components while maintaining semantic relationships.
+
+**Important:** Property-level references require JSON Pointer syntax (`$ref`) and cannot be expressed using curly brace syntax.
+
+### Color Component References
+
+<aside class="example">
+
+```json
+{
+  "base": {
+    "blue": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0.2, 0.4, 0.9],
+        "hex": "#3366e6"
+      },
+      "$type": "color"
+    }
+  },
+  "semantic": {
+    "primary": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [
+          { "$ref": "#/base/blue/$value/components/0" },
+          { "$ref": "#/base/blue/$value/components/1" },
+          0.7
+        ],
+        "hex": "#3366b3"
+      },
+      "$type": "color"
+    },
+    "secondary": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [
+          { "$ref": "#/base/blue/$value/components/0" },
+          { "$ref": "#/base/blue/$value/components/1" },
+          0.5
+        ],
+        "hex": "#336680"
+      },
+      "$type": "color"
+    }
+  }
+}
+```
+
+</aside>
+
+In this example:
+
+- `semantic.primary` keeps the same red and green components as `base.blue` but uses a different blue component (0.7)
+- `semantic.secondary` keeps the same red and green components as `base.blue` but uses a different blue component (0.5)
+- Changes to the hue of `base.blue` will automatically propagate to both semantic colors
+
+### Dimension Component References
+
+<aside class="example">
+
+```json
+{
+  "base": {
+    "spacing": {
+      "$value": { "value": 16, "unit": "px" },
+      "$type": "dimension"
+    }
+  },
+  "layout": {
+    "small": {
+      "$value": {
+        "value": { "$ref": "#/base/spacing/$value/value" },
+        "unit": "rem"
+      },
+      "$type": "dimension"
+    },
+    "large": {
+      "$value": {
+        "value": 32,
+        "unit": { "$ref": "#/base/spacing/$value/unit" }
+      },
+      "$type": "dimension"
+    }
+  }
+}
+```
+
+</aside>
+
+In this example:
+
+- `layout.small` uses the same numeric value as `base.spacing` (16) but with a different unit (`rem`)
+- `layout.large` uses the same unit as `base.spacing` (`px`) but with a different numeric value (32)
+
+### Typography Component References
+
+<aside class="example">
+
+```json
+{
+  "base": {
+    "text": {
+      "$value": {
+        "fontFamily": ["Helvetica", "Arial", "sans-serif"],
+        "fontSize": { "value": 16, "unit": "px" },
+        "fontWeight": 400,
+        "lineHeight": 1.5
+      },
+      "$type": "typography"
+    }
+  },
+  "headings": {
+    "h1": {
+      "$value": {
+        "fontFamily": { "$ref": "#/base/text/$value/fontFamily" },
+        "fontSize": { "value": 32, "unit": "px" },
+        "fontWeight": 700,
+        "lineHeight": { "$ref": "#/base/text/$value/lineHeight" }
+      },
+      "$type": "typography"
+    },
+    "h2": {
+      "$value": {
+        "fontFamily": { "$ref": "#/base/text/$value/fontFamily" },
+        "fontSize": { "value": 24, "unit": "px" },
+        "fontWeight": 600,
+        "lineHeight": { "$ref": "#/base/text/$value/lineHeight" }
+      },
+      "$type": "typography"
+    }
+  }
+}
+```
+
+</aside>
+
+In this example:
+
+- Both headings inherit the `fontFamily` and `lineHeight` from `base.text`
+- Each heading defines its own `fontSize` and `fontWeight`
+- Changes to the base font family or line height automatically affect all headings
+
+## JSON Pointer Path Construction and Resolution
+
+JSON Pointer syntax provides direct access to any location within the design token document structure, following standard JSON Pointer rules as defined by [[rfc6901]].
+
+### Path Construction Rules
+
+- **Root reference:** `#/` (refers to the document root)
+- **Object properties:** `/` separates each level (e.g., `#/group/token/$value`)
+- **Array indices:** Numeric indices for array elements (e.g., `#/color/$value/components/0`)
+- **Special characters:** Must be escaped according to JSON Pointer rules:
+  - `~` becomes `~0`
+  - `/` becomes `~1`
+
+### Token Value Access Patterns
+
+Since design tokens store their values in `$value` properties, JSON Pointer paths to token values follow a predictable pattern:
+
+| JSON Pointer                        | Equivalent Curly Brace Reference | Description              |
+| ----------------------------------- | -------------------------------- | ------------------------ |
+| `#/colors/blue/$value`              | `{colors.blue}`                  | Complete token value     |
+| `#/colors/blue/$value/hex`          | N/A                              | Hex property of color    |
+| `#/colors/blue/$value/components/0` | N/A                              | First component of color |
+| `#/colors/blue/$type`               | N/A                              | Token type metadata      |
+
+### Resolution Algorithm for JSON Pointer
+
+1. **Parse JSON Pointer:** Extract path segments from `#/path/to/target`
+2. **Traverse document:** Navigate through each path segment
+3. **Apply JSON Pointer rules:**
+   - Numeric segments in array contexts become array indices
+   - All segments in object contexts become property names
+   - Handle escaped characters (`~0`, `~1`)
+4. **Validate target:** Ensure the final target exists and is accessible
+5. **Return value:** Extract and return the resolved value
+
+### Curly Brace Resolution Algorithm
+
+1. **Parse reference:** Extract token path from `{group.token}`
+2. **Split path:** Convert to segments `["group", "token"]`
+3. **Navigate to token:** Find the target token object
+4. **Validate token:** Ensure target has `$value` property
+5. **Return token value:** Extract and return the `$value` content
+6. **Check for cycles:** Maintain stack of resolving references
+
+### Error Conditions
+
+Tools MUST report errors for:
+
+- **Invalid syntax:** Malformed curly braces or JSON Pointer syntax
+- **Unresolvable paths:** Target path does not exist in document
+- **Invalid token references:** Curly brace syntax targeting non-tokens
+- **Circular references:** Reference chains that loop back to themselves
+- **Type mismatches:** Referenced value incompatible with expected type
+
+### Path Examples
+
+| Token Path           | JSON Pointer             | Curly Brace Syntax       |
+| -------------------- | ------------------------ | ------------------------ |
+| Root token "primary" | `#/primary`              | `{primary}`              |
+| Nested token         | `#/colors/blue`          | `{colors.blue}`          |
+| Array element        | `#/color/components/0`   | not supported            |
+| Property with space  | `#/brand colors/primary` | `{brand colors.primary}` |
+| Property with slash  | `#/my~1group/token`      | `{my/group.token}`       |
+
+## Implementation Guidance
+
+### For Tool Authors
+
+Tools implementing design token parsing MUST:
+
+1. **Support curly brace syntax** as the primary reference mechanism for token-to-token references
+2. **Support JSON Pointer syntax** for document-level references and property access
+3. **Validate reference targets** to ensure they point to valid tokens (for curly brace) or valid document locations (for JSON Pointer)
+4. **Resolve references** according to the resolution algorithms defined in this specification ([Resolution Algorithms](#resolution-algorithms))
+5. **Detect circular references** before attempting resolution
+6. **Preserve references** in memory/storage and resolve only when values are needed
+7. **Propagate changes** from referenced tokens to all aliases
+
+### Disambiguation Examples
+
+<aside class="example">
+
+```json
+{
+  "ambiguous": {
+    "data": [10, 20, 30],
+    "metadata": {
+      "0": "Info about first item",
+      "1": "Info about second item"
+    }
+  }
+}
+```
+
+</aside>
+
+**Clear resolution:**
+
+| Reference                | Result                    | Notes                                    |
+| :----------------------- | :------------------------ | :--------------------------------------- |
+| `#/ambiguous/data/0`     | `10`                      | JSON Pointer array index                 |
+| `{ambiguous.metadata.0}` | `"Info about first item"` | curly brace object property              |
+| `{ambiguous.data.0}`     | Error                     | curly braces cannot access array indices |
+| `{ambiguous.metadata.2}` | Error                     | property "2" doesn't exist               |
+
+### Error Conditions
+
+Tools MUST report errors for:
+
+- **Invalid reference syntax:** Malformed curly braces or JSON Pointer syntax
+- **Unresolvable references:** Target path does not exist
+- **Circular references:** Reference chains that loop back to themselves
+- **Type mismatches:** Referenced property type incompatible with token type
+- **Invalid property paths:** Attempting to reference non-existent properties
+
+## Relationship to JSON Schema
+
+The reference syntax defined in this specification provides compatibility with JSON Schema patterns while serving the specific needs of design token authoring:
+
+- **JSON Pointer compatibility:** Direct support for RFC 6901 JSON Pointer notation enables integration with JSON Schema tooling
+- **Design token semantics:** Curly brace references provide token-specific syntax optimized for common token-to-token relationships
+- **Complementary approaches:** Both syntaxes serve different use cases within the design token ecosystem
 
-Tools SHOULD preserve references and therefore only resolve them whenever the actual value needs to be retrieved. For instance, in a [=design tool=], changes to the value of a token being referenced by aliases SHOULD be reflected wherever those aliases are being used.
+**Important:** While JSON Pointer references (`$ref`) in design tokens follow the same syntax as JSON Schema `$ref`, curly brace references (`{token}`) are design token-specific and provide different semantics (automatic `$value` resolution and token-only targeting) compared to standard JSON Schema references.
 
-Aliases MAY reference other aliases. In this case, tools MUST follow each reference until they find a token with an explicit value. Circular references are not allowed. If a design token file contains circular references, then the value of all tokens in that chain is unknown and an appropriate error or warning message SHOULD be displayed to the user.
+---
 
-<p class="ednote" title="JSON Pointer syntax">
-  The format editors are currently researching JSON Pointer syntax to inform the exact syntax for aliases in tokens. <a href="https://datatracker.ietf.org/doc/html/rfc6901#section-5">https://datatracker.ietf.org/doc/html/rfc6901#section-5</a>
-</p>
+_This specification provides a flexible, standards-based approach to token references that balances author ergonomics with technical precision, enabling both simple token aliases and sophisticated property-level relationships._
diff --git a/technical-reports/format/composite-types.md b/technical-reports/format/composite-types.md
index 2b21096e..46f43da5 100644
--- a/technical-reports/format/composite-types.md
+++ b/technical-reports/format/composite-types.md
@@ -2,14 +2,45 @@
 
 The types defined in the previous chapters such as color and dimension all have singular values. For example, the value of a color token is _one_ color. However, there are other aspects of UI designs that are a combination of multiple values. For instance, a shadow style is a combination of a color, X & Y offsets, a blur radius and a spread radius.
 
-Every shadow style has the exact same parts (color, X & Y offsets, etc.), but their respective values will differ. Furthermore, each part's value (which is also known as a "sub-value") is always of the same type. A shadow's color must always be a [color](#color) value, its X offset must always be a [dimension](#dimension) value, and so on. Shadow styles are therefore combinations of values _that follow a pre-defined structure_. In other words, shadow styles are themselves a type. Types like this are called **composite types**.
+Every shadow style has the exact same parts (color, X & Y offsets, etc.), but their respective values will differ. Furthermore, each part's value (which is also known as a "sub-value") is always of the same type. A shadow's color must always be a [color](#color) value, its X offset must always be a [dimension](types#dimension) value, and so on. Shadow styles are therefore combinations of values _that follow a pre-defined structure_. In other words, shadow styles are themselves a type. Types like this are called **composite types**.
 
 Specifically, a composite type has the following characteristics:
 
 - Its value is an object or array, potentially containing nested objects or arrays, following a pre-defined structure where the properties of the (nested) object(s) or the elements of the (nested) arrays are sub-values.
-- Sub-values may be explicit `color` values or references to other design tokens that have sub-value's type (e.g. `"{some.other.token}"`).
+- Sub-values may be explicit values (e.g. `color` values) or references to other design tokens that have the sub-value's type (e.g. `"{some.other.token}"`).
 
-A design token whose type happens to be a composite type is sometimes also called a composite (design) token. Besides their type, there is nothing special about composite tokens. They can have all the other additional properties like [`$description`](#description) or [`$extensions`](#extensions). They can also be referenced by other design tokens.
+### Array aliasing in composite types
+
+When a composite type contains array properties, each element in the array may be either an explicit value or a reference to a token of the appropriate type. References in arrays resolve to single values and do not cause array expansion or flattening. This allows for flexible composition where some array elements are references while others are explicit values.
+
+Array aliasing follows these principles:
+
+1. **Single value resolution**: References in arrays always resolve to a single value of the appropriate type, never to arrays themselves.
+2. **No flattening**: When referencing an array, the entire referenced array is treated as a single element in the referencing array.
+3. **Type safety**: Each array element (explicit or referenced) must conform to the expected sub-value type for that composite type.
+4. **Mixed composition**: Arrays may freely mix explicit values and references.
+
+For example, a shadow token with an array value can mix references to other shadow tokens with explicit shadow objects:
+
+```json
+{
+  "layered-shadow": {
+    "$type": "shadow",
+    "$value": [
+      "{base.shadow}",
+      {
+        "color": "{brand.accent}",
+        "offsetX": { "value": 4, "unit": "px" },
+        "offsetY": { "value": 4, "unit": "px" },
+        "blur": { "value": 8, "unit": "px" },
+        "spread": { "value": 0, "unit": "px" }
+      }
+    ]
+  }
+}
+```
+
+A design token whose type happens to be a composite type is sometimes also called a composite (design) token. Besides their type, there is nothing special about composite tokens. They can have all the other additional properties like [`$description`](design-token#description) or [`$extensions`](design-token#extensions). They can also be referenced by other design tokens.
 
 <aside class="example" title="Composite token example">
 
@@ -19,13 +50,10 @@ A design token whose type happens to be a composite type is sometimes also calle
     "$type": "shadow",
     "$value": {
       "color": {
-        "$type": "color",
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 0, 0],
-          "alpha": 0.5,
-          "hex": "#000000"
-        }
+        "colorSpace": "srgb",
+        "components": [0, 0, 0],
+        "alpha": 0.5,
+        "hex": "#000000"
       },
       "offsetX": { "value": 0.5, "unit": "rem" },
       "offsetY": { "value": 0.5, "unit": "rem" },
@@ -92,7 +120,7 @@ A design token whose type happens to be a composite type is sometimes also calle
 
 At first glance, groups and composite tokens might look very similar. However, they are intended to solve different problems and therefore have some important differences:
 
-- **[Groups](#groups)** are for arbitrarily grouping tokens for the purposes of naming and/or organization.
+- **[Groups](groups)** are for arbitrarily grouping tokens for the purposes of naming and/or organization.
   - They impose no rules or restrictions on how many tokens or nested groups you put within them, what they are called, or what the types of the tokens within should be. As such, tools MUST NOT try to infer any special meaning or typing of tokens based on a group they happen to be in.
   - Different design systems are likely to group their tokens differently.
   - You can think of groups as containers that exist "outside" of design tokens.
@@ -144,7 +172,7 @@ These values have the same meaning as the equivalent ["line style" values in CSS
 
 Object stroke style values MUST have the following properties:
 
-- `dashArray`: An array of [dimension values](#dimension) and/or references to dimension tokens, which specify the lengths of alternating dashes and gaps. If an odd number of values is provided, then the list of values is repeated to yield an even number of values.
+- `dashArray`: An array of [dimension values](types#dimension) and/or references to dimension tokens, which specify the lengths of alternating dashes and gaps. Each element in the array must be either an explicit dimension value or a reference to a dimension token. If an odd number of values is provided, then the list of values is repeated to yield an even number of values.
 - `lineCap`: One of the following pre-defined string values: `"round"`, `"butt"` or `"square"`. These values have the same meaning as those of [the `stroke-linecap` attribute in SVG](https://www.w3.org/TR/SVG11/painting.html#StrokeLinecapProperty).
 
 <aside class="example" title="Object stroke style example">
@@ -178,12 +206,35 @@ Object stroke style values MUST have the following properties:
     }
   },
 
+  "mixed-dash-style": {
+    "$type": "strokeStyle",
+    "$value": {
+      "dashArray": [
+        "{dash-length-long}",
+        "{dash-gap-short}",
+        { "value": 0.125, "unit": "rem" },
+        "{dash-gap-short}"
+      ],
+      "lineCap": "round"
+    }
+  },
+
   "dash-length-medium": {
     "$type": "dimension",
     "$value": {
       "value": 10,
       "unit": "px"
     }
+  },
+
+  "dash-length-long": {
+    "$type": "dimension",
+    "$value": { "value": 1, "unit": "rem" }
+  },
+
+  "dash-gap-short": {
+    "$type": "dimension",
+    "$value": { "value": 0.25, "unit": "rem" }
   }
 }
 ```
@@ -220,8 +271,8 @@ Some [=design tools=] like Figma don't support inset, outset or double style lin
 
 Represents a border style. The `$type` property MUST be set to the string `border`. The value MUST be an object with the following properties:
 
-- `color`: The color of the border. The value of this property MUST be a valid [color value](#color) or a reference to a color token.
-- `width`: The width or thickness of the border. The value of this property MUST be a valid [dimension value](#dimension) or a reference to a dimension token.
+- `color`: The color of the border. The value of this property MUST be a valid [color value](types#color) or a reference to a color token.
+- `width`: The width or thickness of the border. The value of this property MUST be a valid [dimension value](types#dimension) or a reference to a dimension token.
 - `style`: The border's style. The value of this property MUST be a valid [stroke style value](#stroke-style) or a reference to a stroke style token.
 
 <aside class="example" title="Border composite token examples">
@@ -233,11 +284,8 @@ Represents a border style. The `$type` property MUST be set to the string `borde
       "$type": "border",
       "$value": {
         "color": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [0.218, 0.218, 0.218]
-          }
+          "colorSpace": "srgb",
+          "components": [0.218, 0.218, 0.218]
         },
         "width": {
           "value": 3,
@@ -277,9 +325,9 @@ Represents a border style. The `$type` property MUST be set to the string `borde
 
 Represents a animated transition between two states. The `$type` property MUST be set to the string `transition`. The value MUST be an object with the following properties:
 
-- `duration`: The duration of the transition. The value of this property MUST be a valid [duration](#duration) value or a reference to a duration token.
-- `delay`: The time to wait before the transition begins. The value of this property MUST be a valid [duration](#duration) value or a reference to a duration token.
-- `timingFunction`: The timing function of the transition. The value of this property MUST be a valid [cubic bézier](#cubic-bezier) value or a reference to a cubic bézier token.
+- `duration`: The duration of the transition. The value of this property MUST be a valid [duration](types#duration) value or a reference to a duration token.
+- `delay`: The time to wait before the transition begins. The value of this property MUST be a valid [duration](types#duration) value or a reference to a duration token.
+- `timingFunction`: The timing function of the transition. The value of this property MUST be a valid [cubic bézier](types#cubic-bezier) value or a reference to a cubic bézier token.
 
 <aside class="example" title="Transition composite token examples">
 
@@ -306,13 +354,20 @@ Represents a animated transition between two states. The `$type` property MUST b
 
 ## Shadow
 
-Represents a shadow style. The `$type` property MUST be set to the string `shadow`. The value MUST contain a single object or an array of objects with the following properties:
+Represents a shadow style. The `$type` property MUST be set to the string `shadow`. The value MUST be either:
+
+- a single shadow object with the properties defined below, or
+- an array of shadow objects and/or references to shadow tokens
 
-- `color`: The color of the shadow. The value of this property MUST be a valid [color value](#color) or a reference to a color token.
-- `offsetX`: The horizontal offset that shadow has from the element it is applied to. The value of this property MUST be a valid [dimension value](#dimension) or a reference to a dimension token.
-- `offsetY`: The vertical offset that shadow has from the element it is applied to. The value of this property MUST be a valid [dimension value](#dimension) or a reference to a dimension token.
-- `blur`: The blur radius that is applied to the shadow. The value of this property MUST be a valid [dimension value](#dimension) or a reference to a dimension token.
-- `spread`: The amount by which to expand or contract the shadow. The value of this property MUST be a valid [dimension value](#dimension) or a reference to a dimension token.
+When the value is an array, each element must be either an explicit shadow object or a reference to another shadow token. References in the array resolve to single shadow objects and do not cause array flattening.
+
+Each shadow object (whether explicit or referenced) MUST have the following properties:
+
+- `color`: The color of the shadow. The value of this property MUST be a valid [color value](types#color) or a reference to a color token.
+- `offsetX`: The horizontal offset that shadow has from the element it is applied to. The value of this property MUST be a valid [dimension value](types#dimension) or a reference to a dimension token.
+- `offsetY`: The vertical offset that shadow has from the element it is applied to. The value of this property MUST be a valid [dimension value](types#dimension) or a reference to a dimension token.
+- `blur`: The blur radius that is applied to the shadow. The value of this property MUST be a valid [dimension value](types#dimension) or a reference to a dimension token.
+- `spread`: The amount by which to expand or contract the shadow. The value of this property MUST be a valid [dimension value](types#dimension) or a reference to a dimension token.
 - `inset`: (optional) Whether this shadow is inside the containing shape (“inner shadow”), rather than a “drop shadow” or “box shadow” which is rendered outside the container (default, or `false`).
 
 <aside class="example" title="Shadow token example">
@@ -323,12 +378,9 @@ Represents a shadow style. The `$type` property MUST be set to the string `shado
     "$type": "shadow",
     "$value": {
       "color": {
-        "$type": "color",
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 0, 0],
-          "alpha": 0.5,
-        }
+        "colorSpace": "srgb",
+        "components": [0, 0, 0],
+        "alpha": 0.5
       },
       "offsetX": { "value": 0.5, "unit": "rem" },
       "offsetY": { "value": 0.5, "unit": "rem" },
@@ -341,12 +393,9 @@ Represents a shadow style. The `$type` property MUST be set to the string `shado
   "$value": [
     {
       "color": {
-        "$type": "color",
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 0, 0],
-          "alpha": 0.1,
-        }
+        "colorSpace": "srgb",
+        "components": [0, 0, 0],
+        "alpha": 0.1
       },
       "offsetX": { "value": 0, "unit": "px" },
       "offsetY": { "value": 24, "unit": "px" },
@@ -355,12 +404,9 @@ Represents a shadow style. The `$type` property MUST be set to the string `shado
     },
     {
       "color": {
-        "$type": "color",
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 0, 0],
-          "alpha": 0.2,
-        }
+        "colorSpace": "srgb",
+        "components": [0, 0, 0],
+        "alpha": 0.2
       },
       "offsetX": { "value": 0, "unit": "px" },
       "offsetY": { "value": 42.9, "unit": "px" },
@@ -369,12 +415,9 @@ Represents a shadow style. The `$type` property MUST be set to the string `shado
     },
     {
       "color": {
-        "$type": "color",
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 0, 0],
-          "alpha": 0.3,
-        }
+        "colorSpace": "srgb",
+        "components": [0, 0, 0],
+        "alpha": 0.3
       },
       "offsetX": { "value": 0, "unit": "px" },
       "offsetY": { "value": 64, "unit": "px" },
@@ -382,17 +425,29 @@ Represents a shadow style. The `$type` property MUST be set to the string `shado
       "spread": { "value": 0, "unit": "px" }
     }
   ]
+},
+
+"mixed-reference-shadow": {
+  "$type": "shadow",
+  "$value": [
+    "{base.shadow}",
+    {
+      "color": "{brand.accent}",
+      "offsetX": { "value": 2, "unit": "px" },
+      "offsetY": { "value": 2, "unit": "px" },
+      "blur": { "value": 4, "unit": "px" },
+      "spread": { "value": 1, "unit": "px" }
+    },
+    "{highlight.shadow}"
+  ]
 }
 "inner-shadow": {
   "$type": "shadow",
   "$value": {
     "color": {
-      "$type": "color",
-      "$value": {
-        "colorSpace": "srgb",
-        "components": [0, 0, 0],
-        "alpha": 0.5,
-      }
+      "colorSpace": "srgb",
+      "components": [0, 0, 0],
+      "alpha": 0.5
     },
     "offsetX": { "value": 2, "unit": "px" },
     "offsetY": { "value": 2, "unit": "px" },
@@ -412,9 +467,11 @@ Represents a shadow style. The `$type` property MUST be set to the string `shado
 
 ## Gradient
 
-Represents a color gradient. The `$type` property MUST be set to the string `gradient`. The value MUST be an array of objects representing gradient stops that have the following structure:
+Represents a color gradient. The `$type` property MUST be set to the string `gradient`. The value MUST be an array of gradient stop objects and/or references to gradient tokens. Each element in the array must be either an explicit gradient stop object or a reference to a gradient token. References resolve to single gradient objects and do not cause array flattening.
 
-- `color`: The color value at the stop's position on the gradient. The value of this property MUST be a valid [color value](#color) or a reference to a color token.
+Each gradient stop object (whether explicit or referenced) MUST have the following structure:
+
+- `color`: The color value at the stop's position on the gradient. The value of this property MUST be a valid [color value](types#color) or a reference to a color token.
 - `position`: The position of the stop along the gradient's axis. The value of this property MUST be a valid number value or reference to a number token. The number values must be in the range [0, 1], where 0 represents the start position of the gradient's axis and 1 the end position. If a number value outside of that range is given, it MUST be considered as if it were clamped to the range [0, 1]. For example, a value of 42 should be treated as if it were 1, i.e. the end position of the gradient axis. Similarly, a value of -99 should be treated as if it were 0, i.e. the start position of the gradient axis.
 
 If there are no stops at the very beginning or end of the gradient axis (i.e. with `position` 0 or 1, respectively), then the color from the stop closest to each end should be extended to that end of the axis.
@@ -428,22 +485,16 @@ If there are no stops at the very beginning or end of the gradient axis (i.e. wi
     "$value": [
       {
         "color": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [0, 0, 1],
-          }
+          "colorSpace": "srgb",
+          "components": [0, 0, 1]
         },
         "position": 0
       },
       {
         "color": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [1, 0, 0],
-          }
-        }
+          "colorSpace": "srgb",
+          "components": [1, 0, 0]
+        },
         "position": 1
       }
     ]
@@ -466,21 +517,15 @@ Describes a gradient that goes from blue to red:
     "$value": [
       {
         "color": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [1, 1, 0]
-          }
+          "colorSpace": "srgb",
+          "components": [1, 1, 0]
         },
         "position": 0.666
       },
       {
         "color": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [1, 0, 0]
-          }
+          "colorSpace": "srgb",
+          "components": [1, 0, 0]
         },
         "position": 1
       }
@@ -517,11 +562,8 @@ Describes a gradient that is solid yellow for the first 2/3 and then fades to re
     "$value": [
       {
         "color": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [0, 0, 0]
-          }
+          "colorSpace": "srgb",
+          "components": [0, 0, 0]
         },
         "position": 0
       },
@@ -531,15 +573,45 @@ Describes a gradient that is solid yellow for the first 2/3 and then fades to re
       },
       {
         "color": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [0, 0, 0]
-          }
+          "colorSpace": "srgb",
+          "components": [0, 0, 0]
         },
         "position": "{position-end}"
       }
     ]
+  },
+
+  "gradient-with-references": {
+    "$type": "gradient",
+    "$value": [
+      "{gradient.start-stop}",
+      {
+        "color": "{brand.secondary}",
+        "position": 0.333
+      },
+      "{gradient.end-stop}"
+    ]
+  },
+
+  "gradient": {
+    "start-stop": {
+      "$type": "gradient",
+      "$value": [
+        {
+          "color": { "colorSpace": "srgb", "components": [1, 1, 1] },
+          "position": 0
+        }
+      ]
+    },
+    "end-stop": {
+      "$type": "gradient",
+      "$value": [
+        {
+          "color": { "colorSpace": "srgb", "components": [0, 0, 0] },
+          "position": 1
+        }
+      ]
+    }
   }
 }
 ```
@@ -558,11 +630,11 @@ Describes a color token called "brand-primary", which is referenced as the mid-p
 
 Represents a typographic style. The `$type` property MUST be set to the string `typography`. The value MUST be an object with the following properties:
 
-- `fontFamily`: The typography's font. The value of this property MUST be a valid [font family value](#font-family) or a reference to a font family token.
-- `fontSize`: The size of the typography. The value of this property MUST be a valid [dimension value](#dimension) or a reference to a dimension token.
-- `fontWeight`: The weight of the typography. The value of this property MUST be a valid [font weight](#font-weight) or a reference to a font weight token.
-- `letterSpacing`: The horizontal spacing between characters. The value of this property MUST be a valid [dimension value](#dimension) or a reference to a dimension token.
-- `lineHeight`: The vertical spacing between lines of typography. The value of this property MUST be a valid [number value](#number) or a reference to a number token. The number SHOULD be interpreted as a multiplier of the `fontSize`.
+- `fontFamily`: The typography's font. The value of this property MUST be a valid [font family value](types#font-family) or a reference to a font family token.
+- `fontSize`: The size of the typography. The value of this property MUST be a valid [dimension value](types#dimension) or a reference to a dimension token.
+- `fontWeight`: The weight of the typography. The value of this property MUST be a valid [font weight](types#font-weight) or a reference to a font weight token.
+- `letterSpacing`: The horizontal spacing between characters. The value of this property MUST be a valid [dimension value](types#dimension) or a reference to a dimension token.
+- `lineHeight`: The vertical spacing between lines of typography. The value of this property MUST be a valid [number value](types#number) or a reference to a number token. The number SHOULD be interpreted as a multiplier of the `fontSize`.
 
 <aside class="example" title="Typography composite token examples">
 
diff --git a/technical-reports/format/design-token.md b/technical-reports/format/design-token.md
index 6b46aa43..a0e87e4c 100644
--- a/technical-reports/format/design-token.md
+++ b/technical-reports/format/design-token.md
@@ -16,7 +16,7 @@
 }
 ```
 
-Note: The `$type` property has been added to ensure this example is valid. Please refer to the [design token type chapter](#type-0) for more details.
+Note: The `$type` property has been added to ensure this example is valid. Please refer to the [design token type chapter](#type) for more details.
 
 </aside>
 
@@ -73,18 +73,14 @@ Tools MAY display a warning when token names differ only by case.
 
 ### Character restrictions
 
-All properties defined by this format are prefixed with the dollar sign (`$`). This convention will also be used for any new properties introduced by future versions of this spec. Therefore, token and [group](#groups) names MUST NOT begin with the `$` character.
+All properties defined by this format are prefixed with the dollar sign (`$`). This convention will also be used for any new properties introduced by future versions of this spec. Therefore, token and [group](groups) names MUST NOT begin with the `$` character.
 
-Furthermore, due to the syntax used for [token aliases](#aliases-references) the following characters MUST NOT be used anywhere in a token or group name:
+Furthermore, due to the syntax used for [token aliases](groups#references-and-json-pointer-integration) the following characters MUST NOT be used anywhere in a token or group name:
 
 - `{` (left curly bracket)
 - `}` (right curly bracket)
 - `.` (period)
 
-<p class="ednote" title="'$' Prefix Rationale">
-  Because of the <a href="#additional-group-properties">decision to prefix group properties with a dollar sign</a> (`$`), token properties will also use a dollar sign prefix. This provides a consistent syntax across the spec.
-</p>
-
 ## Additional properties
 
 While `$value` is the only required property for a token, a number of additional properties MAY be added:
diff --git a/technical-reports/format/groups.md b/technical-reports/format/groups.md
index b2f1f54a..4c406710 100644
--- a/technical-reports/format/groups.md
+++ b/technical-reports/format/groups.md
@@ -1,32 +1,123 @@
 # Groups
 
-A file MAY contain many tokens and they MAY be nested arbitrarily in groups like so:
+Groups organize design tokens into logical collections and provide a hierarchical structure for token files. Groups are arbitrary and tools SHOULD NOT use them to infer the type or purpose of design tokens.
 
-<aside class="example">
+## Group Structure
+
+A group is identified as a JSON object that does NOT contain a [`$value`](design-token#name-and-value) property. Groups MAY contain:
+
+- **Child tokens** - Objects with a `$value` property
+- **Nested groups** - Objects without a `$value` property
+- **Group properties** - Properties prefixed with `$` (e.g., `$description`, `$type`)
+
+**Important:** The presence of a `$value` property definitively identifies an object as a token. If an object contains both `$value` and child tokens/groups, this creates an invalid structure where the object cannot be both a token and a group simultaneously. Tools MUST report this as an error.
+
+## Root Tokens in Groups
+
+Groups MAY contain a **root token** alongside child tokens and nested groups. A root token provides a base value for the group while allowing for variants or extensions.
+
+Groups support root tokens using the reserved name `$root` as the token name:
+
+<aside class="example" title="Root tokens">
+
+```jsonc
+{
+  "color": {
+    "accent": {
+      "$root": {
+        "$type": "color",
+        "$value": {
+          "colorSpace": "srgb",
+          "components": [0.867, 0, 0],
+          "hex": "#dd0000",
+        },
+        // {color.accent.$root} resolves to {"colorSpace": "srgb", "components": [0.867, 0, 0], "hex": "#dd0000"} (the root token)
+        // {color.accent} is an invalid token reference (refers to a group, not a token)
+      },
+      "light": {
+        "$type": "color",
+        "$value": {
+          "colorSpace": "srgb",
+          "components": [1, 0.133, 0.133],
+          "hex": "#ff2222",
+        },
+      },
+      "dark": {
+        "$type": "color",
+        "$value": {
+          "colorSpace": "srgb",
+          "components": [0.667, 0, 0],
+          "hex": "#aa0000",
+        },
+      },
+    },
+  },
+}
+```
+
+</aside>
+
+**Rationale:** Using `$root` as a reserved token name eliminates ambiguity between group references and token references while maintaining clear, explicit syntax. The `$` prefix prevents naming conflicts with user-defined tokens and aligns with other reserved properties in the specification.
+
+## Group Properties
+
+Groups MAY include the following properties:
+
+| Property       | Required | Description                                                                                                                                                                    |
+| -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `$description` | No       | A plain JSON string describing the group's purpose                                                                                                                             |
+| `$type`        | No       | Acts as a default type for tokens within the group that do not explicitly declare their own type. Type inheritance applies to nested groups and their tokens unless overridden |
+| `$extends`     | No       | Inherits tokens and properties from another group. See [Extending Groups](#extending-groups) for details                                                                       |
+| `$deprecated`  | No       | Marks the group as deprecated. Value can be `true`, `false`, or a string explanation                                                                                           |
+| `$extensions`  | No       | Vendor-specific extensions where tools MAY add proprietary data                                                                                                                |
+
+<aside class="example" title="Group description">
+
+```jsonc
+{
+  "spacing": {
+    "$description": "All spacing-related design tokens organized by usage context",
+    "margin": {
+      /* tokens */
+    },
+    "padding": {
+      /* tokens */
+    },
+  },
+}
+```
+
+</aside>
+
+<aside class="example" title="Group type inheritance">
 
 ```json
 {
-  "token uno": {
+  "color": {
     "$type": "color",
-    "$value": {
-      "colorSpace": "srgb",
-      "components": [0.07, 0.07, 0.07]
-    }
-  },
-  "token group": {
-    "token dos": {
-      "$value": { "value": 2, "unit": "rem" },
-      "$type": "dimension"
+    "primary": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0, 0.4, 0.8],
+        "hex": "#0066cc"
+      }
     },
-    "nested token group": {
-      "token tres": {
-        "$value": 33,
-        "$type": "number"
-      },
-      "Token cuatro": {
-        "$value": 444,
-        "$type": "fontWeight"
+    "secondary": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0.4, 0.6, 1],
+        "hex": "#6699ff"
       }
+    },
+    "semantic": {
+      "success": {
+        "$value": {
+          "colorSpace": "srgb",
+          "components": [0, 0.8, 0.4],
+          "hex": "#00cc66"
+        }
+      },
+      "warning": { "$type": "string", "$value": "amber" }
     }
   }
 }
@@ -34,237 +125,609 @@ A file MAY contain many tokens and they MAY be nested arbitrarily in groups like
 
 </aside>
 
-The names of the groups leading to a given token (including that token's name) are that token's _path_, which is a computed property. **It is not specified in the file**, but parsers that conform to this spec MUST be able to expose the path of a token. The above example, therefore, defines 4 design tokens with the following properties:
+### `$deprecated`
 
-- Token #1
-  - Name: "token uno"
-  - Path: "token uno"
-  - Value: { "colorSpace": "srgb", "components": [17, 17, 17] }
-  - Type: "color"
-- Token #2
-  - Name: "token dos"
-  - Path: "token group" / "token dos"
-  - Value: { "value": 2, "unit": "rem" }
-  - Type: "dimension"
-- Token #3
-  - Name: "token tres"
-  - Path: "token group" / "nested token group" / "token tres"
-  - Value: 33
-  - Type: "number"
-- Token #4
-  - Name: "token cuatro"
-  - Path: "token group" / "nested token group" / "token cuatro"
-  - Value: 444
-  - Type: "fontWeight"
+Groups MAY include an optional `$deprecated` property to mark the entire group as deprecated. This extends to all child tokens within the group unless explicitly overridden.
 
-Because groupings are arbitrary, tools MUST NOT use them to infer the type or purpose of design tokens.
+| Value    | Explanation                                                       |
+| -------- | ----------------------------------------------------------------- |
+| `true`   | This group is deprecated (no explanation provided)                |
+| `string` | This group is deprecated AND this is an explanation               |
+| `false`  | This group is NOT deprecated (may override parent group defaults) |
 
-Groups items (i.e. the tokens and/or nested groups) are unordered. In other words, there is no implicit order between items within a group. Therefore, tools that parse or write design token files are not required to preserve the source order of items in a group.
+### `$extensions`
 
-The names of items in a group are case sensitive. As per the guidance in the [design token chapter](#name-and-value), tools MAY display a warning to users when groups contain items whose names differ only in case and could therefore lead to naming clashes when exported.
+Groups MAY include an optional [`$extensions`](design-token#extensions) property where tools MAY add proprietary, user-, team- or vendor-specific data. Each tool MUST use a vendor-specific key whose value MAY be any valid JSON data.
 
-<p class="ednote" title="Naming practices">
-  The format editors acknowledge existing best-practices for token naming, but place no direct constraints on naming via the specification.
-</p>
+## Extending Groups
 
-## Additional group properties
+Groups MAY include an optional `$extends` property to inherit tokens and properties from another group. `$extends` MUST NOT reference a token. The `$extends` property is syntactic sugar for JSON Schema's `$ref` keyword and follows the same semantic behavior as defined in [[json-schema-2020-12]].
 
-<div class="ednote" title="Group properties vs. nested group and token names">
+<aside class="example" title="Group extension">
 
-To prevent collisions with token names, token properties are prefixed with a dollar sign (`$`). Using this prefix eliminates the need for a reserved words list and helps future-proof the spec.
+```json
+{
+  "button": {
+    "$type": "color",
+    "background": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0, 0.4, 0.8],
+        "hex": "#0066cc"
+      }
+    },
+    "text": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [1, 1, 1],
+        "hex": "#ffffff"
+      }
+    }
+  },
+  "button-primary": {
+    "$extends": "{button}",
+    "background": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0.8, 0, 0.4],
+        "hex": "#cc0066"
+      }
+    }
+  }
+}
+```
 
-Group keys without a dollar sign (`$`) prefix denote:
+</aside>
 
-- **A token name:** distinguishable by containing a `$value` property
+### Equivalence to JSON Schema `$ref`
 
-  ```json
-  {
-    "Group of tokens": {
-      "$description": "This is an example of a group containing a single token",
-      "Token name": {
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 0, 0]
-        }
+The `$extends` property is semantically equivalent to JSON Schema's `$ref` keyword as specified in [[json-schema-2020-12]] and later versions. The following two group definitions are functionally identical:
+
+**Using `$extends` (Design Token syntax):**
+
+```json
+{
+  "button-primary": {
+    "$extends": "{button}",
+    "background": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0.8, 0, 0.4],
+        "hex": "#cc0066"
+      }
+    },
+    "focus": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [1, 0.2, 0.6],
+        "hex": "#ff3399"
       }
     }
   }
-  ```
+}
+```
 
-- **A nested group name:** distinguishable by _not_ having a `$value` property
+**Using `$ref` (JSON Schema syntax):**
 
-  ```json
-  {
-    "Group of tokens": {
-      "$description": "This is an example of a group containing a nested group",
-      "Subgroup of tokens": {
-        "Token 1 name": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [0.667, 0.733, 0.8]
-          }
-        },
-        "Token 2 name": {
-          "$type": "color",
-          "$value": {
-            "colorSpace": "srgb",
-            "components": [0.867, 0.933, 1]
-          }
-        }
+```json
+{
+  "button-primary": {
+    "$ref": "#/button",
+    "background": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0.8, 0, 0.4],
+        "hex": "#cc0066"
+      }
+    },
+    "focus": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [1, 0.2, 0.6],
+        "hex": "#ff3399"
       }
     }
   }
-  ```
+}
+```
 
-</div>
+### Reference Resolution and Evaluation
 
-### Description
+Extension resolution follows a straightforward process:
 
-Groups MAY include an optional `$description` property, whose value MUST be a plain JSON string. Its purpose is to describe the group itself.
+1. **Find the target:** Resolve the `$extends` reference to locate the target group
+2. **Copy inherited content:** Start with all tokens and properties from the target group
+3. **Apply local overrides:** Replace any inherited tokens/properties where local ones exist at the same path
+4. **Add new content:** Include any local tokens/properties that don't exist in the inherited group
 
-For example:
+This creates a new resolved group that combines inherited and local content according to the override rules above.
 
-<aside class="example">
+<aside class="note" title="Implementation">
+While this specification references JSON Schema `$ref` behavior for technical implementation guidance, the user-visible behavior is the straightforward deep merge described above. Tools may implement this merge behavior directly or by leveraging JSON Schema libraries.
+</aside>
 
-```json
+### Inheritance Semantics
+
+Group extension follows **deep merge** behavior where local properties override inherited properties at the same path:
+
+1. **Inheritance:** All tokens and properties from the referenced group are inherited (circular references are not allowed)
+2. **Override:** Local tokens and properties replace inherited ones with the same path
+3. **Addition:** Local tokens and properties with new paths are added alongside inherited ones
+
+**Override Rules:**
+
+- **Same path = override:** If both the inherited group and local group define a token at the same path, the local definition wins
+- **Different paths = merge:** Tokens at different paths coexist in the final result
+- **Complete replacement:** When overriding, the entire token definition is replaced (not merged property-by-property)
+
+<aside class="example" title="Override example">
+
+```jsonc
 {
-  "brand": {
-    "$description": "Design tokens from our brand guidelines",
-    "color": {
-      "$description": "Our brand's primary color palette",
-      "acid green": {
-        "$type": "color",
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 1, 0.4]
-        }
+  "input": {
+    "field": {
+      "width": {
+        "$type": "dimension",
+        "$value": { "value": 12, "unit": "rem" },
       },
-      "hot pink": {
-        "$type": "color",
+      "background": {
         "$value": {
           "colorSpace": "srgb",
-          "components": [1, 0, 1]
-        }
-      }
-    }
+          "components": [1, 1, 1],
+          "hex": "#ffffff",
+        },
+      },
+    },
+  },
+  "input-amount": {
+    "$extends": "{input}",
+    "field": {
+      "width": { "$value": "100px" }, // Overrides field.width completely
+    },
+  },
+}
+```
+
+</aside>
+
+**Result for `input-amount`:**
+
+| Token              | Final Value                                                                                        |
+| :----------------- | :------------------------------------------------------------------------------------------------- |
+| `field.width`      | `"100px"` (local override wins)                                                                    |
+| `field.background` | `{"colorSpace": "srgb", "components": [1, 1, 1], "hex": "#ffffff"}` (inherited, no local override) |
+
+**Multi-level Override Example:**
+
+<aside class="example" title="Multi-level override">
+
+```json
+{
+  "base": {
+    "color": { "$value": "#blue" },
+    "spacing": { "$value": "16px" }
+  },
+  "extended": {
+    "$extends": "{base}",
+    "color": { "$value": "#red" }, // Overrides base.color
+    "border": { "$value": "1px solid" } // Adds new token
   }
 }
 ```
 
 </aside>
 
-Suggested ways tools MAY use this property are:
+**Result for `extended`:**
 
-- A style guide generator could render a section for each group and use the description as an introductory paragraph
-- A GUI tool that lets users browse or select tokens could display this info alongside the corresponding group or as a tooltip
-- Translation tools could output this as a source code comment
+| Token     | Final Value   | Source     |
+| :-------- | :------------ | :--------- |
+| `color`   | `"#red"`      | overridden |
+| `spacing` | `"16px"`      | inherited  |
+| `border`  | `"1px solid"` | added      |
 
-### Type
+### Circular Reference Prevention
 
-Groups MAY include an optional `$type` property so a type property does not need to be manually added to every token. [See supported "Types"](#types) for more information.
+Groups MUST NOT create circular inheritance chains. The following patterns are **invalid**:
 
-If a group has a `$type` property it acts as a default type for any tokens within the group, including ones in nested groups, that do not explicitly declare a type via their own `$type` property. For the full set of rules by which a design token's type is determined, please refer to the [design token type property chapter](#type-0).
+<aside class="example" title="Invalid circular reference">
 
-For example:
+```jsonc
+{
+  "button": {
+    "color": { "$value": "#blue" },
+    "border": { "$value": "1px solid" },
+    "secondary": {
+      "$extends": "{button}", // ❌ Invalid: circular reference
+    },
+  },
+}
+```
+
+</aside>
+
+<aside class="example" title="Another circular reference">
+
+```jsonc
+{
+  "groupA": {
+    "$extends": "{groupB}",
+    "token": { "$value": "valueA" },
+  },
+  "groupB": {
+    "$extends": "{groupA}", // ❌ Invalid: circular reference
+    "token": { "$value": "valueB" },
+  },
+}
+```
+
+</aside>
+
+**Valid inheritance patterns:**
+
+<aside class="example" title="Valid inheritance patterns">
+
+```jsonc
+{
+  "button": {
+    "color": { "$value": "#blue" },
+    "border": { "$value": "1px solid" },
+  },
+  "button-secondary": {
+    "$extends": "{button}", // ✅ Valid: references parent group
+    "color": { "$value": "#gray" },
+  },
+  "button-large": {
+    "$extends": "{button}", // ✅ Valid: siblings can reference same parent
+    "padding": { "$value": "16px" },
+  },
+}
+```
+
+</aside>
+
+### Supported Reference Formats
+
+`$extends` supports the same reference formats as [design token aliases](#references-and-json-pointer-integration).
+
+### Error Conditions
+
+`$extends` error handling follows JSON Schema `$ref` error patterns:
+
+- **Unresolvable references:** When the target group cannot be found
+- **Invalid targets:** When the reference points to a non-group (e.g., a token)
+- **Circular references:** When extension chains create cycles
+- **Constraint violations:** When local properties violate inherited constraints
+
+Tools MUST implement the same error detection and reporting patterns used by JSON Schema validators for `$ref` resolution.
+
+### Implementation Guidance
+
+Tools implementing design token parsing MAY choose to:
+
+1. **Transform to `$ref`:** Convert `$extends` to standard JSON Schema `$ref` syntax and use existing JSON Schema libraries for validation
+2. **Native implementation:** Implement `$extends` directly using the same algorithms as JSON Schema `$ref` processing
+3. **Hybrid approach:** Use JSON Schema libraries for validation while maintaining design token-specific reference syntax
+
+Regardless of implementation approach, the semantic behavior MUST be equivalent to JSON Schema `$ref` as specified in JSON Schema 2020-12 or later.
+
+### Relationship to JSON Schema Specifications
+
+This specification defines `$extends` as syntactic sugar for JSON Schema's `$ref` keyword, providing design token-specific reference syntax while maintaining equivalent behavior. The deep merge semantics described above align with how JSON Schema 2020-12 handles `$ref` with sibling properties.
+
+For implementers familiar with JSON Schema, the `$extends` behavior is equivalent to:
+
+- Converting `"$extends": "{group}"` to `"$ref": "#/group"`
+- Applying JSON Schema 2020-12 `$ref` resolution with sibling property evaluation
+
+Tools implementing this specification MAY choose to:
+
+1. **Transform approach:** Convert `$extends` to `$ref` and use JSON Schema libraries
+2. **Direct implementation:** Implement the deep merge behavior described above
+3. **Hybrid approach:** Use JSON Schema for validation while maintaining design token syntax
+
+Regardless of implementation approach, the user-visible behavior MUST match the deep merge semantics described in this specification.
+
+## Empty Groups
+
+Groups MAY be empty (contain no tokens or nested groups). While they may appear to serve no immediate purpose, they:
 
-<aside class="example">
+- Cause no harm to processing or validation
+- Support work-in-progress organization during token development
+- May contain metadata via group properties (`$description`, `$extensions`)
+- Provide placeholder structure for future token development
+
+<aside class="example" title="Empty group">
 
 ```json
 {
-  "brand": {
-    "$type": "color",
-    "color": {
-      "acid green": {
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 1, 0.4]
-        }
-      },
-      "hot pink": {
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [1, 0, 1]
-        }
-      }
-    }
+  "experimental": {
+    "$description": "Tokens for experimental features - currently empty",
+    "$deprecated": "This group is being phased out"
   }
 }
 ```
 
 </aside>
 
-### Extensions
+<aside class="note" title="Token vs Group Ambiguity">
+Objects without a `$value` property are interpreted as groups by definition. This can potentially create ambiguity in cases where a token lacks required properties (such as `$value` or a determinable type) and might be incorrectly parsed as an empty group. Tools SHOULD provide clear error messages when an object appears to be an incomplete token rather than an intentional empty group.
+</aside>
+
+## References and JSON Pointer Integration
+
+The current [token reference syntax](#references-and-json-pointer-integration) using curly braces (`{group.token}`) is maintained for backward compatibility and developer ergonomics. However, tools MAY also support JSON Pointer notation for advanced use cases.
+
+### Current Reference Syntax (Recommended)
+
+<aside class="example" title="Current reference syntax">
 
-Groups MAY include an optional `$extensions` property where tools MAY add proprietary, user-, team- or vendor-specific data to a group. When doing so, each tool MUST use a vendor-specific key whose value MAY be any valid JSON data.
+```json
+{
+  "base": {
+    "$value": {
+      "colorSpace": "srgb",
+      "components": [0, 0.4, 0.8],
+      "hex": "#0066cc"
+    }
+  },
+  "alias": { "$value": "{base}" }
+}
+```
 
-Group extensions follow the same rules as [design token extensions](#extensions), the only difference is that they relate to the group itself.
+</aside>
 
-- The keys SHOULD be chosen such that they avoid the likelihood of a naming clash with another vendor's data. The [reverse domain name notation](https://en.wikipedia.org/wiki/Reverse_domain_name_notation) is recommended for this purpose.
-- Tools that process design token files MUST preserve any extension data they do not themselves understand. For example, if a group contains extension data from tool A and the file containing that data is opened by tool B, then tool B MUST include the original tool A extension data whenever it saves a new design token file containing that group.
+### JSON Pointer Support
 
-Note that, since a group's `$extensions` only relate to that group, they do not have any effect on nested groups or tokens.
+Tools MUST support JSON Pointer references as defined by [[rfc6901]], using the `$ref` property:
 
-<aside class="example">
+<aside class="example" title="JSON Pointer references">
 
 ```json
 {
-  "brand": {
-    "$extensions": {
-      "org.example.tool-a": 42,
-      "org.example.tool-b": {
-        "turn-up-to-11": true
-      }
-    },
-    "color": {
-      "acid green": {
-        "$type": "color",
-        "$value": {
-          "colorSpace": "srgb",
-          "components": [0, 1, 0.4]
-        }
+  "base": {
+    "$value": {
+      "colorSpace": "srgb",
+      "components": [0, 0.4, 0.8],
+      "hex": "#0066cc"
+    }
+  },
+  "alias": { "$ref": "#/base" }
+}
+```
+
+</aside>
+
+## Processing Rules
+
+### Token Resolution Order
+
+When processing groups, tools MUST follow this resolution order:
+
+1. **Local tokens** - Direct children with `$value` properties
+2. **Root tokens** - Tokens with `$root` names
+3. **Extended tokens** - Tokens inherited via `$extends` (if not overridden)
+4. **Nested groups** - Process recursively
+
+### Path Construction
+
+Token paths are constructed by concatenating group names and token names with periods (`.`). The reserved token name `$root` is included in the path to maintain explicit, unambiguous references.
+
+Examples:
+
+| Location              | Path                 | Notes                                          |
+| :-------------------- | :------------------- | :--------------------------------------------- |
+| `/color/accent/$root` | `color.accent.$root` | Token path                                     |
+| `/color/accent/light` | `color.accent.light` | Token path                                     |
+| `/color/accent`       | —                    | Invalid for token resolution, valid for groups |
+
+### Type Inheritance
+
+Type resolution follows these rules in order of precedence:
+
+1. **Token's explicit [`$type`](design-token#type) property** (highest precedence)
+2. **Resolved group's `$type` property** (after extension resolution)
+3. **Parent group's `$type` property** (walking up the hierarchy)
+4. **Token is invalid** if no type can be determined
+
+**Type Resolution with Extensions:**
+Since `$extends` follows JSON Schema `$ref` semantics, type inheritance behavior is determined by constraint validation rather than explicit merge rules. Local type constraints are evaluated alongside inherited constraints according to JSON Schema validation patterns.
+
+<aside class="example" title="Type resolution with extensions">
+
+```jsonc
+{
+  "base": {
+    "$type": "color",
+    "primary": {
+      "$value": {
+        "colorSpace": "srgb",
+        "components": [0, 0.4, 0.8],
+        "hex": "#0066cc",
       },
-      "hot pink": {
-        "$type": "color",
+    },
+  },
+  "extended": {
+    "$extends": "{base}",
+    "$type": "dimension", // Local constraint
+    "spacing": { "$value": { "value": 16, "unit": "px" } },
+  },
+}
+```
+
+</aside>
+
+In this example, the group `extended` must satisfy both its local `$type: "dimension"` constraint and any applicable constraints from the referenced `base` group, following JSON Schema constraint resolution rules.
+
+### Circular Reference Detection
+
+Tools MUST detect and throw an error on circular references in:
+
+- Token [aliases](#references-and-json-pointer-integration) (`{token}` references)
+- Group extensions (`$extends` references)
+- JSON Pointer references (`$ref` properties, if supported)
+
+Circular reference detection for `$extends` follows the same requirements as JSON Schema `$ref` circular reference detection. Tools SHOULD implement the same algorithms used by JSON Schema validators for cycle detection.
+
+<aside class="example" title="Circular reference detection">
+
+```jsonc
+{
+  "a": { "$extends": "{b}" },
+  "b": { "$extends": "{c}" },
+  "c": { "$extends": "{a}" }, // Creates circular reference: a → b → c → a
+}
+```
+
+</aside>
+
+Tools MUST report this as an error affecting groups `a`, `b`, and `c`.
+
+## Migration and Compatibility
+
+This specification is designed to be backward compatible with existing design token files. Tools implementing this specification:
+
+- MUST continue to support existing group syntax
+- SHOULD provide warnings for deprecated patterns
+- MAY implement new features incrementally
+- MUST validate that token names do not conflict with reserved properties
+
+## Examples
+
+### Basic Group with Root Token
+
+<aside class="example" title="Basic group with root token">
+
+```json
+{
+  "spacing": {
+    "$type": "dimension",
+    "$description": "Base spacing scale",
+    "$root": { "$value": { "value": 16, "unit": "px" } },
+    "small": { "$value": { "value": 8, "unit": "px" } },
+    "large": { "$value": { "value": 32, "unit": "px" } }
+  }
+}
+```
+
+</aside>
+
+### Group Extension with Override Example
+
+<aside class="example" title="Group extension with override">
+
+```json
+{
+  "input": {
+    "$type": "dimension",
+    "field": {
+      "width": { "$value": { "value": 100, "unit": "%" } },
+      "background": {
         "$value": {
           "colorSpace": "srgb",
-          "components": [1, 0, 1]
+          "components": [1, 1, 1],
+          "hex": "#ffffff"
         }
       }
     }
+  },
+  "input-amount": {
+    "$extends": "{input}",
+    "field": {
+      "width": { "$value": { "value": 100, "unit": "px" } }
+    }
   }
 }
 ```
 
-In this example, the "brand" group has 2 extensions: `org.example.tool-a` and `org.example.tool-b`.
-
 </aside>
 
-### Deprecated
+**Resolved tokens:**
 
-The **`$deprecated`** property MAY be used to mark a group as deprecated, which extends to all child tokens within. This property may also optionally give a reason.
+- `{input-amount.field.width}` → `{ "value": 100, "unit": "px" }` (overridden)
+- `{input-amount.field.background}` → `#ffffff` (inherited from input)
 
-<aside class="example">
+This demonstrates the key use case where a component extends a base component but overrides specific tokens while inheriting others.
+
+### Complex Hierarchical Structure
+
+<aside class="example" title="Complex hierarchical structure">
 
 ```json
 {
-  "Button": {
-    "$deprecated": "Please use tokens in the Action group instead.",
-    "Foreground": {
-      "$value": {
-        "colorSpace": "srgb",
-        "components": [0.125, 0.125, 0.125],
-        "hex": "#202020"
+  "color": {
+    "$type": "color",
+    "$description": "Complete color system",
+    "brand": {
+      "$root": {
+        "$value": {
+          "colorSpace": "srgb",
+          "components": [0, 0.4, 0.8],
+          "hex": "#0066cc"
+        }
+      },
+      "light": {
+        "$value": {
+          "colorSpace": "srgb",
+          "components": [0.2, 0.533, 0.867],
+          "hex": "#3388dd"
+        }
       },
-      "$type": "color"
+      "dark": {
+        "$value": {
+          "colorSpace": "srgb",
+          "components": [0, 0.267, 0.6],
+          "hex": "#004499"
+        }
+      }
     },
-    "Background": {
-      "$value": {
-        "colorSpace": "srgb",
-        "components": [1, 1, 1],
-        "hex": "#ffffff"
+    "semantic": {
+      "$extends": "{color.brand}",
+      "success": {
+        "$root": {
+          "$value": {
+            "colorSpace": "srgb",
+            "components": [0, 0.8, 0.4],
+            "hex": "#00cc66"
+          }
+        },
+        "light": {
+          "$value": {
+            "colorSpace": "srgb",
+            "components": [0.2, 0.867, 0.533],
+            "hex": "#33dd88"
+          }
+        },
+        "dark": {
+          "$value": {
+            "colorSpace": "srgb",
+            "components": [0, 0.6, 0.267],
+            "hex": "#009944"
+          }
+        }
       },
-      "$type": "color"
+      "error": {
+        "$root": {
+          "$value": {
+            "colorSpace": "srgb",
+            "components": [0.8, 0, 0],
+            "hex": "#cc0000"
+          }
+        },
+        "light": {
+          "$value": {
+            "colorSpace": "srgb",
+            "components": [1, 0.2, 0.2],
+            "hex": "#ff3333"
+          }
+        },
+        "dark": {
+          "$value": {
+            "colorSpace": "srgb",
+            "components": [0.6, 0, 0],
+            "hex": "#990000"
+          }
+        }
+      }
     }
   }
 }
@@ -272,13 +735,14 @@ The **`$deprecated`** property MAY be used to mark a group as deprecated, which
 
 </aside>
 
-In the context of a group, adding `$deprecated` will apply to all tokens within that group, unless a token explicitly sets a value of `false`. Any value provided by a token will override the group default.
+This structure creates tokens accessible as:
 
-| Value    | Explanation                                                 |
-| :------- | :---------------------------------------------------------- |
-| `true`   | This token is deprecated (no explanation provided).         |
-| `String` | This token is deprecated AND this is an explanation.        |
-| `false`  | This token is NOT deprecated (may override group defaults). |
+| Token Reference                  | Resolved Value                                                                |
+| :------------------------------- | :---------------------------------------------------------------------------- |
+| `{color.brand.$root}`            | `{"colorSpace": "srgb", "components": [0, 0.4, 0.8], "hex": "#0066cc"}`       |
+| `{color.brand.light}`            | `{"colorSpace": "srgb", "components": [0.2, 0.533, 0.867], "hex": "#3388dd"}` |
+| `{color.semantic.success.$root}` | `{"colorSpace": "srgb", "components": [0, 0.8, 0.4], "hex": "#00cc66"}`       |
+| `{color.semantic.error.dark}`    | `{"colorSpace": "srgb", "components": [0.6, 0, 0], "hex": "#990000"}`         |
 
 ## Use-cases
 
@@ -288,7 +752,7 @@ Groups let token file authors better organize their token files. Related tokens
 
 For example:
 
-<aside class="example">
+<aside class="example" title="Organized token groups">
 
 ```json
 {
@@ -325,7 +789,7 @@ For example:
 
 ...is likely to be more convenient to type and, arguably, easier to read, than:
 
-<aside class="example">
+<aside class="example" title="Flat token structure">
 
 ```json
 {
@@ -371,7 +835,7 @@ Token names are not guaranteed to be unique within the same file. The same name
 
 For example, a [=translation tool=] like [Style Dictionary](https://amzn.github.io/style-dictionary/) might use the following design token file:
 
-<aside class="example">
+<aside class="example" title="Translation tool input">
 
 ```json
 {
@@ -408,7 +872,7 @@ For example, a [=translation tool=] like [Style Dictionary](https://amzn.github.
 
 ...and output it as Sass variables like so by concatenating the path to create variable names:
 
-<aside class="example">
+<aside class="example" title="Translation tool output">
 
 ```scss
 $brand-color-acid-green: #00ff66;
diff --git a/technical-reports/format/types.md b/technical-reports/format/types.md
index c1af9404..82c237d1 100644
--- a/technical-reports/format/types.md
+++ b/technical-reports/format/types.md
@@ -184,7 +184,7 @@ For example:
 
 ## Number
 
-Represents a number. Numbers can be positive, negative and have fractions. Example uses for number tokens are [gradient stop positions](#gradient) or unitless line heights. The `$type` property MUST be set to the string `number`. The value MUST be a JSON number value.
+Represents a number. Numbers can be positive, negative and have fractions. Example uses for number tokens are [gradient stop positions](composite-types#gradient) or unitless line heights. The `$type` property MUST be set to the string `number`. The value MUST be a JSON number value.
 
 <aside class="example">
 
diff --git a/technical-reports/index.html b/technical-reports/index.html
index ffe6b792..b800d05f 100644
--- a/technical-reports/index.html
+++ b/technical-reports/index.html
@@ -30,7 +30,7 @@
           { name: 'Kevin Powell', url: 'https://x.com/kevinmpowell' },
           { name: 'Louis Chenais', url: 'https://bsky.app/profile/lucho.cool' },
           { name: 'Matt Felten', url: 'https://mattfelten.com' },
-          { name: 'Matthew Ström', url: 'https://matthewstrom.com' },
+          { name: 'Matthew Ström-Awn', url: 'https://matthewstrom.com' },
           { name: 'Val Head', url: 'https://valhead.com' },
         ],
         github: {
diff --git a/technical-reports/package.json b/technical-reports/package.json
index f99173a6..b9f7af3f 100644
--- a/technical-reports/package.json
+++ b/technical-reports/package.json
@@ -16,9 +16,10 @@
     "dev": "chokidar \"**/*.{html,md}\" -c \"pnpm run build\" -d 2000",
     "lint": "prettier . --check",
     "format": "prettier . --format --write",
-    "validate": "pnpm run validate:index && pnpm run validate:format",
+    "validate": "pnpm run validate:index && pnpm run validate:format && pnpm run validate:color",
     "validate:index": "respec --localhost index.html --haltonerror --haltonwarn",
-    "validate:format": "respec --localhost format/index.html --haltonerror --haltonwarn"
+    "validate:format": "respec --localhost format/index.html --haltonerror --haltonwarn",
+    "validate:color": "respec --localhost color/index.html --haltonerror --haltonwarn"
   },
   "devDependencies": {
     "chokidar": "^4.0.3",