From Tokens to Thinking Systems: Making AI-Native Design Systems Actually Work

In AI Design Systems: Why Tokens, Schema & Generative Rules Matter Now, Rythm lays out a clear and timely thesis:

Design systems are no longer built for designers. They are built for AI.

I strongly agree with that direction, and I would argue we are now past the theory phase. The interesting failures I see in client work and in open experiments are not philosophical. They show up as the same diff, again and again: a component that looks fine in Storybook, reads well in Notion, and still produces the wrong DOM, the wrong focus order, or the wrong token when an agent assembles a screen from a one-line prompt.

The real question in 2026 is no longer why tokens, schema, and generative rules matter, but how we make them usable by real LLMs today, without hand-holding or tribal knowledge. That is the gap I have been trying to close with schema templates you can hand to a model and expect a repeatable result, not a lucky Friday afternoon.

This article is a response and a concrete extension to Rythm's framing. It stays focused on one thing: LLM-consumable design systems that can actually generate UI, not just talk about it.

The Missing Piece: AI Needs Contracts, Not Concepts

Rythm correctly identifies the three pillars of AI-ready design systems: tokens, schema, and generative rules. Tokens carry visual and semantic intent. Schema names what a component is allowed to be. Generative rules connect context (variant, mode, density, domain) to the token overrides that should apply. Together they are supposed to replace the designer's implicit judgment with something a model can execute.

Most teams already have the first two in some form. Figma variables, Style Dictionary exports, Storybook props. The third pillar is where documentation usually stays fuzzy. A slide says "primary uses brand accent in light mode," and everyone nods. An LLM does not nod. It needs a rule object with inputs, conditions, and outputs.

"generativeRules": {
  "contextInputs": ["variant", "mode", "density"],
  "rules": [
    { "if": { "variant": "primary" }, "then": { "tokens": { "color": "brand.accent" } } },
    { "if": { "variant": "destructive" }, "then": { "tokens": { "color": "semantic.error" } } },
    { "if": { "mode": "dark" }, "then": { "tokens": { "surface": "neutral.surfaceElevated" } } }
  ]
}

But there is an implicit assumption hiding in most discussions: if we define these things clearly enough, AI will understand them. In practice, that is not how LLMs work. They do not infer intent from prose, diagrams, or Figma pages the way a senior designer does after three years on the same product. They operate best when given explicit, machine-readable contracts: deterministic structure, declared constraints, named responsibilities, and predictable output shapes. In other words, schemas that leave very little room for interpretation.

Behavior and interaction deserve the same treatment as color. A paragraph in the docs that says "accordion panels close when another opens" is not enough. The contract should state the default state, the state model (controlled vs uncontrolled), and what renders when.

"behavior": {
  "map": "Clicking a trigger opens a panel and closes others.",
  "stateModel": "uncontrolled",
  "rendering": "Panels render only when open.",
  "defaultState": "all closed"
},
"interaction": {
  "logic": [
    { "trigger": "onClick", "effect": "toggle panel" }
  ],
  "feedback": {
    "hover": "highlight trigger",
    "focus": "focus ring",
    "active": "press feedback"
  }
}

Accessibility is the same story. WCAG checklists in a wiki do not survive contact with a generative prompt. Roles, relationships, and keyboard paths need to be part of the schema so the model cannot "helpfully" invent a div with a click handler where a button belongs.

"accessibility": {
  "roles": {
    "container": "div",
    "primary": "button",
    "panel": "region"
  },
  "aria": {
    "expanded": "true when open",
    "controls": "panel-id",
    "labelledBy": "trigger-id"
  },
  "keyboard": "Enter/Space toggles panel"
}

Without that level of explicitness, AI-generated UI quickly becomes visually plausible and structurally wrong. You get inconsistent spacing across runs, focus traps that only show up in production, and brand drift that no linter catches because the output never touched your token files. That is not a model quality problem. It is a contract problem.

The Shift I am Proposing: From Design Systems to Generation Systems

Traditional design systems answer a human question: how should a person assemble UI from approved parts? The documentation, the Figma library, and the Storybook stories all assume someone is making judgment calls in the loop. AI-native design systems have to answer a different question: under what conditions is UI allowed to exist, and how should it be derived?

That shift changes what you document. Components stop being static artifacts you copy from a gallery. Variants stop being endless enumerations in a dropdown. Documentation stops being explanation that only makes sense after you have already built the thing. Instead you describe components as semantic objects (what they mean, where they may appear), behavior as logic that can be evaluated (not bullet points), and screens as outcomes of rules plus context.

