The standard is finished. The toolkit is not.

The system answers what is true and what is forbidden with real authority. It does not yet answer give me the thing. A designer opening it to build a Google Ad gets six laws and six hex values. A developer starting a second website gets a palette and retypes every button by hand. A volunteer opening Canva gets a kit this repository has never heard of.

The distance between the standard and the artifact is where drift is born, and right now that whole distance is covered by human judgment and goodwill. Every layer that closes it converts a judgment call into a default.

Concretely: tokens.json stops at color and type family. There is no spacing scale, no named type scale, no elevation, no motion, no neutral ramp, no print color space. components.json describes thirteen components in prose and ships CSS for none of them, so the only way to reproduce a card is to read the portal's inline stylesheet. And no file anywhere states what a 1080 by 1350 post, a 600 pixel email, a responsive search ad, or a 300 dpi tri-fold is supposed to be.

brandsource.py recovers structured facts by running twenty-odd regular expressions over brand/index.html: the :root block, the token table rows, the proportion heading, the changelog. It works, it fails loudly, and it has held. But the direction of authority is inverted. The presentation layer owns the data.

Three consequences, in increasing order of cost. A designer cannot propose a color change without editing a hundred-kilobyte HTML file. Any visual redesign of the guide is a breaking change to the build. And a fact with no natural visual home has nowhere to live, which is exactly why ai-source/ exists as a second parallel truth alongside the first.

The fix is to invert it: a structured token source generates the guide's :root and its color and token tables, and the guide keeps owning prose, which genuinely does belong in markup. Do this last, after the value is proven, or skip it if phases one through five land cleanly.

Your Canva account currently holds two brand kits: "THE WORD Branding Kit" and "THE WORD FOR ALL THE WORLD". Neither is governed by this repository, neither carries a version, and nothing anywhere can tell you which one a volunteer used last Tuesday.

Canva matters more than Figma here, because Canva is where the people who are not designers actually make things: the flyer for a city gathering, the certificate, the conference recap post. That is where a brand actually breaks, and it is the one surface this system currently cannot see.

Do: consolidate to one kit. Stamp the version into its name, so THE WORD · v6.8 is visible to everyone who opens it. Load exactly the six colors and three families, no extras. Build locked Brand Templates for the five recurring jobs rather than leaving people on a blank canvas. Then register the kit id in the repository with the version it was last synced to, so the linter can say out loud that Canva is running v6.6 while the standard is v6.8. Push what the Connect API supports and print a short manual checklist for the rest.

This is exactly the loop you described: a designer proposes a change as a pull request against the token source, it is reviewed and merged, and an action pushes the new values into Figma Variables through the REST API. Their library updates. Nobody retypes a hex.

The library file carries Variables for color, type, and spacing, Text Styles, Effect Styles, and components whose names match components.json ids exactly, so a Figma layer and an audit finding refer to the same thing. Register the file key alongside the Canva kit with its synced version.

The rule that makes it work: Figma is a consumer, never an origin. The moment someone changes a variable in Figma instead of in the repository, you have two standards again, and the one with the nicer interface always wins.

These are two different jobs and the answer differs for each. In the brand repository, Storybook means Node, a component framework, a bundler, and a dependency tree that needs maintaining, all to document HTML snippets. That contradicts the property that makes this system good, and it buys one thing you actually want: a page where every component renders live next to its spec.

Generate that page instead. /components/, built by build_ai.py from components.json, rendering each component with its spec, its copyable HTML, its do and don't, and its appearance on both grounds. Zero new dependencies, correct by the same mechanism as everything else here.

In a Next.js product repository, Storybook is a reasonable and probably good choice. It documents your React components, which is not what the brand repository publishes. Name each story after the component id in components.json, so a story, a Figma layer, and an audit finding all refer to the same thing by the same name.

The plan below was written assuming this repository was the only codebase. If you are building Next.js sites and apps, the architecture holds unchanged, but the package that phase one treats as optional becomes the main delivery mechanism, and it should ship in phase one rather than later.

What changes. A React application does not consume brand.css, it consumes tokens and builds its own components against them. So publish @theword/brand as an installable package carrying the tokens as CSS custom properties, as typed TypeScript exports, and as a Tailwind preset. Then a brand version bump opens a dependency pull request in every application repository automatically. That is the mechanism that makes "a designer changes the standard and everything updates" reach the apps, rather than stopping at the portal.

What stays. brand.css is still worth building, because the majority case is not a Next.js app. It is a landing page, a partner microsite, an email, a page someone builds in an afternoon. Both artifacts come from the same token source, so they cannot disagree.

Two small Next.js specifics. Load the three faces with next/font/google rather than a stylesheet link: it self-hosts at build time, which removes the third-party request and the layout shift, and it matches the self-hosting already recommended in phase zero. And keep theming in CSS custom properties rather than a JavaScript theme object, so it works unchanged in server components.

Worth being explicit, because it is the assumption most likely to cost you a rebuild. You cannot import a card out of the HTML gallery into a Next.js app. What travels between them is the token layer and the specification, not the markup.

A React Card in an initiative app looks identical to the Card in the gallery because both read the same variables, spacing, radii, and states from the same source. But the React version is written once, by hand, in a library that every initiative app installs. That library is the thing that travels, and it is worth building precisely because you have more than one app.

Three artifacts, three jobs, one source underneath all of them.

Why not collapse this into one React library. An email cannot consume React, and neither can a static microsite or a partner's own CMS. If the only real components live in React, the brand forks the first time someone builds outside Next.js, and it forks quietly. Tokens sitting underneath both implementations is what prevents that.

Neither implementation is the source. components.json is. The gallery and the React library are both consumers of it, registered with the version they were built against, exactly like Figma and Canva. One id names each component in the gallery, in its Storybook story, in its Figma layer, and in an audit finding, so a Card is a Card everywhere anyone looks it up.