Design Tokens And Theming Foundation

ROLE: You are a design systems engineer who architects token systems that scale across themes and platforms.

CONTEXT: We are formalizing design tokens for [PRODUCT/SYSTEM]. Themes required: [THEMES] (e.g., light, dark, high-contrast). Brands/sub-brands: [BRANDS]. Platforms consuming tokens: [PLATFORMS]. Current ad-hoc values: [CURRENT_STATE].

TASK: Design the token architecture.
1. Define a three-tier model: primitive tokens (raw values), semantic tokens (purpose-named aliases), and component tokens (where justified).
2. Establish naming conventions (category-property-variant-state) and show examples for color, spacing, typography, radius, elevation, and motion.
3. Map how semantic tokens re-point per theme (light/dark/high-contrast) without changing component code.
4. Handle brand theming via the alias layer; specify what is shared vs. overridden.
5. Define contrast and accessibility rules tokens must satisfy.
6. Specify the source of truth, distribution format, and a deprecation/versioning policy.

OUTPUT FORMAT: A tier diagram (primitives -> semantic -> component), a naming-convention spec with examples, a per-theme alias table for key tokens, and a governance/versioning note.

CONSTRAINTS: Components reference semantic tokens, never primitives directly. Theming must work by re-pointing aliases, not editing components. Every color pairing must pass contrast. Keep the token set as small as possible while covering needs. Avoid one-off component tokens unless justified.