Not taste. Conditions. Every rule below is written so a person or an agent reaches the same answer from the same inputs — and so that when two rules disagree, the order of precedence settles it rather than the loudest opinion in the room.
The core ruleUse the baseline by default. Change, combine, automate, personalise or invert it only when a specific user condition justifies the change.
{{ ruleCount }} rules · {{ setCount }} rule sets
Step 01
Required inputs
Twelve values. If they are unknown, do not make strong stylistic decisions — use the baseline or ask.
{{ i.k }}{{ i.v }}
Step 02
Priority order
When rules conflict, the higher line wins. No exceptions, including for the brand.
{{ p.n }}{{ p.t }}
{{ c.a }}{{ c.b }}
Step 03
The universal element rule
Every element must do at least one of these eight jobs. None of them, and it goes. More than three, and it splits.
{{ j.n }}{{ j.t }}{{ j.d }}
{{ r.a }}{{ r.b }}
{{ g.n }}{{ g.t }}
{{ g.role }}
{{ r.a }}{{ r.mid }}{{ r.b }}
Never
{{ n.t }}
Engine 01
Escalation
Start at baseline. Move one step only when a named condition justifies it — and stop the moment the component stops contributing.
{{ e.n }}{{ e.t }}{{ e.d }}
The escalation testBefore adding complexity, answer six questions. If every answer is no, do not add it.
{{ t.t }}
Engine 02
Section selection
Read down until a condition is true. This is what stops a page becoming a stack of fashionable sections.
{{ s.a }}{{ s.b }}
Engine 03
Page assembly
One outcome in, one primary action out. Everything between earns its place.
{{ a.t }}
Remove a section when{{ r.t }}
Engine 04
The assembly loop
{{ l.n }}{{ l.t }}
Agent-readable
Every pattern, documented the same way
A screenshot in a library tells you nothing about when not to use something. This schema is the difference between a gallery and a system a machine can build from.