Most large organisations hold their identity in a document. It is handsome, it was expensive, and it is read in full by the people who made it and by almost nobody else. It specifies a colour to a hexadecimal value that the presentation software rounds, a typeface that the office computers do not have, and a clear-space rule that the signage contractor has never seen. Within a year the brand exists in three versions: the one in the PDF, the one on the website and the one in the last hundred documents sent to customers. The PDF is decoration. It describes an identity; it does not enforce one.
An identity that behaves like infrastructure is different in kind, not in quality. Its decisions are encoded where they are consumed: colour, type, spacing, radius, motion and voice held as named, versioned tokens in one source, exported to every surface that renders the brand, and changed through a release process that a subsidiary can see and a board can govern. The guideline document still exists, but it describes what the system already does. This is the only form of identity that survives the three events that destroy the other kind: a merger, the rebrand of a subsidiary and the arrival of a new chief marketing officer.
What a token is, and why the word matters
A design token is a named decision. colour.ink is a decision about the colour of text; space.4 is a decision about a distance; type.heading.width is a decision about the cut of a typeface; motion.arrive is a decision about how something appears. The token has a name, a value and a version. Every template, component, document and screen that renders the brand refers to the name, never to the value.
This separation is the whole point. When the value changes, everything that refers to the name changes with it. When the name is versioned, a subsidiary can say which version it is on, a changelog can say what moved between versions, and a deprecation can carry a date. The identity stops being a set of pictures and becomes a set of facts with a history.
Voice belongs in the token set too, though it is rarely treated that way. The register, the vocabulary, the words the brand refuses to use and the way it names things are decisions in the same sense as a colour. They can be held in one source, versioned, and enforced in the tools where copy is produced. A banned list that lives in a document is a wish; a banned list that fails a build is a standard.
One source, many surfaces
The design system and the brand are usually procured separately, by different departments, from different suppliers. Marketing commissions the brand. Engineering builds the design system. The two meet in a file transfer, once, and diverge from that day.
The alternative is one source. The tokens are the brand, and the design system is one consumer of them alongside every other surface: the website, the product interface, the printed report, the signage on the building, the contract template in the legal department, the presentation the sales team gives on Tuesday and, increasingly, the voice agent that answers the telephone. Each surface has its own renderer. The web reads the tokens as CSS variables. The office documents read them as themes. The print supplier reads them as a colour specification derived from the same source. The voice agent reads the verbal identity: its register, its vocabulary, the names it uses and the things it will not say.
That last surface is new and it is instructive. A voice agent has no logo. Its entire brand is voice, and voice is the part of most identity systems that was never encoded at all. An organisation that has treated its verbal identity as a chapter in a PDF discovers, when it deploys an agent, that it has no source of truth to hand the engineers. The agent is briefed from a marketing deck and sounds like one.
A banned list that lives in a document is a wish. A banned list that fails a build is a standard.
Why it matters at a merger
A merger is an identity event before it is anything else. Two organisations arrive with two brands, two sets of templates, two websites, two typeface licences and, usually, two PDFs. The integration plan assumes the brand question will be settled by a decision about the name. It is not. The name is one token. The work is the migration of every surface in both organisations to one system, in a sequence that the business can bear.
With infrastructure, that migration is a release. The acquired company is placed on a version, given a path through the architecture rules that decides how far its name may sit from the parent, and moved surface by surface, with the interim states designed rather than improvised. The cheapest and least visible surfaces move first and prove the system. The most visible move once, when the system is proven. Without infrastructure, the migration is a programme of manual redrawing that lasts years and is never finished; the board is still finding old letterheads at the third anniversary.
The subsidiary rebrand is the same problem at smaller scale and higher frequency. A division is renamed, a product line is spun out, a regulator requires a legal entity to change what it calls itself. In a token-based system, each of these is a change proposal, a review, a version and a release. In a PDF-based system, each is a small agency engagement and a quarter of drift.
The change of chief marketing officer is the quietest of the three and the most reliable. A new CMO inherits a brand and, understandably, wants to improve it. Where the identity is a document, improving it means commissioning a new one; the old drift is replaced by new drift, and the organisation learns that its brand changes when its marketing leadership does. Where the identity is infrastructure, the new CMO inherits a versioned system with a changelog, a council and a backlog. Improvements are proposed and released like any other change. The brand outlasts the person, which is what a brand is for.
Governance
Infrastructure is governed or it decays. The governance of an identity has four parts, and each has to be decided before the tokens are drawn.
Who owns the tokens. One named role, inside your organisation, holds the source. Not the agency, not the engineering team that happens to host the repository, not marketing collectively. The owner is accountable for the version, the changelog and the release calendar, and chairs the council that decides changes.
How changes are proposed. Anyone in the group may propose a change: a subsidiary that needs a colour for a new product line, a market that needs a script the system does not yet set, an engineer who has found that a spacing token breaks on a small screen. A proposal names the token, the reason and the surfaces affected. The council reviews it on a fixed cadence and either declines it, accepts it into the next version or accepts it as a regional variation within stated latitude.
How changes are released. A version is cut, a changelog is written, the exported packages are published for every platform, and each consuming surface updates on its own schedule within a stated window. Deprecations carry a date. A subsidiary that has not updated by the date is visible in a register, which makes it a governance conversation and not a mystery.
Accessibility as a constraint. This is the part most identities get wrong, because they treat accessibility as a check applied after the design is finished. In infrastructure it is a constraint on the tokens themselves. Every colour pairing the palette permits is measured for contrast against the Web Content Accessibility Guidelines 2.2 at level AA, and the measurement is recorded in the token. Type sizes, line lengths and focus states are specified in the system. Every motion token has a reduced-motion alternative. A pairing that fails is not permitted to exist, so no surface can use it. The identity meets the standard by construction, and the evidence is the token set.
| Question | Style guide | Infrastructure |
|---|---|---|
| Where does a colour live? | In a PDF, as a value | In a token, as a name with a value and a version |
| What happens when it changes? | Every surface is redrawn by hand | Every surface that references the name updates |
| Which version is a subsidiary on? | Nobody can say | The register says |
| Who approves a change? | Whoever is asked | A council, on a cadence, in writing |
| Is the palette accessible? | It was checked once | Every permitted pairing is measured and recorded |
The failure modes
Three failures account for most identities that were bought as systems and delivered as pictures.
The agency hands over files. The engagement ends with a mark, a guideline document, a folder of design source and a set of templates that were drawn by hand to look like the guideline. Nothing consumes anything. The organisation has been given a very good description of an identity and asked to enforce it by vigilance. Vigilance lasts until the first busy quarter.
Engineering forks the tokens. The design system team receives the brand, encodes it as tokens in its own repository, and from that moment holds a copy rather than a reference. Marketing changes a colour in the source; the product does not follow. Some months later there are two brands with the same name, and the argument about which is correct is conducted between departments that both believe they own it. The cure is one source with one owner, consumed by engineering rather than copied into it.
Marketing buys a template. A regional team needs a presentation and the template library does not have the format. Someone buys one, restyles it approximately, and it spreads. Within a quarter it is the de facto standard for a market. The template was not malicious; the system had a gap and no request path to fill it. The cure is the request path: a proposal, a review, a release, on a cadence fast enough that buying a template is slower than asking.
Each failure has the same root. The identity was delivered as an output and not as a system with an owner, a source and a process. None of them is fixed by a better PDF.
Procuring identity as infrastructure
The brief decides what is delivered. A brief that asks for a new mark, a guideline and a set of templates will receive exactly that, executed well, and will have bought decoration. A brief that asks for infrastructure specifies different deliverables and different acceptance criteria, and a general counsel and a chief information officer should be in the room when it is written.
Ask for the token set as a deliverable, exported to every platform in scope, with the contrast measurement for every permitted pairing recorded in it. Ask for templates and components that consume the tokens rather than resemble them, and test that claim at acceptance by changing a token and watching the surfaces follow. Ask for the governance charter as a document your board adopts, naming the owner, the council, the request path and the release cadence, and for the release tooling to be operating, with your people running it, before the engagement ends. Ask for the verbal identity as a source that tooling can enforce, not as a chapter. Ask for the typeface and asset licences in your name, scoped to the group and its future entities, so that the next acquisition does not break a per-seat count. Ask for the design source in open, editable formats, and for the assignment of every mark, token and template to you, in writing, on payment.
Then ask the firm one question: when you leave, who approves a business card? If the answer is anyone outside your organisation, the deliverable is not infrastructure.
What to do on Monday
- Find every place your primary brand colour is defined across the organisation, and count the values. If the count is greater than one, you have a style guide.
- Ask engineering whether the product's design tokens reference the brand source or copy it, and when the two were last reconciled.
- Ask who, by name, approves a change to the identity today, and how long the last one took from request to appearance on every surface.
- Measure the contrast of your most-used text and background pairing against WCAG 2.2 level AA, and record the result where the colour is defined.
- Rewrite the next identity brief so that the token set, the consuming templates, the governance charter and the licences in your name are the acceptance criteria.