The Adaptive Brand

Coherence was never designed. For most of the history of software it was enforced, and the enforcement was scarcity. Screens were expensive to make, so few people made them, and those few carried the brand in their heads. A style guide existed, but it worked like etiquette: a written reminder of judgments that were really passed from person to person. When a company wanted more coherence, it hired more reviewers and slowed down. The brand was the bottleneck, and the bottleneck was the brand.

AI removed the bottleneck twice. First at design time: an agent working in a repository can produce a decent screen in minutes. Screens are no longer scarce, so the reviewers who used to see every surface now see a fraction of them. Then at runtime: a model inside the product composes sentences, and soon interfaces, on demand, per person, per moment. No reviewer will ever see most of what a generative product shows its customers, because most of it does not exist until the moment it is shown.

What grows without the bottleneck is not chaos. It is sprawl. AI features grow the way weeds do: a team adds one, and someone writes a prompt. The prompt works, so it gets copied into the next feature and edited a little. Six months later the product speaks with eleven slightly different personalities, none of them chosen. The design-time version of the same weed is the almost-component: every generated screen slightly different from its siblings. Each difference is defensible on its own. The sum is incoherent.

The costs are real. In February 2024 a Canadian tribunal ordered Air Canada to honor a bereavement discount its support chatbot had invented. The airline argued that the chatbot was a separate legal entity responsible for its own statements. The tribunal disagreed: the product spoke, so the company promised. Every generated sentence is a commitment made on the company's behalf. Every generated screen is a brand decision published without review.

What is missing is a governed layer above both generators: one place where the product's identity lives in a form machines can read, loaded into context before anything is generated and checked against contracts after. The rest of this article describes that layer, what goes in it, and what it costs. What the bottleneck used to enforce by accident, the system now has to guarantee on purpose.

When production gets cheap, the unit of design moves. This has happened before. Print designers specified pages. Web designers learned to specify templates, because the page count had become unbounded. It is happening again, and this time the move is bigger. When an agent can produce any screen on request and a model can rephrase any sentence per reader, the screen and the sentence stop being things you design. They are outputs. What you can still design is the behavior underneath: what the product is trying to do in this moment, what it must include, what it must never claim, and what a good outcome looks like.

The designer's job moves with the unit. Producing five plausible directions for a screen now takes minutes. Knowing which one is right, and why, is the craft that remains, and the whole system is organized around it. The division of labor is simple: the machine generates options, and the human chooses, with reasons. A team that lets the machine choose, taking the first plausible output, has not automated design. It has abandoned it.

It is tempting to treat this as a story about chat, since chat is where most teams first met a generative surface. But conversation is just one renderer. The same behavior, explaining a delayed transfer, can show up as a chat reply, a status banner, an email, or thirty seconds of a voice call. A product that designs the reply has solved one surface. A product that designs the behavior has solved all of them, including the ones it has not shipped yet.

Every serious proposal needs a chapter that argues against itself. This is that chapter. For many products, at many stages, building the full system in this article is a mistake, and not because the ideas are wrong. A three-screen prototype does not need behavior contracts. A product whose AI writes nothing riskier than a caption does not need an authority model. One person with good taste and a small surface can hold coherence in their head, which is where it has always lived most cheaply. A product without a coherence problem is buying insurance against a fire that is not burning.

The threshold is not company size. It is exposure, and exposure is two numbers multiplied: the cost of a wrong sentence, and the number of surfaces that can produce one. A solo designer shipping a marketing site is near zero on both. A brand file and a weekly critique are all that situation needs. A four-person team moving money through a chat thread is high on both, whatever its headcount, because a generative surface in a regulated category makes commitments at conversational speed.

So adopt like a ladder, not a leap. The first rung is a brand file the agent reads before generating anything. It costs an afternoon. Then tokens as the single source of visual truth, then extracted components with names, then contracts on the behaviors that can do harm, then evaluations, then traces. Each rung is useful without the ones above it, and each should be justified by a coherence failure the team has actually had, not one it can imagine. The same logic applies to hiring. A team that wants a second designer usually wants the system instead: written taste, enforced tokens, a decision log. If none of that exists, the hire will not fix it. Do not hire; build.

There are also exit conditions, and naming them early is part of being honest. If models become reliable enough that a plain instruction holds across a million generations, some of this scaffolding should come down, and Chapter 13 describes how to tell. A system that cannot say what would make it unnecessary is a belief, not an architecture.

