Design system context for AI tools

Why generated UI drifts

A model asked for a settings screen will produce a settings screen. It will also produce a grey it invented, a corner radius it liked, a button that is nearly your button, and spacing that is nearly your scale. Nothing in the request told it otherwise.

The usual fix is to paste the rules into the prompt. That works once. Then the next tool gets re-taught the same system by hand, and the one after that, and the output still drifts, because a paraphrase of a system is not the system. Every tool holds a slightly different copy, and none of the copies has a version number.

What “generates from nothing” looks like

The failure is not dramatic. The screen works, it is laid out sensibly, and nothing about it looks like a mistake. Then you look closely. The border is a hairline at a grey one step off the one you use. The vertical rhythm runs on multiples of five where your scale runs on four. The primary button has your label face and a radius you retired last year. The empty state has a heading tone the brand team spent a week ruling out. Every one of these is a decision the tool had to make and had nothing to make it with.

Multiply that by the number of tools in the building. Each one invents its own near-miss version of the system, and none of them is wrong in a way that fails a test.

What each layer prevents

The three layers each stop a different failure, which is why a partial answer does not work.

A token prevents the invented value. Given the token, the tool does not need to judge which grey is your grey; it uses the one that is. This is the layer most teams have something of already, and the layer that most often ships as an unversioned copy.

An asset prevents the substitute. Given the approved logo, the type files, and the component, the tool is not reconstructing your mark from a description of it. A near-miss here is the one people outside the team notice.

A rule prevents the wrong-but-valid use. Every value in the output can be a real token and the screen can still be wrong, because the destructive colour is doing decorative work, or the display face is set at body size, or a warning tone is carrying good news. Values alone do not catch that. Only a written rule does.

A hint and a constraint

Structured context is the system in a shape a machine can read without guessing: the rules, the token values, and the approved assets, addressable and versioned, rather than prose describing them.

The difference is between telling a tool “use our brand blue” and handing it the token, the value, the version it belongs to, and the rule about where it may be used. The first is a hint. The second is a constraint the tool can satisfy exactly, and that a reviewer can check.

A hint has to be interpreted, and interpretation is where the drift enters. It is also unfalsifiable: nobody can say whether a screen followed “keep it calm and spacious” or not. A constraint names a thing that either was or was not used, so it can be checked by someone who was not in the conversation.

Review instead of correction

Correction is what most teams do today. Something is generated, a designer reads it closely, finds the six near-misses, writes them up, and the loop runs again. The cost scales with the amount of output, which is exactly the wrong way round now that output is cheap. It also depends on the reviewer holding the whole system in their head.

Review is the other shape. The values and the assets are the real ones because they came from the source, and the reviewer’s attention goes to the questions only a person can answer: is this the right pattern for this job, does the tone fit, is the rule being applied where it makes sense.

How Riyar plans to serve it

Riyar’s third module, Serve, is being built to do exactly this: documentation for people, and structured context for AI tools through MCP and API. One source, read two ways, so the page a designer opens and the context a tool pulls come from the same place and cannot disagree.

That delivery is planned, not shipped. Riyar is in development, and the MCP and API surfaces are part of what is being built rather than something you can point a tool at today.

What changes for agents and generative tools

For a coding agent, the change is that the tokens and components it reaches for are the real ones, at a known version, instead of plausible ones. For a generative tool, it is that logos, type, and color come from the approved set rather than from a description of it. In both cases the work moves from correcting output to reviewing it.

What is being served is the material described in decisions, tokens, assets, held in the single source of truth those tools are reading from.