Don't Tell Anybody — These Are Evals

The design decisions behind Fluent Flex — token reduction, semantic naming, mathematical scales — were made with AI legibility as an explicit goal. The argument: if names encode intent and relationships are mathematical, AI tools should be able to reason over the system the way a designer would. They should be able to infer hierarchy, suggest appropriate values, and generate consistent output without a lookup table.

But "AI-inferable" is a claim, not a fact, until it's tested. The field has no established methodology for evaluating whether a token system can serve as a machine-consumable instruction set. So with Lydia Mitchelson, we built one.

The methodology: Docs 🤝 Schema — a pipeline for translating design language documentation into something a model can reason over, then stress-testing whether it holds.

The starting point: Fluent Flex documentation for spacing, corner radius, and typography — the same docs designers read. The ask to the model: translate this into a machine-friendly schema that can be fed to models for generative UI. Prompt language included: "Some of the pages have really good tidbits of info. Make sure to add those in model-friendly, prioritization language."

The model produced a YAML schema with structured fields for intent, increment, examples, allowed tokens, constraints, and model rules. Raw design knowledge converted into something executable. Notes baked into the schema: "Intent-first: choose semantic tier/level before selecting numeric values" and "Use lowest hierarchy that satisfies clarity; escalate only when needed."

Stress-tested the schema using only the generated schema — no source documentation, no Figma files. Three natural language questions asked directly against it:

The schema was self-sufficient. Correct answers, cited correctly, from the schema alone. No source documentation consulted.

Asked the model for a rationale: what patterns did it find in the raw token values that informed its schema decisions? The model identified four:

Applied the same schema approach to two additional token sets — the Copilot token file and the Fluent 2 token file — which lacked the rich documentation the Fluent Flex system had. The model generated parallel schema structures with inferred role, intent, and constraints from sparse source data alone.

Then: ran a cross-schema comparison across all three design language schemas, asking the same questions of each — long-form reading styles, button vs. modal corner radius, input-to-submit spacing at the roomiest density.

Initial result: mostly accurate, but incomplete. One follow-up constraint revealed the system's real depth:

The stress tests were evaluations all along. Not testing whether the model knew token values — testing whether it could reason over the system the way a designer would. Whether the intent encoded in the names and structure was enough for the model to make the right call without a lookup.

And the stress tests revealed something more important: the design language structure either causes or prevents specific AI failure modes.

When a model is asked to generate UI from intent, there are identifiable ways it breaks — and the design language structure is a primary cause or prevention of each one.

The cleanup work — token reduction, semantic naming, mathematical scales — was infrastructure investment all along. Not just for designers and engineers. For AI.

Already in practice: AI used to automate accessibility testing between foreground and background color tokens across all 58 canonical pairings, recomputing in real time when a custom brand is applied. AI used to validate group token naming conventions against the schema. The evaluation wasn't theoretical — it was confirming what was already being built.