Can an AI Agent Verify Material Design 3 Compliance From Token Files Alone?

Most design frameworks are advice: readable, arguable, and useless as automated checks. Material Design 3 is the exception that proves the rule — Google publishes the framework’s values as literal constants in open-source token files and its color logic as a reference algorithm. This is a test of how much of M3 an agent can verify as arithmetic, and where the 2026 Expressive direction ends the constant tables.

Hypothesis

Material Design 3 is unusual among design systems: it publishes its own arithmetic. Hypothesis — an AI agent can verify most static M3 compliance from token files and computed styles alone, because state layers, elevation, shape, type, and dynamic color all resolve to published constants. What it cannot verify is semantic correctness: surface hierarchy, source-color intent, and Expressive motion.

Method

The audit an agent would run has four passes. Pass threshold: ≥ 90% token membership.

1. Token-file parse. Google ships M3’s constants as open-source SCSS in the material-web repo, so ground truth is a data file. The state-layer tokens fix interaction opacities at 0.08 (hover), 0.12 (focus), 0.12 (pressed), and 0.16 (dragged). The elevation tokens define exactly six levels — 0, 1, 3, 6, 8, 12 — as web level numbers, not dp values. The shape tokens set corner radii at 0, 4, 8, 12, 16, 28, and 9999 px (none through full). The type-scale tokens enumerate 15 roles, each a (size, line-height, tracking, weight) tuple: body-small at 0.75rem/1rem, body-medium at 0.875rem/1.25rem, body-large at 1rem/1.5rem, display-large at 3.5625rem (57px).

2. Computed-style membership. Diff every rendered element’s computed styles against the published values. Any value outside the constant set fails.

3. Dynamic-color regeneration. Given the app’s source seed, run the material-color-utilities reference implementation to regenerate the five tonal palettes — primary, secondary, tertiary, neutral, neutral-variant — in HCT space (hue 0–360, chroma ~0–120, tone 0–100), then diff against the app’s color roles per scheme variant.

4. Tone-delta contrast. Contrast in M3 is a function of tone: “colors with a greater difference in tone create higher contrast” (dynamic color scheme). The agent verifies each on-role pair meets the framework’s requirement.

Results

The boundary between checkable and uncheckable is clean.

Fully checkable: state layers, elevation levels, shape corners, and all 15 type roles are static constants — deterministic pass/fail on every element.

Deterministic given the seed: dynamic color is reproducible. The same source seed yields identical tonal palettes on every run of the reference implementation, so color-role diffs are exact rather than fuzzy.

Breaks the constant model: at Google I/O 2026 (May 19), the framework announced its Expressive direction — a layout-system scaffold adapting across mobile, desktop, and spatial contexts, plus physics-based motion built on mass, spring, and timing. None of this reduces to a token diff; there is no SCSS file listing which spring a screen deserves.

Uncheckable without interpretation: which elevation level a surface should receive — the elevation overview describes purposes, not a decision procedure — which wallpaper or seed was chosen and why, and whether motion communicates the intended product meaning.

Conclusion

M3 compliance splits into arithmetic and intent. The arithmetic half is genuinely inspectable today; the intent half is not, and grows larger as Expressive moves the framework past constant tables.

Computable rule: given the M3 token files and a source seed, verify compliance by asserting token-membership of computed styles at ≥ 90% and confirming that regenerated tonal palettes match computed color roles. Anything requiring product-level intent — surface hierarchy, seed selection, Expressive motion — stays outside arithmetic and needs human design judgment.

This analysis is based on Google’s published specification pages, the open-source material-web token files, and the material-color-utilities reference implementation; we did not build or test an M3 application hands-on.

Rule: framework-constant-coverage — a computable rule the weekly Empire Design Scan can check: For any page claiming Material Design 3 compliance, parse the published constants (state opacities {0.08 hover, 0.12 focus, 0.12 pressed, 0.16 dragged}; elevation levels {0,1,3,6,8,12}; shape radii {0,4,8,12,16,28,9999}px; 15 type-scale size/line-height pairs) and assert computed-style membership — any value outside the published set fails. Given a source seed, regenerate the five tonal palettes with material-color-utilities and diff against computed color roles; verify on-role tone deltas meet contrast requirements. PASS if >= 90% of sampled styles match published constants AND regenerated palettes match roles. Never auto-pass semantic decisions (surface elevation intent, seed choice, Expressive motion) — route to human review.