Sort scattered design values into a token system with three tiers

Help me turn the design values scattered across our files into a token system with a defensible structure. I will give you what exists today; you sort it, name it, and tell me where the sources disagree.

What exists today: {{paste or describe: Figma variables or styles, CSS custom properties, a Tailwind config, iOS or Android resource files, and the values still hardcoded in components}}
Platforms this has to serve: {{e.g. web and iOS; or web only}}
Tools in the chain: {{e.g. Figma variables exported through Tokens Studio into Style Dictionary; or nothing automated yet}}
Themes or brands to support now or soon: {{light and dark, a second brand, a high-contrast mode, or none}}
Who maintains this and how many people consume it: {{e.g. two designers, fourteen engineers across three products}}
What breaks today: {{e.g. six greys that are nearly identical, a designer picks a color that does not exist in code, dark mode was bolted on with overrides}}

Sort everything into three tiers, and be strict about the boundary between them.

**Primitives** hold raw values and carry no opinion about use. Every actual value in the system lives here exactly once, and the names describe what the value is rather than where it goes. This is where a duplicate is a defect: if two greys differ by one step and nothing depends on the difference, say which one to keep and which references to redirect.

**Semantic tokens** reference primitives and carry the intent. These are what a designer or engineer reaches for, and their names describe the role rather than the appearance, so that switching a theme changes what they resolve to without renaming anything. A semantic token holding a literal value instead of a reference to a primitive is the single most common structural error here, so flag every instance.

**Component tokens** exist only where a component genuinely needs to diverge from the semantic layer. Be skeptical of this tier. For each one you propose, give the reason the semantic layer cannot serve it. If the honest answer is that someone wanted a slightly different value once, say so and drop it.

Then produce these, in this order.

**The naming convention, stated as a pattern.** Give the ordered segments, the casing, the rule for numeric scales, and how theme variants are expressed. Then show it applied to eight tokens drawn from my actual values, spanning color, spacing and typography, so I can see the pattern hold rather than read it described. Note which of my existing names break under it and what they become.

**The sorted inventory.** A table of the values I gave you: current name or location, proposed tier, proposed name, resolved value, and where it is used. Include a row for anything you are deliberately leaving out of the system, with the reason — one-off illustration colors and page-specific layout numbers usually belong outside it, and a token system that absorbs every number stops carrying meaning.

**The drift report.** Where the same concept holds different values across my sources: Figma against code, one platform against another, light theme against dark. For each, say which one you believe is intended and what evidence in my input supports that. This is usually the section that pays for the exercise, so be thorough and do not smooth over a disagreement by picking an average.

**The theme layer.** How the semantic tier resolves differently per theme, and which tokens must be theme-aware for dark mode to work without per-component overrides. Call out anything in my current setup that would force an override.

**Governance, in five lines or fewer.** Who can add a primitive, what a designer does when the value they want does not exist, how a token is deprecated without breaking consumers, and what stops the set from doubling in a year. Make it short enough that someone will actually follow it.

Where my input is not specific enough to place a value in a tier, ask rather than guessing: putting a value in the wrong tier is more expensive to undo than leaving it unsorted for a day.

Tip: Export the Figma variables and the CSS custom properties and paste both, even where you expect them to agree, because the drift report is only as good as having two sources to compare. On the interchange format: the Design Tokens Community Group JSON shape is what Figma, Style Dictionary, Tokens Studio and Terrazzo read, but the specification is still a working draft that tells implementers not to treat it as authoritative, so target it for portability and do not expect it to be stable in every detail.