The goal is not to remove designers. It is to move their work up a layer: from placing instances to defining the system that places instances correctly when asked.

Two LLM Template Schemas (Public, Opinionated, Practical)

To explore this paradigm, I have prepared two publicly shared LLM template schemas designed explicitly for design-system autogeneration. They are not tied to a specific tool, vendor, or framework, though I have also published a Tailwind-oriented variant for teams that live in utility classes. They are meant to work with any capable LLM, as long as you treat the JSON as source of truth and the prose around it as commentary, not the other way around.

1. Design System Semantic Schema

This schema answers one core question: what is this thing, really? It defines components as semantic entities, not as rectangles with padding. At a high level it encodes identity and purpose, allowed contexts, required vs optional properties, interaction states, accessibility obligations, and containment rules (what may nest inside what).

A button in this model is not "a clickable rectangle." It is an action trigger with intent (primary, destructive, passive), behavioral guarantees (what happens on press, loading, disabled), accessibility constraints (name, role, keyboard), and layout implications (inline vs block, icon placement). That gives the model comprehension, not just a class string that happened to match last time.

2. Generative Rule and Token Resolution Schema

The second schema answers a different question: given a context, how should this UI adapt? It formalizes token resolution logic, conditional overrides, environmental triggers (mode, density, accessibility preferences, viewport), precedence when two rules conflict, and safe mutation boundaries (what an agent may never override without a human flag).

Instead of hardcoding twelve navigation variants, you describe evaluations: if accessibility mode favors low vision, adjust typography and contrast tokens; if viewport width drops below a threshold, switch navigation pattern; if the surface is financial data, prioritize numerical hierarchy tokens. UI becomes adaptive by default, not adaptive by exception after someone files a bug.

Why This Matters (And Where Many Systems Fail)

Most AI design system experiments I have reviewed fail for a simple reason. They describe systems. They do not define execution logic. The Notion page is beautiful. The Figma file is meticulous. The prompt still hallucinates a secondary button style because nothing in machine-readable form said it could not.

LLMs are extremely good at following rules, but only if those rules are explicit, scoped, and validated. When you separate semantic meaning, token intent, and generative behavior into distinct layers, you give the model just enough structure to produce UI that stays consistent, accessible, brand-aligned, evolvable, and auditable. Auditable matters: if a screen is wrong, you want to trace which rule fired, not re-run the prompt until luck improves.

This Is Meta-Design, Not Automation

Rythm frames this shift well when he writes that your job moves from designing screens to designing the logic that generates screens. These schemas are my attempt to make that shift operational, not aspirational.

They do not replace designers. They raise the abstraction level of design work. You spend more time defining intent, encoding judgment, shaping constraints, and anticipating misuse (what happens when someone asks for a destructive primary button on a checkout step). The model's job is execution inside those boundaries. AI does not design in the sense of owning tradeoffs; it runs the system you designed.

Where This Is Going Next

I expect the next wave to look less like "chat to UI" and more like schema-driven UI APIs, token-only brand definitions, AI-assisted design QA in CI, runtime-adaptive interfaces, and workflows where Figma artifacts are outputs of the system rather than the source of truth. None of that works unless the contracts are right first. That is what these public schemas are for: a place to stress-test the idea with real prompts, real products, and real criticism.

Validation checklist

Before you trust generated UI in a pipeline, walk through this list against your own components. It is deliberately boring. Boring is what keeps agents from improvising.

• Schema uses required sections with meaningful content.
• Behavior and interaction maps match actual component behavior.
• Constraints align with real layout limitations.
• Accessibility roles and keyboard rules are accurate.
• Generative rules map to tokens or Tailwind classes correctly.
• Storybook exposes schema for review and auditing.

Open Invitation: Tear This Apart

These schemas are public by design.

They are:

I would rather ship something wrong in the open and fix it with your production scars than polish a PDF nobody runs against GPT-4o on a Monday morning.

If you are working on:

I would genuinely love your critique.

• What is missing?
• What is naive?
• What breaks under real product pressure?

I have linked the schemas below. Comments, suggestions, and brutal feedback are very welcome.

LLM Component Schema Template (Gumroad)

PS. I promise to follow up with an updated version if I get good suggestions or comments!

LLM Component Schema Guide. MIT Distribution License. Copyright Petri Lahdelma Digitaltableteur. digitaltableteur.com

Build systems, not screens, but make sure your systems are precise enough that AI cannot misunderstand them.