# How do you audit a design system in code?

Source: https://saer.app/guides/audit-design-system-in-code
Updated: 2026-10-22

**Short answer.** Audit the code, not the documentation. Reconstruct what is declared (tokens in every theme, components), read everything that is used, and compare the two. A useful audit separates deterministic findings (a raw value identical to a token) from inferences (a value close to a token), cites the files for each, and says plainly what it could not determine.

## The areas to cover

- Colour: tokens per theme and mode, exact drift, near-matches, dead and conflicting declarations.
- Typography: the type scale in use, raw sizes on and off the scale.
- Foundations: spacing, sizing, radius, shadows, z-index, breakpoints, borders, opacity, motion.
- Components: inventory, duplicates, variant sprawl, overrides, unused components.
- Accessibility: contrast of real text and background pairs in each theme, focus styles, target sizes, reduced motion.

## What makes an audit trustworthy

Determinism (the same code gives the same findings), evidence (every finding names its files), and honesty about uncertainty (an unresolved value is reported as unresolved, never guessed). Without these, an audit becomes a list of opinions that teams argue about instead of fixing.

## Running one with Saer

A first scan:

```
$ cd your-project
$ saer scan
# report: .saer/report.html
# data:   .saer/system.json
```

Saer reads only; it writes its report into `.saer/` and changes nothing else. See [getting started](https://saer.app/docs/getting-started).

## What Saer does about this today

- Colour: in the beta.
- Typography, foundations, components, accessibility checks and website audits: in the beta.

## Not built yet

- The unified audit report across every area, with traceable scores: planned.