diff --git a/README.md b/README.md
index eec5e4c..0271b1e 100644
--- a/README.md
+++ b/README.md
@@ -123,7 +123,7 @@ See [Implementation Checklist](docs/adoption/implementation-checklist) for compl
 
 1. Read [CSS Consumption](docs/consumption/css) or [TypeScript Consumption](docs/consumption/typescript)
 2. Use generated CSS variables or TypeScript types
-3. Follow [Framework Integration](docs/consumption/frameworks) for React/Vue
+3. Follow [UI Library Integration](docs/consumption/frameworks) for React/Vue
 4. Test variable consumption
 
 ### For Design Engineers
@@ -138,79 +138,81 @@ See [Implementation Checklist](docs/adoption/implementation-checklist) for compl
 
 ### Introduction
 
-- [Why Variables](docs/introduction/why-variables) - Why "variables" not "design tokens"
-- [Comparison](docs/introduction/comparison) - Variable Design Standard vs DTCG, Style Dictionary, Material, Adobe
-- [Positioning](docs/introduction/positioning) - What Variable Design Standard is and is not
+- [Why Variables](docs/introduction/why-variables): Why "variables" not "design tokens"
+- [Comparison](docs/introduction/comparison): Variable Design Standard vs DTCG, Style Dictionary, Material, Adobe
+- [Positioning](docs/introduction/positioning): What Variable Design Standard is and is not
 
 ### Contract reference
 
-- [Variable Design Standard](docs/contract/variable-contract) - JSON shape and structure
-- [Groups](docs/contract/groups) - Group structure and extension
-- [References](docs/contract/references) - Reference syntax and resolution
-- [Modes](docs/contract/modes) - Mode structure and resolution
-- [Types](docs/contract/types) - Type system reference
-- [Composite Types](docs/contract/composite-types) - Border, Transition, Shadow, Gradient, Typography
-- [Naming](docs/contract/naming) - Naming convention
-- [Anatomy](docs/contract/anatomy) - Base, alias, and component tokens
+- [Variable Design Standard](docs/contract/variable-contract): JSON shape and structure
+- [Groups](docs/contract/groups): Group structure and extension
+- [References](docs/contract/references): Reference syntax and resolution
+- [Modes](docs/contract/modes): Mode structure and resolution
+- [Types](docs/contract/types): Type system reference
+- [Composite Types](docs/contract/composite-types): Border, Transition, Shadow, Gradient, Typography
+- [Naming](docs/contract/naming): Naming convention
+- [Anatomy](docs/contract/anatomy): Base, alias, and component tokens
 
 ### Adoption
 
-- [Getting Started](docs/adoption/getting-started) - Team adoption guide
-- [Implementation Checklist](docs/adoption/implementation-checklist) - Pre/post implementation checklists
-- [Migration Strategy](docs/adoption/migration-strategy) - Phased migration approaches
+- [Getting Started](docs/adoption/getting-started): Team adoption guide
+- [Implementation Checklist](docs/adoption/implementation-checklist): Pre/post implementation checklists
+- [Migration Strategy](docs/adoption/migration-strategy): Phased migration approaches
 
 ### Governance
 
-- [Governance Overview](docs/governance/overview) - Governance principles and workflow
-- [Change Control](docs/governance/change-control) - Review and release process
-- [Validation](docs/governance/validation) - Validation tools and CI setup
-- [Versioning](docs/governance/versioning) - Semantic versioning and breaking changes
-- [Migration](docs/governance/migration) - Migrating from other formats
-- [Troubleshooting](docs/governance/troubleshooting) - Common issues and solutions
-- [Accessibility](docs/governance/accessibility) - Accessibility constraints
+- [Governance Overview](docs/governance/overview): Governance principles and workflow
+- [Change Control](docs/governance/change-control): Review and release process
+- [Validation](docs/governance/validation): Validation tools and CI setup
+- [Versioning](docs/governance/versioning): Semantic versioning and breaking changes
+- [Migration](docs/governance/migration): Migrating from other formats
+- [Troubleshooting](docs/governance/troubleshooting): Common issues and solutions
+- [Accessibility](docs/governance/accessibility): Accessibility constraints
 
 ### Scenarios
 
