The method · Correct by Design

The method distinction

Two questions.

Reading finds the cause. Building finds the gap.

Read

Is it capable of guiding an agent?

Scattered tokens. Permissive APIs.

Documentation outside the repo.

Blind to what is missing.

Build

What happens when an agent uses it?

A gap exists only against something someone actually tried to build.

Blind to why it happened.

What is measured

Six properties. Most design systems have one or two.

An agent reads your repository literally. Each property is scored 0 to 5 with the evidence attached.

01
Constraint

Wrong output is impossible, not discouraged.

The component API and the type system make illegal output fail at build time. Nothing relies on anyone reading a guideline, and nothing can decay when attention moves on.

02
Single source

Every visual decision lives in exactly one place.

One definition, one place. Change it once and it propagates. Anything that still needs hand-editing was never a source of truth.

03
Legibility

The rules are in the repository, and every component says what it's not for.

Guidance an agent must leave the repository to find is guidance it will not read. The line that matters most is the boundary: what each thing is not for.

04
Fidelity

The documentation cannot drift from the code.

Not should not. Cannot. When the docs and the code disagree, the build fails. Intent is not a mechanism.

05
Adherence

The system is the easiest way to build.

What sits in the application is what an agent treats as precedent. This count is not a record of debt. It is a prediction of what your agent will copy.

06
Completeness

The system knows what it's missing.

Gaps are recorded when something needed does not exist, not improvised into one-offs. That demand data becomes the roadmap.

Diagnostic outcomes

Four shapes of the work.

The score is not the product. What the audit finds decides what kind of work comes next.

What the audit findsWhat it meansThe work

Low constraint, low legibilityA component library, not infrastructure.The full build

Good docs, low constraintIt holds by convention and goodwill.Harden the API

Good system, low adherenceAdoption and governance are the problem.The ownership clause

Good everything, many gapsMature, and still incomplete.The gap roadmap

Whatever the shape, the through-line is the same: the design moves into the code, and someone owns it there. That is what turns a component library into infrastructure.

The standard

What the six look like when they're all satisfied.

There is a system built to all six by construction, and a working application an agent composed from it with no design direction. The home page carries that claim; the system itself is available to look through on request.

Available to look through on request. The system, the application, and the code underneath both. Request the sample →

A worked example

What an audit turns up, and what it leads to.

Nivoda, a global B2B jewellery marketplace running Material UI. The audit counted:

81per-component override files fighting Material's defaults

723inline style escapes, every one a place a token could be ignored

32component-specific token files maintained by hand

…and 89 separate styleOverrides passes underneath them. The team was paying, continuously, to make Material UI not look like Material UI.

Nobody had decided to do that. It had accreted over years. And until it was counted, nobody could argue about it.

That audit became the rebuild: a token pipeline, sixty-three components, agent-readable documentation, and a design team that moved into the codebase and stopped handing pictures to engineers.

The drift-checking didn't get faster. It stopped being necessary. The build could no longer disagree with the design. What was left for the team to judge was whether the design was right.

The system is running in production. Read the full case study →

What this will not tell you

Three honest limits.

It does not tell you whether your design is any good.

It measures whether the build can disagree with the design, and whether an agent can follow the system. Whether the design is the right design stays with your team.

It does not score what it cannot see.

If it cannot be measured, it comes back as not measured, with the reason. That never renders as a failure.

It is not a certification and there is no badge.

The output is a measurement with the working attached. You can disagree with any part of it and check it yourself.

Encode design law.