Systems drift when their truth is stored twice. The traditional design stack stored it at least twice by construction: once in the design tool, once in the code, with a human translating between them. The two copies disagreed within a sprint of any release. The first structural decision of an adaptive brand is to collapse them. Tokens, components, screens, copy, and decisions live in one repository, and everything else, the style guide site, the exported specs, the agent's instructions, is generated from it. When the repository changes, the derivatives change. Nothing depends on someone remembering to update it.

Tokens carry the visual half of the truth, and their structure matters more than their format. Three layers, each answering a different question. Primitives name what exists: the palette, the scale, the type family. Semantic tokens name what things mean: surface, accent, warning, the vocabulary screens are actually built from. Component tokens name exceptions, and the fewer there are, the healthier the system. A generator styling a screen touches only the semantic layer. That is how a rebrand becomes an afternoon, and how a thousand generated screens stay siblings.

{
  "color": {
    "surface":  { "$value": "{color.cream.100}" },
    "ink":      { "$value": "{color.brown.900}" },
    "accent":   { "$value": "{color.gold.600}" },
    "warning":  { "$value": "{color.orange.600}",
                  "$description": "Reserved: fee changes, delays, holds." }
  },
  "space": { "flow": { "$value": "{space.4}" } }
}

The less obvious half of the decision is who the design system is for. It used to be documentation for people. Now it is, first, context for machines: the agent scaffolding tomorrow's screen and the model rendering tonight's answer both read it, and its quality is measured by what they do with it. A style guide site still matters, but as a human-readable view of a system whose native form is machine-readable. Both audiences read the same truth, which is the only arrangement where they cannot diverge.

Component libraries standardized the nouns of interface: Button, Card, Modal. Adaptive products need a vocabulary one level up, for the verbs. When a model decides how to respond and an agent decides how to compose a screen, the reusable unit is the behavior: Explain, Clarify, Confirm, Compare, Recommend, Repair, Warn. Each is a designed object, defined without reference to any particular surface. A Confirm names the facts it must present, the consent it must collect, the actions it may offer, and the evaluations that decide whether it worked. How a Confirm looks in a chat thread versus a web form is a rendering question, and rendering comes later.

The vocabulary is discovered, not invented. The reliable moment is the second flow. The first flow produces candidates. The second shows which parts recur, because the agent, asked to build it, will reproduce the first flow's patterns almost correctly, and the almost is the signal. At that point the team audits the inconsistencies, promotes the recurring patterns to named components, and replaces the inline variants with the canonical ones. Name components by what they do, never by how they look: a TransferSummary survives a redesign, a BlueFeeCard does not.

export const ConfirmTransfer: SemanticComponent = {
  intent: "Collect informed consent for a money transfer",
  requiredFacts: ["amount", "rate", "fee", "arrivalWindow"],
  allowedActions: ["confirm", "edit", "cancel"],
  forbiddenClaims: ["guaranteed arrival time"],
  repair: "RepairTransferDetails",
  evals: ["consent-is-explicit", "fee-stated-before-confirm"],
};

Once behaviors have names, everything downstream gets simpler. Prompts stop describing what a response should be like and start naming what it is. Evaluations attach to behaviors instead of prose. And the two generators finally share a vocabulary: the agent composes screens out of the same Confirm the runtime model speaks in a chat thread. That is the first concrete payoff of governing one system instead of two.

Ask a team what their brand voice is and someone will say warm but professional, and everyone will nod, and no two people will mean the same thing. That was survivable when every sentence passed through a writer. It is fatal when sentences are generated, because a model given warm but professional will decide for itself what warmth means at three in the morning to a customer whose transfer is stuck. The brand has to move from adjectives to constraints: written down, versioned, and loaded into every generator's context before it produces a word.

The written form has two halves. The first is the brand file: identity, voice, tone by context, terminology, and the never-say list, which does more work than everything above it. Its entries are not style preferences. Each is a commitment: a sentence the product will not produce, in any language, on any surface, no matter how fluent it would sound. The second half is the contract, which is what the brand file compiles into. A conversation contract bounds what a behavior may say: allowed facts, required disclosures, forbidden claims, output shape. The brand file teaches the generator. The contract checks its work.

## Voice
Plain, warm, direct. Money talk is calm talk.
Short sentences around numbers. No exclamation
points within two sentences of an amount.