-- [Multi-Brand](docs/scenarios/multi-brand) - Multi-brand architecture patterns
-- [Multi-Theme](docs/scenarios/multi-theme) - Theme composition and mode inheritance
-- [Large Sets](docs/scenarios/large-sets) - Performance considerations
-- [Component Integration](docs/scenarios/component-integration) - Component library integration
+- [Multi-Brand](docs/scenarios/multi-brand): Multi-brand architecture patterns
+- [Multi-Theme](docs/scenarios/multi-theme): Theme composition and mode inheritance
+- [Large Sets](docs/scenarios/large-sets): Performance considerations
+- [Component Integration](docs/scenarios/component-integration): Component library integration
 
 ### Tooling
 
-- [Ecosystem](docs/tooling/ecosystem) - Tools that support Variable Design Standard
-- [CI/CD](docs/tooling/ci-cd) - CI/CD integration patterns
-- [Build Pipelines](docs/tooling/build-pipelines) - Complete build pipeline examples
-- [Figma Adapter](docs/adapters/figma) - Figma export normalization
-- [Tokens Studio Adapter](docs/adapters/tokens-studio) - Tokens Studio export normalization
-- [Style Dictionary Adapter](docs/adapters/style-dictionary) - CSS/TypeScript output generation
+- [Ecosystem](docs/tooling/ecosystem): Tools that support Variable Design Standard
+- [CI/CD](docs/tooling/ci-cd): CI/CD integration patterns
+- [Build Pipelines](docs/tooling/build-pipelines): Complete build pipeline examples
+- [Figma Adapter](docs/adapters/figma): Figma export normalization
+- [Tokens Studio Adapter](docs/adapters/tokens-studio): Tokens Studio export normalization
+- [Style Dictionary Adapter](docs/adapters/style-dictionary): CSS/TypeScript output generation
 
 ### Consumption
 
-- [CSS](docs/consumption/css) - CSS variable consumption patterns
-- [TypeScript](docs/consumption/typescript) - TypeScript type generation
-- [Frameworks](docs/consumption/frameworks) - React/Vue integration
+- [CSS](docs/consumption/css): CSS variable consumption patterns
+- [TypeScript](docs/consumption/typescript): TypeScript type generation
+- [UI Libraries](docs/consumption/frameworks): React/Vue integration
 
 ### Design
 
-- [Figma Naming](docs/design/figma-naming) - How to name variables in Figma
-- [Figma Workflow](docs/design/figma-workflow) - Designer workflow
-- [Component Variables](docs/design/component-variables) - Using variables in Figma components
+- [Figma Naming](docs/design/figma-naming): How to name variables in Figma
+- [Figma Workflow](docs/design/figma-workflow): Designer workflow
+- [Component Variables](docs/design/component-variables): Using variables in Figma components
 
 ### Testing
 
-- [Validation](docs/testing/validation) - Testing variable changes
-- [Visual Regression](docs/testing/visual-regression) - Visual regression testing
-- [Consumption Tests](docs/testing/consumption-tests) - Testing generated outputs
+- [Validation](docs/testing/validation): Testing variable changes
+- [Visual Regression](docs/testing/visual-regression): Visual regression testing
+- [Consumption Tests](docs/testing/consumption-tests): Testing generated outputs
 
 ### Patterns
 
-- [Multi-Brand Architecture](docs/patterns/multi-brand-architecture) - Complete multi-brand example
-- [Theme Composition](docs/patterns/theme-composition) - Theme composition patterns
-- [Performance](docs/patterns/performance) - Performance optimization
+- [Multi-Brand Architecture](docs/patterns/multi-brand-architecture): Complete multi-brand example
+- [Theme Composition](docs/patterns/theme-composition): Theme composition patterns
+- [Performance](docs/patterns/performance): Performance constraints
 
 ## Requirements
 
+JSON-as-API means file paths and names are the interface. Treat renames as breaking changes.
+
 Variable Design Standard JSON files MUST:
 
 - Use DTCG 2025.10 format
@@ -219,7 +221,7 @@ Variable Design Standard JSON files MUST:
 - Include `$type` and `$value` on all variables
 - Resolve all references (no broken references)
 - Avoid circular references
-- Use consistent mode keys within collections
+- Use the same mode key set within each collection
 
 Variable Design Standard JSON files SHOULD:
 
