A design system at launch is easy to admire. Tokens are consistent, the components match the documentation, the Figma library and the code agree. It is a photograph of a moment when one person still had their hands on everything.
Year two is the real test, and the failure is never dramatic. A team needs a slightly different card and there is a deadline, so they fork it. Someone hard-codes a hex because the token was not obvious. A variant appears in Figma that was never built. None of these is a scandal. Together they are how a system quietly stops being one.
Governance is the part people skip and the part that decides whether a design system is still true a year later.
Three things that actually hold
First, a named owner. Not a committee and not “the design team”. Systems decay in exactly the way that shared property decays.
Second, a route for exceptions. Teams will need things the system does not have. If the only options are wait or fork, they will fork. A visible path (propose, review, absorb or reject with a reason) converts divergence into a queue you can see.
Third, audits with teeth, on a schedule. Not a survey; a comparison. What is in the library, what is in the code, what is actually on production screens. The gap between those three is the health of the system, and it is the only metric worth reporting upward.
The token is the contract
The deepest version of this is that the token, not the component, is the unit of agreement. Components get replaced. If everything reaches for the same values, a replacement is a local event. If it does not, every replacement is a negotiation.
It is also what makes a system portable. Once colour, spacing and type live as data rather than as decisions embedded in files, you can re-skin an entire product, generate documentation that cannot drift, and prove a contrast ratio by reading the value rather than squinting at a screenshot.
None of this is glamorous, and none of it demos well. It is the difference between a system that shipped and a system that survived.