## Tone by context
- Delay or hold: lead with what is true now,
  then the next step. Never open with an apology.
- Success: quiet confidence. One sentence.

## Never say
- "Oops" or "Uh oh" anywhere in a payment flow
- Any arrival promise not present in the
  rate object ("guaranteed", "instantly")
- "Trust us"

export const DelayExplanation: ConversationContract = {
  behavior: "Explain",
  allowedFacts: ["status", "holdReason", "nextStep", "eta"],
  requiredDisclosures: ["etaIsEstimate"],
  forbiddenClaims: ["blame-customer", "guaranteed-eta"],
  onValidationFailure: "degrade-to-template",
};

What makes this maintainable is that the same files serve both machines. The agent reads the brand file before drafting copy at design time. The context compiler loads it, with the contract, before the runtime model explains a delay. One edit to the never-say list reaches every future screen and every future sentence. That is what it means for a brand to be on by construction rather than by review.

Cross-platform used to mean responsive: the same layout, gracefully squeezed. An adaptive product faces a harder version, because its surfaces do not share a layout to squeeze. A behavior renders as a chat message, a form, an email, a voice turn, or an interface composed on the spot. What holds these together cannot be visual sameness. It is the promise underneath: the same facts, the same disclosures, the same actions, wearing whatever clothes the channel requires.

The instrument is the renderer contract, and the useful analogy is accessibility testing. Nobody tests a screen by asking whether the disclosure exists somewhere in the markup. They test whether a person using a screen reader actually encounters it. Renderer contracts make the same demand of every surface: the fee is stated before the confirm control can be reached, the warning is as prominent as the risk is serious, the cancel action is never more than one step away. Placement and reachability, not mere presence. A rendering that cannot meet the contract on some channel does not ship on that channel, and every behavior carries a deterministic fallback layout for the day the generative path fails. The fallback will be plain. It will also be correct, and correct-but-plain is the right floor for a product that moves money.

Language is the other axis, and it is behavioral before it is lexical. Translating strings is the last step of localization, not the substance. A conversation profile localizes behavior: pacing, directness, formality, which examples land, how consent is asked. The words change with the locale file. The disclosure changes with nothing. Copy itself is tokenized like color, stored as semantic keys with per-locale values, so the agent generating a screen and the model generating a sentence draw from the same vocabulary in every market.

A fair question is where all these artifacts meet. The answer is a control plane: the governed layer that decides, for each piece of work, what context is admitted, which capabilities are available, which policies apply, and what evidence is kept. The striking thing is that a well-run adaptive product builds it twice, in the same shape, at two different moments. The two versions differ in stakes and in dress, but every component in one has a counterpart in the other, because both solve the same problem: a fluent generator that must be briefed before it works and bound while it works.

The design-time plane is the humbler one, and it is where most teams start. It is the repository itself, made legible: an instruction file stating what the project is and what may never happen, skill files carrying the brand and the patterns, and hooks that check the invariants on every change. The split between instructions and hooks is the important part. An instruction can be forgotten. A hook fires every time. Preferences belong in the instructions. Invariants belong in the machinery.

The runtime plane is the same idea with higher stakes. Before a model speaks, the compiler assembles what it may know, the authority graph limits what it may do, contracts bound what it may say, and a trace records what happened, so any turn can be replayed when someone asks why. Neither plane is the agent, and neither is the model. The generators are tenants. The plane is the building. And the deepest economy of the whole approach is that the two buildings share load-bearing walls: the same tokens, the same brand file, the same behaviors, the same evaluations. Maintain them as one system and you pay for coherence once, then collect it at both moments.

Before the practice comes apart into disciplines, watch one week of it run. The Corredor team is adding scheduled transfers: a sender sets up a recurring payment to arrive before her mother's rent is due. One designer owns the flow. The system owns the coherence.

Taste that stays in a designer's head does not scale to generators, because generators cannot read heads. The fix is older than it looks: the design critique, made continuous and partly mechanical. Every substantial piece of work gets options before commitment, a structured critique against written criteria, and a scheduled second look after it ships. What changes is who participates. The agent can run the critique too, against the brand file and the pattern library, and a different model makes a usefully disagreeable second reviewer precisely because it shares none of the first one's habits.

Under the critiques sits the harder discipline: writing the taste down as evaluations. An eval is a rubric made executable, attached to a behavior rather than a prompt. Does the explanation state the fee before the consent control appears? Does the recovery message avoid opening with an apology? Is the warning as prominent as the money at risk? Each is checkable across a hundred generated variants, which is the only scale at which checking now matters. Product metrics complete the loop but cannot start it: metrics decide winners, evals decide entrants. A variant that converts beautifully while breaking a disclosure rule is not a winner. It is an incident with good numbers.

That distinction deserves a name, because it organizes all brand measurement: floors and dials. The on-brand score is a dial, and it should climb as the voice artifacts and their evals improve. The brand commitments are floors: the claim that is never made, the register that never appears, the disclosure that always does. Dials chased without floors corrupt quietly. The fastest way to raise a conversion dial is to warn less and hedge less. Write the taste down as dials. Write the commitments down as floors. Never let the first argue with the second.

## ConfirmTransfer / consent-is-explicit
Fail if consent is collected by any control
whose label does not name the action and the
amount ("Confirm $200 to Rosa") .

## Explain / no-blame-opening
Fail if the first sentence attributes the
delay to the customer, in any phrasing.

The uncomfortable implication is that the rubric is now a first-class design deliverable. A designer who can say why a direction is right, in criteria precise enough to run, has written down the scarcest thing they have. The criteria are the craft. Everything else in the system exists so that the craft, once written, gets applied everywhere.

Technology scales through abstraction. Teams scale through memory. Every design decision of consequence gets made once, forgotten, and made again by someone else, slightly differently, and the drift between the two answers is where incoherence enters a growing product. The countermeasure is unglamorous: a decision log, kept in the repository, written at the moment of choice. What was decided, what was rejected, and why, in two or three sentences. The log is not documentation of the design. It is the design's reasons, the part the artifacts cannot carry.

### 2026-06-19 — Fees shown as totals, not itemized
Chose a single all-in fee line on every summary.
Rejected itemization: it tested as more honest but
read as more expensive, and support tickets rose.
Sign-off: brand + compliance. Revisit if corridors
with tax line-items launch.

The log earns its keep twice. People check it when a settled question comes back, which happens about every six months in any team with turnover. The agent checks it before every generation, which is how a new flow inherits last quarter's reasoning without anyone re-explaining it. In practice the log becomes the onboarding: a new designer who reads the decisions, the brand file, and the behavior vocabulary has absorbed the team's taste in an afternoon, because for once it is written where the work happens.

Governance follows the same principle at team scale. Ownership attaches to artifacts, not tools: someone owns the tokens, someone owns the behavior vocabulary, someone owns the contracts that carry legal weight, and the review gates say which changes need whose eyes. The rest stays loose on purpose. Standardize the artifacts, not the tools, and let each designer keep whatever harness makes them fast. Everything of value lives in the files they all share.

Every example so far resolved cleanly, and that should make a skeptical reader suspicious. So this chapter breaks the system, with a failure built entirely from defensible decisions. A designer, moving fast on a Friday, lets the agent converge on a redesigned summary screen without the options pass. The screen is lovely. The agent, drawing on an older pattern, places the all-in fee below the confirm control instead of above it. The fee-before-consent eval would have caught it, but the eval is bound to ConfirmTransfer, and the new screen quietly introduced a ConfirmScheduled variant nobody registered. The pull request is small, the reviewer checks performance, and the screen ships. For eleven days, on one surface, in one locale, Corredor collects consent before stating its price.

The interesting part is not the failure. Every system fails, and generative ones fail faster. The interesting part is the shape of the failure, because the architecture spent all its effort making that shape small and legible. The breach was one behavior variant on one surface, not a personality drift across the product, because everything else was contract-bound. It was found in an audit sweep, not a courtroom, because the weekly screen-level pass walks surfaces the unit evals cannot see. And the trace answered why in minutes: the variant, the missing registration, the skipped options pass, each visible, each fixable at exactly one point. The postmortem produced a rule, the rule became a hook, and the hook now fails any pull request that adds a behavior without an eval binding. An instruction would have asked the team to remember. The hook removed the option of forgetting.

This is the honest promise of the whole system. Not that generation becomes safe, but that failure becomes local: one contract, one variant, one surface, one fix, instead of a diffuse off-brand-ness nobody can locate. A team that cannot say where a failure would show up does not have an architecture yet. It has confidence.

The strongest objection deserves its strongest form. Models improve every few months, and much of what this article proposes is compensation for their current weaknesses. Contracts exist because instructions do not reliably hold. Evals exist because judgment does not reliably transfer. Fallback layouts exist because generation sometimes fails. Each artifact is scaffolding around a limitation, and scaffolding around a shrinking limitation is a depreciating asset. A team that spends this year building the full apparatus may spend next year maintaining machinery the models have made unnecessary, while a rival that waited simply writes better instructions to a better model.

Part of that is right, and the answer is to plan the retirement rather than deny it. Every layer should carry a sunset condition: the observable fact that would make it removable. When a plain instruction holds across a million generations, retire the contract that duplicates it. When the model's judgment matches the rubric nine hundred ninety-nine times in a thousand, thin the eval to a sample. Review the scaffolding on the same cadence the models improve, and feel no sentimentality when a layer comes down. Architecture must earn its keep annually.

But the objection proves less than it seems to, because it confuses two kinds of artifact. The scaffolding compensates for the generators, and it will depreciate as they improve. The commitments compensate for nothing. What the product promises, what it must disclose, what it may never claim, whose consent it needs, why the fee is shown as a total: no model improvement makes these decisions for a company, because they are not capability gaps. They are choices. Better models make expressing them cheaper and enforcing them lighter, and leave the deciding exactly where it was. The same logic settles the tooling anxiety. Harnesses, models, and vendors churn fastest, which is exactly why nothing of value should live in them. The test is simple: if the favorite tool disappeared tomorrow, the team should lose a driver, not the brand, the decisions, or the taste. Everything in this article passes that test by construction, because everything in it is a file in the team's own repository.

This article opened with a bottleneck and has spent thirteen chapters replacing it. The design system analogy carried most of the distance, and here is where it ends. Visual design systems asked for consistency: the same button, the same blue, the same spacing, everywhere. An adaptive brand asks for something harder, because its surfaces are not supposed to be the same. They are generated per person, per channel, per moment, in whatever language the customer thinks in. Buttons needed consistency. Generative products need coherence, and coherence is what holds while everything else adapts.

What holds is short enough to list. The commitments, written as contracts. The taste, written as evaluations. The meaning, written as behaviors. The truth, written once, in a repository both generators read. Around that fixed core, everything is allowed to move: the words, the layouts, the pacing, the channel, the model, the harness, even the team. The discipline is refusing to let the two categories blur, because every incoherent product fails the same way: something that should have been governed became something that merely tended to be true.

The next generation of products will not be distinguished by fluency. Everyone's model will be fluent, everyone's screens will be competent, and both will be cheap. Products will be distinguished by whether they can adapt everything and still be recognizably, accountably themselves: one promise, kept on every surface, in every language, by generators that never met the founders. That quality is not taste applied at review time. It is built, the way this article has described. That is the discipline the name has been pointing at all along.

Every law from the preceding chapters, regrouped by what it governs. They are meant to travel without the chapters attached.

The system is, in the end, a small set of files. These are Corredor's, trimmed to their load-bearing lines. Names and tools will date; the shapes should not.

# Corredor
WhatsApp-native remittances, four-person team,
design happens in this repo.

## Absolute rules
1. Never hardcode a color or spacing value.
   Semantic tokens only.
2. Every behavior ships with all states:
   happy, empty, error, loading, 375px.
3. Every new behavior registers an eval
   binding before merge.
4. Money copy follows skills/brand.md.
   The never-say list is not advisory.

## Read before generating
skills/brand.md · skills/decisions.md ·
behaviors/ · tokens/semantic.json

export const MxFirstTime: ConversationProfile = {
  locale: "es-MX",
  pacing: "one-idea-per-message",
  directness: "high",
  formality: "usted",
  consent: "explicit-question",
  examples: "cash-pickup-first",
};

export const ConfirmRenderer: RendererContract = {
  behavior: "ConfirmTransfer",
  guarantees: [
    "fee-visible-before-consent-reachable",
    "cancel-within-one-step",
    "warning-salience-scales-with-amount",
  ],
  fallback: "templates/confirm-plain",
};

Review every screen changed this week against
skills/brand.md and the pattern library.

For each issue: severity, the rule it breaks,
and the smallest fix. Check the decision log
before proposing anything it already settled.
Generate nothing. This is a critique.