One token source, many hosts
The Design Tokens Format Module gives the portfolio a shared interchange format — still a Draft Community Group Report whose own current text warns implementers not to build against this version — and Style Dictionary compiles it per host, which is what makes “ninety brands” a build step rather than ninety forks.
You have one mapping file for one host, written by hand, and it works. Now imagine the tenth. Then the fortieth. Each one is a dozen declarations somebody wrote on an afternoon, and they will not stay consistent: one has a border colour and the next does not, one falls back to #1a1a1a and another to #111, and three of them were copied from a host whose names changed in April.
The problem is not the work. A dozen lines ninety times is a bad week, not an impossible one. The problem is that ninety hand-written files have ninety independent chances to drift, and nobody can answer “what does the component look like in production” by reading any one of them. What you want is one source that you edit and ninety files that nobody edits.
The format, and the warning on its own front page
The Design Tokens Format Module is the interchange format everybody in this space is converging on, and the honest description of its status matters more than the syntax. It is a Draft Community Group Report, not a W3C standard. The draft checked on 2026-09-03 was titled “Design Tokens Format Module 2025.10,” dated 30 July 2026, and carried the warning “Do not attempt to implement this version of the specification.”
That is a stronger caveat than “not yet a Recommendation.” It is the authors telling implementers not to build against the current text. It does not mean the format is unusable and it does not mean you should invent your own. It means two specific things for you.
- Do not build tooling that assumes the current text is final. Keep the format at the edge of your pipeline, behind a build step you own, so a change to the draft is a change to one transform rather than to everything downstream of it.
- Do not tell a host’s platform engineer that your tokens follow a W3C standard. They will check, they will find a community group report with that warning on it, and everything else you claimed gets a discount it may not deserve. Say what it is: a draft community format, used because it is the one the tools read.
Where people get burned
The registered summary for this lesson called the format “a single interchange format,” and that reads as settled in a way the source does not support. It is a shared interchange format whose own current text warns implementers off it. That is still a good reason to use the shape — the tools read it, and a home-grown JSON schema would have all the same instability with none of the ecosystem — but it is not a reason to describe it as stable to anyone.
What the format actually gives you
A token is an object with reserved keys: $value, $type, $description, $extensions. Aliasing is by reference, either {group.token} or a JSON Pointer. There are primitive types — color, dimension, fontFamily, fontWeight, duration, cubicBezier, number — and composite types that assemble them: strokeStyle, border, transition, shadow, gradient, typography.
{
"color": {
"brand": { "primary": { "$value": "#2b6cb0", "$type": "color" } }
},
"spacing": {
"md": { "$value": "{spacing.base}", "$type": "dimension" }
}
}Notice what the format does not give you: names. It standardises the file, not the vocabulary. Nothing in it says a text colour should be called color.text.primary, so two hosts can both be conformant and share not one token name. That is why the brand lesson had you write a mapping by hand, and why no amount of format adoption eliminates the step where a human looks at a host and decides what corresponds to what.
Style Dictionary is a build system, and it is a vendor
Style Dictionary describes itself as “a build-system that runs in both NodeJS and browsers (natively), to parse and transform your design tokens to then export them to any platform.” Its three concepts are platforms, transforms and formats, and it documents itself as forward-compatible with the Design Tokens Community Group specification. That is the project documenting its own product, the same way Module Federation and single-spa document theirs, and it is worth saying out loud when you put it in a contract: the claim that it exports to any platform is the vendor’s claim about the vendor.
One honesty note before you pin a version. Style Dictionary’s own installation page shows v3, v4 and v5 without stating anywhere which is current, as checked on 2026-09-03. This lesson therefore names no version. Run npm view style-dictionary version on the day you install, pin the exact major in your build, and put that number in the graft contract alongside the bundle budget. A build tool whose version you cannot state is a build tool that will produce different output on somebody else’s machine.
The pipeline that fits a tenant, not an owner
A conventional token pipeline has one input: your tokens. This one has two, and the second is the part that is unusual enough to design deliberately. This arrangement is the course’s own, not a recipe from either project’s documentation.
- Your token source. One DTCG file describing your component’s vocabulary and its default values — the
--graft-*names from the brand lesson. This changes when your component changes, which is rarely. - One host descriptor per host. Not tokens. Data about a host: their token names where they have them, measured literals where they do not, and the date each value was checked. This is the artifact that grows with the portfolio.
- One output per host. The mapping stylesheet from the brand lesson, generated, never edited.
hosts/acme.json # host descriptor: their names, or measured values + date
tokens/graft.tokens.json # your vocabulary and defaults, in DTCG shape
# build →
dist/agent-graft.js # identical for every host
dist/host-acme.css # generated mapping, twelve lines, nobody edits itKeeping the host descriptors as data rather than as CSS buys you the thing hand-written files cannot: questions you can answer by running a script. Which hosts have no accent token. Which values were measured before June and are due a re-check. Which hosts would break if you renamed one of your own names. Ninety CSS files answer none of those; ninety JSON descriptors answer all of them.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
Name the two inputs to this pipeline, say which one grows with the portfolio, and say what you would tell a host team about the maturity of the format underneath it.
Check your answer
The inputs are your token source — your component’s vocabulary and default values, in DTCG shape — and one descriptor per host, which records that host’s own token names or the literals you measured, with dates. The host descriptors grow with the portfolio; your vocabulary should barely move.
On maturity, say the true thing. The format is a Draft Community Group Report, not a W3C standard, and its current text tells implementers not to build against that version. You use it because the tools read it and a home-grown schema would be less stable with less ecosystem, and you keep it behind a build step you own so that a change to the draft is a change to one transform. Style Dictionary is the compiler and it is a project documenting its own product, pinned to an exact version you can state.
Hands on
Compile one token source into two hosts
Done when: One DTCG token file and two host descriptors compile to two mapping stylesheets that differ only in their right-hand sides — identical declaration count, identical order — with the exact Style Dictionary version you installed recorded in ARTIFACT.md alongside the date you checked it.
- Write your token source: the
--graft-*names from the brand lesson, each with a$valueand a$type, in DTCG shape. Keep it to the five or six values the component actually renders with. A large token file at this stage is a token file you will regret mapping ninety times. - Write two host descriptors. One is the real host you mapped in the brand lesson. The other is the plain HTML page from the artifact plan, which has no brand at all — that is the case worth having early, because it forces every fallback to be correct.
- Install Style Dictionary and record the version. Run
npm view style-dictionary version, pin that exact major, and write the number and the date intolearning/grafting-ui/ARTIFACT.md. The installation page does not state a current version, so the version you record is the one you observed, not the one anybody published as current. - Build both outputs. Diff them. If the two files differ in anything but their right-hand sides — a missing line, a different order, an extra declaration — fix the build, not the file.
- Load the unchanged bundle in both hosts with only the generated stylesheet swapped, and confirm the component picks up each host’s brand. This is the first checkpoint of the three-host demo arriving early, at two hosts, where it is cheap to fix.
- Bring both generated files into the chat, side by side. I will look for any line that exists in one and not the other.
What this does not cover
Everything here inherits appearance. None of it inherits identity: a component that looks perfectly native and then asks the user to sign in to a service they have never heard of has failed more completely than one that renders in the wrong blue. The session lesson covers what your graft gets for free from the host’s origin, what it does not, and the one browser fact on this subject that most writing still gets wrong.
This lesson also stopped at two hosts on purpose, because two hosts that both run a modern build prove less than they appear to. Putting the same unchanged file into three genuinely different products, one of which predates most of the tooling here, is the demo lesson, and it is the only version of this claim that survives a room.
Read this next — primary source
Design Tokens Format ModuleW3C Design Tokens Community Group — free. A Draft Community Group Report, not a W3C standard. Checked 2026-09-03
This lesson takes the file shape from it — the reserved keys, aliasing, and the split between primitive and composite token types — and takes its status line just as seriously, because the draft tells implementers not to build against the current version. Read the whole document once, including the composite types, so that when a host hands you a token file you can tell what is conformant from what somebody invented. Read the status header first, before any of it.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.