# Designesy — /contracts/guardrails Canonical page: https://www.designesy.org/contracts/guardrails --- ## Guardrails Guardrails are the product layer: ingest a design system, emit a frozen build contract for AI coding agents — the file the agent reads, plus the lint config that enforces it. "Tokens are a contract, not a library." Version 0.1.0 · provisional · [machine export](/contracts/guardrails.json) ## Source authority Designesy research 2026-08-01 DLS Lead — "treat the design system as an API, not a library... CI fails if either side breaks the agreement" davekurian (dev.to) — "tokens are types... you're removing the off-brand options from the API it consumes" zeroheight Design Systems Report 2025 — token adoption 84% (up from 56% in 2024), but 40% still sync tokens by hand ## Output bundle Fetch the URL, extract all CSS + :root custom properties, parse token values into DTCG format, generate lint rules from the allowed values, emit the AGENTS.md rules file, derive component contract patterns, generate the DESIGN.md file (Google open spec). ## Verification 6 checks — 6 checks. PASS=1, FAIL=0. Score = (points/6) × 100. A≥90, B≥80, C≥70, D≥60, F<60. Note: the guardrail emitter is an output generator, not a scoring engine — the score reflects emission completeness, not design quality. ## Open questions - The component contract (g04) is heuristic — it infers patterns from token names, not from actual component code - The lint config targets Stylelint — teams using Lightning CSS or Biome need a different config format - The agent rules file uses AGENTS.md format — teams using Cursor.cursorrules or Claude CLAUDE.md need format adaptation - The emitter does not verify that the guardrail file actually prevents drift — that requires running the lint against AI output ## Run it Generate a guardrail bundle for any URL: