What a design rule is — and what it is not

The phrase “designers will write rules instead of screens” is easy to repeat and incomplete on its own.

The useful question is more concrete: what has to be written down for a decision to survive the moment, the person and the interface that first produced it?

A token stores a value. A component exposes a capability. Neither knows when it should be used. A rule is the missing layer: it says when a decision applies, what must happen, what is not allowed, what happens when context is missing, who can approve an exception and how the result is checked.

tokens → components → rules → decisions → interface

The first two make a system readable. Rules make it governable.

Four levels, not one claim

I use four levels to avoid calling a system “agent-ready” too early:

readable      a machine can inspect the system
usable        it can use known pieces
governable    it knows what is permitted, required and forbidden
verifiable    the outcome can be checked

Exporting tokens as JSON helps with readability. Publishing a component registry helps with usability. Most systems stop there.

Governance begins when the system can say that a destructive action needs confirmation, a screen has one primary action for its context, or an assertion cannot be published without its source. Verification begins when those statements can fail a build, reject a composition or ask for human review.

Rules have different weights

Not every rule should compete in the same layer.

invariants    never overridden
policies      product choices that can be debated
preferences   defaults that can be changed

Accessibility belongs in the first layer. A visible focus state is not a product preference. A policy may change a default, but it should not turn off an invariant.

Exceptions are also part of the system. A real exception names the rule, gives a reason, records who approved it and expires. An unnamed override is just forgotten debt.

The limit of this proposal

This is a working model, not a standard. It still leaves hard questions: who versions the contract between server and device, how a rule is evaluated when context is incomplete, and which decisions should never become executable.

That uncertainty is deliberate. The point is not to pretend that a system can replace judgement. The point is to make enough judgement explicit that an agent cannot quietly invent it.

Continue the research

• Read the original research in Spanish.
• See the methodology.
• Explore a diagnostic for a team working through these questions.