@@ -247,7 +249,7 @@ Validation checks:
 - Reference resolution (all references resolve)
 - Circular reference detection (no reference cycles)
 - Type correctness (`$value` matches `$type`)
-- Mode consistency (mode keys shared within collections)
+- Mode key set checks (keys match within each collection)
 
 See [Validation](docs/governance/validation) for validation tools and CI setup.
 
@@ -270,7 +272,7 @@ Non-breaking changes:
 
 - New variables
 - New modes
-- Value changes (if documented and intentional)
+- Value changes (if approved in review and documented)
 
 See [Versioning](docs/governance/versioning) for complete versioning strategy.
 
@@ -315,21 +317,21 @@ See [Style Dictionary Adapter](docs/adapters/style-dictionary) for details.
 
 ## Examples
 
-- [Figma Export JSON](docs/examples/figma-export) - Example Figma export
-- [DTCG Compliant Example](docs/examples/dtcg-compliant) - Complete DTCG 2025.10 example
-- [Adapter Pipeline](docs/examples/adapter-pipeline) - End-to-end transformation example
+- [Figma Export JSON](docs/examples/figma-export): Example Figma export
+- [DTCG Compliant Example](docs/examples/dtcg-compliant): Complete DTCG 2025.10 example
+- [Adapter Pipeline](docs/examples/adapter-pipeline): Export-to-contract conversion example
 
-## UDS Framework
+## UDS System
 
-Variable Design Standard is part of UDS (UI Design Standard), a comprehensive framework for design-to-code governance.
+Variable Design Standard is part of UDS (UI Design Standard), a comprehensive standard set for design-to-code governance.
 
 UDS components:
 
-- Variable Design Standard (VDS) - this spec
-- Integrity Design Standard (IDS) - tooling layer (future)
-- Component Design Standard (future) - component mapping
-- Pattern Design Standard (future) - pattern mapping
-- Design-Dev Mapping (future) - artifact relationships
+- Variable Design Standard (VDS): this spec
+- Integrity Design Standard (IDS): tooling layer (future)
+- Component Design Standard (future): component mapping
+- Pattern Design Standard (future): pattern mapping
+- Design-Dev Mapping (future): artifact relationships
 
 Variable Design Standard is the first standard in UDS, focusing on variables.
 
@@ -419,10 +421,10 @@ Variable Design Standard is maintained by the editor. Contributions welcome.
 
 Variable Design Standard builds on:
 
