A design system your boards are actually held to
Most design systems are a document everyone agrees with and nobody is stopped by. Rezee's is a document a board names, enforced on the write - with an escape hatch, an exact-match rewrite, and a refusal that tells you the nearest token.
Aug 25, 2026 · 4 min read · Kash Gohil
Every design system has the same failure mode. It is written down, everyone agrees with it, and six months later the boards are full of hex codes nobody can trace. Not because designers are careless - because the system was a document beside the work rather than a rule the work was held to.
Rezee's design systems are the second thing. A board names a system, and from then on it may not state a value the system has not named.
The system is a document you can look at
A design system in Rezee is docs.kind = 'system' - the same document row a spec, a board and a deck are. Its body is an ordinary scene: a swatch grid and a type ramp, drawn in its own tokens.
That last part matters more than it sounds. A token table in a settings page is a thing you administer. A system whose body is a drawing in the vocabulary it defines is a thing you review - and because it is a document, it arrives with everything a document has: node-anchored comment threads, sign-off, version history, restore.
So "we are changing the brand colour" is a reviewable event with somebody's name on the approval, not a Friday afternoon in a settings screen.
A board names one, or none
A board points at a system through docs.system_doc_id. Null means ungoverned, which is what every board drawn before systems existed still is. No migration ran, nothing broke, and a team can adopt this one board at a time.
There is no version pinning, and that is deliberate. A board references the system the way an instance references a component: an edit reaches every consumer. Pinning would turn "we changed the brand colour" into a migration across every board in the workspace, which is the exact problem the feature exists to remove.
The honest cost is that a system edit is a wide edit. So it is priced where it is made: the review panel states the blast radius first - how many boards, decks and instances change - with a before-and-after render, in front of the person approving it.
Four rules, and three of them are about being usable
Governance runs on the write, not as an audit afterwards. A board that renders fine and is quietly full of stray hex is exactly the drift a system exists to stop.
A role governs a slot only if the system names tokens for it. No radius tokens in your system, no opinion about radius. This is the escape hatch, and it is a property of the system rather than a flag on a node - because a per-node exemption is the drift mechanism the whole idea is against.
An exact match is rewritten, never refused. Someone who knew the value and spelled it the long way is not making a mistake worth a sentence. This kills the commonest machine failure - an agent reads the system, then writes the hex it just read - and costs nothing.
A refusal names the nearest token. By CIE76 ΔE for a colour, by distance for a number. For an agent the tool vocabulary is the documentation, and an error is the only documentation that arrives at the moment it is needed. One retry beats one document read.
Geometry is never governed. There is no x among the governed slots, and "none" is never refused - the absence of paint is not a choice of paint.
Assigning a system to a board you drew last year
The same pass runs in a second mode. Instead of refusing a departure it rewrites it to the nearest token, which turns adopting a system on an old board from an afternoon into a batch.
You get a diff to look at, in a document with history, that somebody has to approve.
Modes came later, and cost one field
Dark mode arrived a milestone after systems did, and the interesting part is what it did not change. A mode is flattened into a plain token map by the caller and injected - a token's value stays the default mode and modes holds the others.
Threading a mode through token resolution, layout, rendering and governance would have put a fifth argument on every seam in the engine to carry a fact only the reader of a system document needs. Flattening at the boundary means the engine cannot disagree with itself about which answer applied.
The payoff: every system built before modes existed is a one-mode system that migrated by doing nothing, and a forty-token vocabulary can grow a dark mode six tokens at a time.
What this is not
It is not a rule engine for taste. It governs whether a value was named, never whether it was good - a board can be entirely on-token and still ugly, and no amount of enforcement fixes that.
It also will not stop a determined author: leave a slot un-tokenised and the system has nothing to say about it. That is the escape hatch working as designed. A system that cannot be escaped gets abandoned; one that can be escaped in a way you can see gets adopted.
What you get is narrower and more useful than compliance: at any moment you can answer "which boards use this colour, and what happens if we change it" - because the answer is a query rather than an archaeology project.