The central requirement most teams bring to an AI-native CMS is deceptively simple to state and brutally hard to satisfy: every page must obey the brand, yet no two pages should look like the same template stamped twice. This chapter explains the architecture that makes "consistent variety" possible — design tokens as the single source of truth, component libraries as the vocabulary, layout primitives as the grammar, and constraint-based composition as the rule that turns a finite kit into an effectively infinite (but always on-brand) page space. It draws on the W3C Design Tokens stable spec (2025.10), the "Every Layout" primitives, the block models of Storyblok/Sanity/Contentful, and how editorial teams like The New York Times, Vox, and The Pudding vary within a system. The thesis: you do not choose between rigid templates and chaos — you design a system with bounded degrees of freedom.
There are two failure modes, and most CMS setups fall into one of them.
The goal is the third option: a system where the allowed moves are all on-brand, and there are enough allowed moves to make every page feel composed for its content. This is sometimes called "templates with degrees of freedom" or constraint-based composition. Borning et al.'s foundational work on constraint-based document layout framed it precisely: arithmetic constraints "provide great freedom in laying out elements" while still guaranteeing the result is valid. A constraint isn't a cage; it's the boundary inside which variety is safe.
A workable on-brand-but-varied system has four layers, each constraining the one above it. AI generation (and human editors) operate at the top, but can only ever produce combinations the lower layers permit.
| Layer | What it is | What it constrains | Standard / tool |
|---|---|---|---|
| 1. Design tokens | Named design decisions (color, space, type, radius, shadow) | The values anything can use | W3C DTCG .tokens.json, Style Dictionary, Tokens Studio |
| 2. Layout primitives | Composable spacing/arrangement patterns (Stack, Cluster, Grid, Switcher) | How things sit relative to each other | Every Layout, CSS Grid/Flexbox, container queries |
| 3. Components | Branded UI parts (card, hero, quote, gallery) built from tokens + primitives | The vocabulary of page parts | CMS block schemas, React/Vue/Web Components |
| 4. Composition rules | Which components may go where, in what order, how many | The grammar — valid page shapes | CMS field validation, block allow-lists, slot rules |
The discipline is that freedom is granted from below, not asserted from above. An editor or an AI never picks a raw hex value; they pick color.brand.accent, which resolves to a token, which is themeable. They never set margin-top: 23px; they choose a Stack with space-m. The variety the reader perceives is recombination of a controlled kit — exactly how a language produces infinite sentences from a finite vocabulary and grammar.
Design tokens are the foundation, and as of October 28, 2025 they have a stable, vendor-neutral standard: the Design Tokens Community Group (DTCG) Format Module 2025.10, the first stable version of the spec (w3.org/community/design-tokens). This matters for an AI-native CMS because it gives one machine-readable contract every tool — design (Figma, Penpot, Sketch, Framer), build (Style Dictionary, Terrazzo), and runtime — can read.
Key facts about the stable format:
application/design-tokens+json and the extension .tokens or .tokens.json. Spec-defined properties are $-prefixed: $value, $type (required), plus $description, $extensions, $deprecated.{group.token.name} curly-brace syntax or JSON Pointer. This is what creates a semantic layer: color.brand.primary → color.palette.blue.600. Editors and AI touch the semantic names; designers can re-point them without breaking anything downstream.$extends, one token set drives light/dark, accessibility variants, and multiple brands. Teams that previously hand-maintained "dozens or even hundreds of token files" can collapse that to a base plus overrides.A minimal token file (DTCG 2025.10 shape):
{
"color": {
"palette": { "blue": { "600": { "$type": "color", "$value": "#1b54f8" } } },
"brand": { "primary": { "$type": "color", "$value": "{color.palette.blue.600}" } }
},
"space": {
"s": { "$type": "dimension", "$value": "8px" },
"m": { "$type": "dimension", "$value": "16px" },
"l": { "$type": "dimension", "$value": "32px" }
}
}
The tooling layer turns this into platform code. Style Dictionary (open-source, originally from Amazon) compiles one token source into CSS custom properties, iOS, Android, and Flutter outputs. Tokens Studio (formerly Figma Tokens) lets designers author and theme tokens inside Figma and sync to the same source. Terrazzo is another reference implementation. Per the DTCG announcement, 10+ tools — including Penpot, Figma, Sketch, Framer, Knapsack, Supernova, and zeroheight — support or are implementing the standard.
Why tokens are the first guardrail: when an AI generates a page, the highest-frequency way to drift off-brand is at the value level — a slightly-wrong blue, an off-scale spacing, an unsanctioned font size. If the only colors, spaces, and type ramps that exist are tokens, the AI literally cannot pick a wrong one. Variety lives in composition; values are locked.
Tokens fix values; primitives fix relationships. The most influential modern formulation is Every Layout (Andy Bell & Heydon Pickering, every-layout.dev), which documents a small set of composable patterns — primitives — that combine to produce most web layouts without page-level media queries.
Core primitives:
| Primitive | Role | On-brand benefit |
|---|---|---|
| Stack | Vertical rhythm — injects consistent margin between siblings via the adjacent-sibling combinator | Every vertical gap is a token; spacing is never ad hoc |
| Cluster | Inline group with consistent gaps that wraps gracefully | Tag lists, button rows, metadata stay tidy at any width |
| Sidebar | Two-column where one column has intrinsic width and the other flexes | Content/aside relationships without fragile breakpoints |
| Switcher | Switches from a row to a stack based on container width, not viewport | Cards reflow by available space, so the same component looks right anywhere |
| Grid | Auto-fitting grid optimized to the inline size available | Galleries that vary column count automatically and consistently |
| Cover, Frame, Center, Box, Imposter, Reel | Specialized arrangements | Bounded options for full-bleed, aspect-ratio, max-width content |
The crucial property: Every Layout's primitives are self-governing and free from media queries, because media queries tie layout to the viewport — wrong for modular components. Instead, the layouts respond to the dynamic space in their container and the intrinsic width of their contents. With CSS container queries (now broadly supported in 2025–2026 evergreen browsers), this is "intrinsic web design": a card knows how to lay itself out based on the slot it lands in, not the screen. That is exactly what lets the same component appear in a one-up hero, a two-up split, and a four-up grid and look deliberate in each — variety with zero new code and zero off-brand spacing.
This is also why "layout primitives" are spreading into component frameworks. React/Vue teams ship <Stack>, <Cluster>, <Grid> components so that the only way to space things is the sanctioned way (dev.to, Structuring React apps with layout primitives; codercarl.dev, Design System Primitives). The primitive is a guardrail wearing the costume of a convenience.
Components are branded parts assembled from tokens and primitives: a Hero, PullQuote, StatCallout, Gallery, Timeline, CTA. The guardrail technique here is variants and slots, not free props.
Hero with variant: "image-left" | "image-right" | "full-bleed" | "text-only". The editor (or AI) picks one of four; all four are on-brand. They cannot invent a fifth. The DTCG spec explicitly supports component-level token references, so a variant's overrides (e.g., inverted text on a dark hero) are themed tokens, not hard-coded.Card exposes media, eyebrow, title, body, actions. What can go in each slot is constrained by type. The card layout is fixed; the content is free.This is the line between structured content and layout. A robust system keeps content as data and layout as a separate, bounded choice — so the same article can be rendered in three different page treatments without re-authoring, and AI can be asked to "render this as a feature" vs. "render this as a brief" by switching variants, not rewriting.
The top layer decides which components are allowed, in what order, how many, and where — the difference between a paragraph and word salad. Modern headless CMSs implement this directly, and they differ in how much freedom they grant editors:
| CMS | Composition model | Where the guardrails live | Editor freedom |
|---|---|---|---|
| Storyblok | "Blocks" — reusable components; editors assemble pages visually inside developer-defined constraints | Block schemas + nestable/allow-list rules; visual editor previews live | High, but bounded — "balances flexibility with guardrails" |
| Sanity | Content is structured data in the Content Lake; schemas in TypeScript; Portable Text + arrays of blocks | Code-defined schemas, array of: allow-lists, validation rules | Highest control for developers; editor freedom is exactly what schema permits |
| Contentful | Structured, form-based content types; references + (newer) experiences/composition | Content-type fields + validations; "optimizes for predictability and low architectural risk" | More constrained, more consistent by default |
(Comparison synthesized from Monterail, Which CMS to choose 2026; Attract Group, Headless CMS comparison 2026; FocusReactive, Sanity vs Storyblok.)
The shared pattern, in Storyblok's words: developers define the blocks; editors assemble pages from them. Or as a common framing puts it: developers "build components once and establish brand guardrails, while marketing teams mix, match and customize those components." The grammar is enforced by:
{type: hero | richText | gallery | quote | cta} — and only those. (In Sanity, this is literally the of: array on a block field.)StatCallout can't be the very first block.PullQuote only inside an Article, not a landing page.These rules are what make the difference between "rigid template" and "constraint-based composition": instead of one fixed sequence of slots, you describe the set of valid sequences. The number of distinct, on-brand pages that set permits is enormous, but every member of it passes the brand bar.
The teams who do this best are newsrooms, because they ship dozens of stories a day that must feel like the publication and feel bespoke to the story.
The takeaway across all three: the higher you push the freedom, the more disciplined the substrate must be. NYT permits moderate composition freedom on a tight component kit. The Pudding permits near-total layout freedom but on an unmistakable visual language and a small set of token-level decisions.
2026's AI design tools converge on exactly this layered model:
The reason this is the answer for AI specifically: an LLM generating layout is a sampler over possibilities. If the possibility space is "any CSS," it will drift. If the possibility space is "valid compositions of these tokens, these primitives, these components, under these rules," then every sample it draws is on-brand by construction — and the temperature of the model becomes the source of the variety you actually want. You get different, never wrong. The design system is, in effect, the AI's prompt-time constitution. Constraint-based composition was a good idea for human page builders; for generative ones it is a prerequisite.
color.brand.*, space.*) so brand re-points without breakage; use it for theming/multi-brand via $extends.of: arrays, Storyblok block rules, Contentful validations) — describe the set of valid pages, not one page..tokens.json, $value/$type, aliases, Oklch/P3 color, and $extends theming — supported by Style Dictionary, Tokens Studio, Figma, Penpot, and 10+ tools. Expose only semantic tokens to authors..tokens.json, $value/$type, references, $extends.