Two applications in the same company ship what should be the same primary button, and after a rebrand the shades differ by one step. A third application's button is the old colour entirely. What is the underlying cause, and which change prevents recurrence?

The mechanism

The colour was copied rather than referenced. Each application holds its own literal value, so a rebrand is not one change but N changes, applied by N teams on N schedules, with at least one missed. This is the same drift that duplicated configuration always produces, and the mechanism is identical: a value with more than one home has more than one truth.

A design token is the value given a name and one owner: colour.action.primary resolves to a hex value in exactly one place, and the applications reference the name. A rebrand becomes a version bump of the token package. The colour stops being data that teams hold and becomes an interface they consume, which is why the fix is structural rather than procedural.

Two details decide whether it works. Tokens must be versioned like any dependency, so a team can see which version they are on and an upgrade is a normal pull request rather than an announcement. And the rule against raw values must be enforced in the build, because a convention that is not checked decays in a quarter: the pipeline fails on a hex literal outside the token definitions, with an error naming the token to use.

Why the other options fail

• Document the values in the wiki. This is what the third application did, and it is why it still has the old colour. A document cannot propagate a change, and nobody re-reads it during a feature.
• A lint rule that warns. The right mechanism at the wrong severity. Warnings accumulate and stop being read; a build failure is the only lint outcome that changes behaviour. Pair it with tokens, or the rule bans the literal without offering the replacement.
• Design reviewing screenshots. It catches the drift after it ships, on the screens someone thought to capture, and it costs a person's time every release. It is a detector with a slow loop, not a fix — and the one-step difference in the question is exactly what a human comparison misses.

What it costs

Tokens add a dependency and a release process, so a colour change now requires publishing a package and 11 applications upgrading, which is slower than editing a stylesheet. Budget 1 to 2 days per application for the first adoption and minutes per upgrade after that. That slowness is the trade: you give up the ability to change one application quickly, and get the ability to change all of them consistently.

The decision rule is the number of consumers. Choose tokens at the second application that must match the first, and choose a stylesheet below that. Design systems have been publishing tokens as versioned packages since around 2016 for this reason, and the published post-mortems of failed design systems almost always describe the same cause: the values were documented rather than consumed, so drift was never prevented, only detected.

When this is over-engineering

One application, one team: put the values in a stylesheet and stop. Tokens earn their cost at the second consumer, and a token pipeline built for a single product is infrastructure maintained for nobody. The other case where the simpler answer wins is a deliberately distinct brand: a sub-brand that is meant to look different does not need to be forced through the shared palette, and pretending otherwise produces a token set with exceptions for every application, which is a stylesheet with extra steps.