-- [DTCG 2025.10 Format](https://www.designtokens.org/tr/2025.10/format/) - Base format specification
-- [Style Dictionary](https://styledictionary.com/) - Output generation tool
-- Figma Variables - Design tool integration
-- Tokens Studio - Design tool integration
+- [DTCG 2025.10 Format](https://www.designtokens.org/tr/2025.10/format/): Base format specification
+- [Style Dictionary](https://styledictionary.com/): Output generation tool
+- Figma Variables: Design tool integration
+- Tokens Studio: Design tool integration
 
 ## JSON Schema
 
@@ -444,10 +446,10 @@ See [Schema](docs/schema) for validation tools and IDE integration.
 
 ## References
 
-- [DTCG 2025.10 Specification](https://www.designtokens.org/tr/2025.10/format/) - Design Tokens Community Group format
-- [Variable Design Standard Documentation](docs/index.md) - Complete specification and governance
-- [DTCG Alignment](docs/contract/dtcg-alignment.md) - Compliance details
-- [JSON Schema](docs/schema) - Validation schema and tools
+- [DTCG 2025.10 Specification](https://www.designtokens.org/tr/2025.10/format/): Design Tokens Community Group format
+- [Variable Design Standard Documentation](docs/index.md): Complete specification and governance
+- [DTCG Alignment](docs/contract/dtcg-alignment.md): Compliance details
+- [JSON Schema](docs/schema): Validation schema and tools
 
 ## Conformance
 
diff --git a/docs/introduction/comparison.md b/docs/introduction/comparison.md
index 7377d6e..eabc3aa 100644
--- a/docs/introduction/comparison.md
+++ b/docs/introduction/comparison.md
@@ -4,7 +4,9 @@ title: Comparison
 
 # Variable Design Standard (VDS) vs Other Standards
 
-How Variable Design Standard (VDS) compares to other variable/token standards and why it wins.
+Scope: comparison of Variable Design Standard (VDS) to other variable and token standards.
+
+Failure if ignored: teams pick formats without governance and ship incompatible rules.
 
 ## Comparison matrix
 
@@ -18,7 +20,7 @@ How Variable Design Standard (VDS) compares to other variable/token standards an
 | Adapters          | Yes          | No           | Tool-specific    | No              | No             |
 | Tool-agnostic     | Yes          | Yes          | No               | No              | No             |
 | Designer-focused  | Yes          | No           | No               | Yes             | Yes            |
-| Developer-focused | Yes          | No           | Yes              | Partial         | Partial        |
+| Engineer-focused | Yes          | No           | Yes              | Partial         | Partial        |
 
 ## Variable Design Standard (VDS) vs DTCG 2025.10
 
@@ -90,16 +92,16 @@ Material Design is a design system. Variable Design Standard (VDS) is a governan
 
 ## Variable Design Standard (VDS) vs Adobe Spectrum
 
-### Adobe Spectrum is complex
+### Adobe Spectrum is specialized
 
 Adobe Spectrum:
 
 - Complex taxonomy (namespace, domain, object, base, modifiers)
 - Many naming segments
 - Brand-specific structure
-- Over-engineered for most use cases
+- More detailed taxonomy than most teams need
 
-### Variable Design Standard (VDS) is simple
+### Variable Design Standard (VDS) keeps a smaller required surface
 
 Variable Design Standard (VDS):
 
@@ -108,39 +110,39 @@ Variable Design Standard (VDS):
 - Flexible structure
 - Practical and testable
 
-Adobe Spectrum solves Adobe's problems. Variable Design Standard (VDS) solves everyone's problems.
+Adobe Spectrum solves Adobe-specific constraints. Variable Design Standard (VDS) keeps a smaller required surface for broader use.
 
-## Why Variable Design Standard (VDS) wins
+## Why teams choose Variable Design Standard (VDS)
 
-### 1. Simplicity
+### 1. Smaller contract surface
 
 - Variables are variables, not special "tokens"
 - Simple naming (dot-separated paths)
 - Clear structure
 - Easy to understand
 
-### 2. Governance
+### 2. Governance baked in
 
 - Clear rules (not opinions)
 - Testable requirements
 - Versioning strategy
 - Change control process
 
-### 3. Tool-agnostic
+### 3. Tool-agnostic by design
 
 - Works with any tool
 - Adapter pattern for tool integration
 - Not tied to specific tools
 - Flexible consumption
 
-### 4. Designer + Developer
+### 4. Designer and Engineer alignment
 
 - Works for both audiences
 - Clear handoff process
 - Shared understanding
 - No separation
 
-### 5. Production-ready
+### 5. Stable discipline
 
 - Validation in CI
 - Version control integration
diff --git a/docs/introduction/positioning.md b/docs/introduction/positioning.md
index 713e4da..ccd4b32 100644
--- a/docs/introduction/positioning.md
+++ b/docs/introduction/positioning.md
@@ -4,7 +4,7 @@ title: Positioning
 
 # Variable Design Standard (VDS) Positioning
 
-What Variable Design Standard (VDS) is, what it is not, and how it fits into the larger UDS framework.
+What Variable Design Standard (VDS) is, what it is not, and how it fits into the larger UDS system.
 
 ## What Variable Design Standard (VDS) is
 
@@ -21,6 +21,7 @@ Variable Design Standard (VDS) provides:
 - Governance (naming rules, change control)
 - Validation (what to check)
 - Adapters (how to convert tool outputs)
+- File selection rule (brand and mode selection by file list)
 
 ## What Variable Design Standard (VDS) is NOT
 
@@ -32,17 +33,17 @@ Variable Design Standard (VDS) is NOT:
 - A runtime library (use DTCG-compliant validators)
 - A build tool (use Style Dictionary or similar)
 
-## UDS Framework
+## UDS System
 
-Variable Design Standard is part of UDS (UI Design Standard), a comprehensive framework for design-to-code governance.
+Variable Design Standard is part of UDS (UI Design Standard), a comprehensive standard set for design-to-code governance.
 
 UDS components:
 
-- Variable Design Standard (VDS) - this spec
-- Integrity Design Standard (IDS) - tooling layer (future)
-- Component Design Standard (future) - component mapping
-- Pattern Design Standard (future) - pattern mapping
-- Design-Dev Mapping (future) - artifact relationships
+- Variable Design Standard (VDS): this spec
+- Integrity Design Standard (IDS): tooling layer (future)
+- Component Design Standard (future): component mapping
+- Pattern Design Standard (future): pattern mapping
+- Design-Dev Mapping (future): artifact relationships
 
 Variable Design Standard is the first standard in UDS, focusing on variables.
 
@@ -94,9 +95,21 @@ Variable Design Standard (VDS) works by:
 1. Defining structure (DTCG 2025.10 format)
 2. Adding governance (naming, validation, versioning)
 3. Providing adapters (tool integration)
-4. Enabling validation (CI checks)
+4. Running validation (CI checks)
 5. Supporting migration (from any format)
 
+## JSON-as-API
+
+The JSON file set is the API surface. Paths and names are the contract. Brand and mode selection happens by file list, not by a mapped layer.
+
+## Standard posture
+
+Variable Design Standard (VDS) is a spec and a governance layer.
+
+- The contract is the JSON in version control.
+- CI validates structure, naming, references, and modes.
+- Contract changes are reviewed before merge.
+
 ## Success criteria
 
 Variable Design Standard (VDS) succeeds when:
diff --git a/docs/introduction/why-variables.md b/docs/introduction/why-variables.md
index 4f8f524..0b7bf0b 100644
--- a/docs/introduction/why-variables.md
+++ b/docs/introduction/why-variables.md
@@ -8,9 +8,9 @@ title: Why Variables
 This page is part of the [Variable Design Standard (VDS)](../contract/variable-contract) governed specification. See [License](../license) for usage terms.
 :::
 
-Variables are variables. CSS variables, JavaScript variables, Figma variables. They're all variables.
+Scope: terminology. VDS uses “variables” because it matches the language used in code and design tools.
 
-If you call them "design tokens" or "style properties" or "design constants," you create confusion. Developers know variables. Designers know variables. Variable Design Standard (VDS) uses the term everyone understands.
+Failure if ignored: teams split vocabulary and handoff breaks.
 
 ## The naming problem
 
@@ -22,9 +22,9 @@ Everyone calls them something different:
 - Variables (CSS, JavaScript, Figma)
 - Tokens (Tokens Studio, Adobe)
 
-This creates confusion. A developer sees "design token" and thinks "what's that?" A designer sees "CSS variable" and thinks "is that different?"
+This splits vocabulary across roles and makes handoff less precise.
 
-## Variables are variables
+## Variables are shared primitives
 
 Variables exist in:
 
@@ -33,7 +33,7 @@ Variables exist in:
 - Figma: Variables panel
 - TypeScript: `export const color = { primary: '#0066cc' }`
 
-They're all variables. They store values. They can be referenced. They can be changed.
+They store values, can be referenced, and can be changed.
 
 ## Why Variable Design Standard (VDS) uses "variables"
 
@@ -58,16 +58,16 @@ Variable Design Standard (VDS) does NOT standardize:
 - What tools you use (use any tool)
 - How you consume them (CSS, JS, whatever works)
 
-## The "design token" problem
+## The term "design token"
 
-"Design token" implies:
+The term "design token" implies:
 
 - Special category separate from code
 - Design-only concept
 - Something designers own exclusively
 - Marketing terminology
 
-This creates separation between design and code. Variables bridge that gap.
+This separates design from code. Variables keep the same term across both.
 
 ## Variable Design Standard (VDS)'s approach
 
diff --git a/docs/license.md b/docs/license.md
index 7a3178a..def866d 100644
--- a/docs/license.md
+++ b/docs/license.md
@@ -6,8 +6,8 @@ title: License
 
 The Variable Design Standard (VDS) Specification is dual-licensed:
 
-1. **CC BY-ND 4.0** — Legally recognized base license
-2. **Standards Integrity Addendum** — Additional terms for public use
+1. **CC BY-ND 4.0**. Legally recognized base license.
+2. **Standards Integrity Addendum**. Additional terms for public use.
 
 ## Part I: Base License (CC BY-ND 4.0)
 
@@ -15,13 +15,13 @@ This Specification is licensed under [Creative Commons Attribution-NoDerivatives
 
 **You are free to:**
 
-- **Share** — Copy and redistribute in any medium or format
-- **Implement** — Build software that conforms to the Specification
+- **Share**. Copy and redistribute in any medium or format.
+- **Implement**. Build software that conforms to the Specification.
 
 **Under these terms:**
 
-- **Attribution** — You must give appropriate credit and link to the license
-- **NoDerivatives** — You may not distribute modified versions of the Specification as an alternative standard
+- **Attribution**. You must give appropriate credit and link to the license.
+- **NoDerivatives**. You may not distribute modified versions of the Specification as an alternative standard.
 
 ## Part II: Standards Integrity Addendum
 
diff --git a/docs/meta/change-log.md b/docs/meta/change-log.md
index 3d17d0b..cf2a359 100644
--- a/docs/meta/change-log.md
+++ b/docs/meta/change-log.md
@@ -31,29 +31,29 @@ Documentation hardening and DTCG 2025.10 compliance improvements.
 
 #### Documentation Hardening
 
-- **Version consistency**: Updated all version references from 0.3.7 to 0.4.0.
-- **Fixed incorrect version claims**: Corrected FAQ claim that 1.0.0 is stable.
+- **Version references**: Updated all version references from 0.3.7 to 0.4.0.
+- **Fixed incorrect version claims**: Corrected FAQ claim that 1.0.0 is the current release.
 - **Updated examples**: Fixed `dtcg-compliant.json` to use strict DTCG object formats.
 - **Improved accuracy**: Ensured all DTCG compliance claims are accurate and verifiable.
 
 ### Files Updated
 
-- `package.json` - Version bump to 0.4.0
-- `README.md` - Version update and DTCG claims correction
-- `docs/index.md` - Version update
-- `docs/faq.md` - Fixed version claim
-- `docs/contract/dtcg-alignment.md` - Clarified VDS extensions
-- `docs/contract/modes.md` - Added DTCG disclaimer
-- `docs/contract/types.md` - Updated to show object format as canonical
-- `docs/contract/groups.md` - Updated to use `$extends`
-- `docs/contract/references.md` - Clarified modes are VDS extension
-- `docs/contract/variable-contract.md` - Updated group extension syntax
-- `docs/examples/dtcg-compliant.md` - Updated to match corrected JSON
-- `docs/examples/figma-export.md` - Fixed REST API claims
-- `docs/adapters/figma.md` - Clarified plugin vs REST API formats
-- `docs/design/figma-naming.md` - Clarified export prefixes
-- `assets/schema/dtcg-compliant.json` - Fixed to strict DTCG format
-- `LINKS.md` - Added Figma documentation links
+- `package.json`: Version bump to 0.4.0
+- `README.md`: Version update and DTCG claims correction
+- `docs/index.md`: Version update
+- `docs/faq.md`: Fixed version claim
+- `docs/contract/dtcg-alignment.md`: Clarified VDS extensions
+- `docs/contract/modes.md`: Added DTCG disclaimer
+- `docs/contract/types.md`: Updated to show object format as canonical
+- `docs/contract/groups.md`: Updated to use `$extends`
+- `docs/contract/references.md`: Clarified modes are VDS extension
+- `docs/contract/variable-contract.md`: Updated group extension syntax
+- `docs/examples/dtcg-compliant.md`: Updated to match corrected JSON
+- `docs/examples/figma-export.md`: Fixed REST API claims
+- `docs/adapters/figma.md`: Clarified plugin vs REST API formats
+- `docs/design/figma-naming.md`: Clarified export prefixes
+- `assets/schema/dtcg-compliant.json`: Fixed to strict DTCG format
+- `LINKS.md`: Added Figma documentation links
 
 ## Version 0.3.7
 
@@ -64,6 +64,6 @@ Previous version with initial documentation structure.
 - **v0.5.0**: Reference validator CLI and test fixtures
 - **v0.6.0**: Reference adapters as code (Figma, Tokens Studio)
 - **v0.7.0**: Reference output generators (CSS, TypeScript, Tailwind v4)
-- **v1.0.0**: Formal Status of this Document (SOTD), conformance registry, stabilized schema
+- **v1.0.0**: Formal Status of this Document (SOTD), conformance registry, schema frozen for 1.x
 
 See [Versioning](governance/versioning) for versioning strategy and breaking change definitions.
diff --git a/docs/meta/contributors.md b/docs/meta/contributors.md
index 96ffa45..de03a12 100644
--- a/docs/meta/contributors.md
+++ b/docs/meta/contributors.md
@@ -8,7 +8,7 @@ People who have contributed to Variable Design Standard (VDS).
 
 ## Editor
 
-**Mark Learst** - Editor and maintainer
+**Mark Learst**: Editor and maintainer
 
 Variable Design Standard (VDS) has been in development since 2017.
 
diff --git a/docs/meta/status-of-this-document.md b/docs/meta/status-of-this-document.md
index 59d2781..f50364b 100644
--- a/docs/meta/status-of-this-document.md
+++ b/docs/meta/status-of-this-document.md
@@ -72,7 +72,7 @@ When filing an issue, please include:
 
 ### Editor
 
-**Mark Learst** - Editor and maintainer
+**Mark Learst**: Editor and maintainer
 
 Variable Design Standard (VDS) has been in development since 2017.
 
@@ -84,10 +84,10 @@ See [Contributors](contributors) for a list of people who have contributed to Va
 
 Variable Design Standard (VDS) builds on:
 
-- [DTCG 2025.10 Format Specification](https://www.designtokens.org/tr/2025.10/format/) - Base format specification
-- [Style Dictionary](https://styledictionary.com/) - Output generation tool
-- Figma Variables - Design tool integration
-- Tokens Studio - Design tool integration
+- [DTCG 2025.10 Format Specification](https://www.designtokens.org/tr/2025.10/format/): Base format specification
+- [Style Dictionary](https://styledictionary.com/): Output generation tool
+- Figma Variables: Design tool integration
+- Tokens Studio: Design tool integration
 - The design systems community for feedback and validation
 
 ## Document History
@@ -96,8 +96,8 @@ Version history and release notes are documented in the [Change Log](change-log)
 
 ### Recent Versions
 
-- **0.4.0** (Current) - Documentation hardening and DTCG compliance improvements
-- **0.3.7** - Previous version with initial documentation structure
+- **0.4.0** (Current): Documentation hardening and DTCG compliance improvements
+- **0.3.7**: Previous version with initial documentation structure
 
 ### Future Versions
 
diff --git a/docs/meta/status.md b/docs/meta/status.md
index 75c87e8..cb73076 100644
--- a/docs/meta/status.md
+++ b/docs/meta/status.md
@@ -33,7 +33,7 @@ This document defines the status taxonomy for Variable Design Standard (VDS) and
 - Suitable for production use with awareness of potential minor changes
 
 **Transition criteria**: Move from Draft to Candidate Standard when:
-- Core features are stable
+- Core features are frozen for the current major version
 - Breaking changes are limited to major versions
 - Community feedback period begins
 
@@ -42,7 +42,7 @@ This document defines the status taxonomy for Variable Design Standard (VDS) and
 **Definition**: Production-ready, breaking changes only in major versions.
 
 **Characteristics**:
-- Specification is stable and production-ready
+- Required fields are frozen for the current major version
 - Breaking changes only in major versions (following semantic versioning)
 - Minor and patch versions are backward-compatible
 - Recommended for production use
@@ -74,20 +74,20 @@ This document defines the status taxonomy for Variable Design Standard (VDS) and
 
 **Variable Design Standard (VDS) 0.4.0**: **Draft**
 
-The specification is in active development. While it is production-ready and used by teams, breaking changes may occur as the specification evolves based on feedback and implementation experience.
+The specification is in active development. While it is used in production by some teams, breaking changes may occur as the specification evolves based on feedback and implementation experience.
 
 ## Status History
 
-- **0.1.0 - 0.3.7**: Draft
+- **0.1.0: 0.3.7**: Draft
 - **0.4.0**: Draft (current)
 
 ## Status Indicators
 
 Status is indicated in:
-- `docs/index.md` - Status metadata table
-- `docs/meta/change-log.md` - Version status field
-- `docs/faq.md` - Production-ready answer
-- This document - Status definitions
+- `docs/index.md`: Status metadata table
+- `docs/meta/change-log.md`: Version status field
+- `docs/faq.md`: Production-ready answer
+- This document: Status definitions
 
 ## Compatibility Promises by Status