Back to work

Design token architecture
for LLMs

Design tokens are the most machine-legible part of a design system β€” but most token architectures were designed exclusively for human workflows. Re-architecting token hierarchies with LLM interpretation in mind unlocks a new class of AI capability: systems that can reason about design decisions, not just execute them.

Scope Token Architecture
Context AI Β· LLM Integration
Category AI Architecture
Focus Tokens Β· Semantics Β· Reasoning
CORE TOKENS SEMANTIC TOKENS LLM LAYER #0A0A0A #F7C948 16px spacing 1rem type 0.25rem radius color.background.base color.accent.primary spacing.component.md typography.body.base radius.surface.sm LLM processing layer Reason Generate Validate TOKEN ARCHITECTURE Β· SEMANTIC LAYER Β· LLM REASONING Β· DESIGN SYSTEM

Tokens as a shared language between humans and AI

The goal was to re-architect token hierarchies so that LLMs could reliably interpret design intent β€” not just token values β€” enabling AI tools to reason about visual relationships, generate contextually correct UI, and validate design decisions against system rules.

This built directly on the existing three-tier token architecture (core β†’ semantic β†’ component) but extended it with a new layer of machine-readable context.

Tokens weren't designed for AI reasoning

  • Semantic token names carried implicit human meaning that LLMs couldn't reliably infer
  • No formal relationships between tokens β€” LLMs couldn't understand which tokens were related or why
  • Token documentation existed as prose, not structured data LLMs could query or reason over
  • AI tools defaulted to hardcoded values when token names were ambiguous, breaking the system
  • No mechanism for LLMs to validate generated token usage against system intent
  • Token hierarchies designed for CSS cascade, not for AI traversal or reasoning

A token layer built for machine reasoning

  • Extended semantic tokens with structured intent descriptors β€” machine-readable annotations explaining purpose, relationships, and constraints
  • Formalised token relationship graphs connecting related tokens across tiers and categories
  • Created a token manifest: a structured, queryable document of all tokens, their values, intent, and usage rules
  • Developed token validation rules LLMs can reference to check generated token usage for correctness
  • Built a token-to-component mapping layer so LLMs understand which tokens belong to which components
  • Defined a simplified token vocabulary for AI context windows β€” optimised for prompt length and reasoning accuracy

Extending the existing architecture

1

Token Audit Through an AI Lens

Re-examined the existing three-tier token architecture to identify where LLMs were failing to interpret intent correctly β€” focusing on ambiguous names, missing relationships, and undocumented constraints.

2

Intent Annotation Schema

Designed a lightweight annotation schema for semantic tokens β€” adding purpose, usage context, and constraint fields without disrupting existing token workflows.

3

Token Manifest

Built a machine-readable token manifest in structured JSON, covering all tokens with values, tier, category, intent, and relationship data.

4

LLM Testing

Ran iterative tests measuring how accurately LLMs could apply tokens in generated UI with and without the new manifest and annotations β€” tracking error rates and token hallucination.

5

Integration & Documentation

Integrated the manifest into AI tooling workflows and published guidance on FreeStyle for teams using AI assistants with the design system.

Tokens that AI can reason about

🎯

Reduced Token Hallucination

Structured intent annotations and the token manifest significantly reduced cases where AI tools invented token names or defaulted to hardcoded values.

🧠

AI That Understands Intent

LLMs could reason about visual relationships and design decisions β€” not just apply values β€” enabling more sophisticated AI-assisted UI generation.

πŸ“Š

Queryable Token Knowledge

The token manifest gave AI tools a reliable, structured source of truth β€” queryable at generation time for any token's purpose, value, or constraints.

πŸ”—

Design–Code Coherence

Token-to-component mappings ensured AI-generated code referenced the right tokens in the right contexts, maintaining system integrity.

Want to talk through this work?

Get in touch β†’