Short answer. A brand book is written for people who can interpret it; a generative pipeline cannot interpret, so the brand has to be expressed as artefacts it can be conditioned on and scored against — an approved fact pack, a termbase with do-not-translate entries, positive and negative examples, a claims matrix per market, and a reviewer rubric. A model asked to recall a brand from general knowledge will produce a plausible average of similar companies. The artefact work is one-time per brand and per language, and it is the difference between a pipeline that scales and one that re-argues its brand on every asset.
Key takeaways
- A generative pipeline cannot interpret prose brand guidelines the way a person can; it needs structured artefacts to condition on and be scored against.
- The five core artefacts are an approved fact pack, a termbase, an example set with negative examples, a claims matrix, and a reviewer rubric.
- A termbase is a control surface with do-not-translate flags, forbidden alternatives, product scope, and phonetics, not a simple glossary of translations.
- Localisation means deciding explicitly which elements stay fixed (names, figures, disclosures where required) and which adapt (register, examples, formats) per market.
- Automating mechanical checks — forbidden terms, unsourced figures, disallowed claims — frees human reviewers to spend their time on register, cultural fit and quality.
Why doesn't a brand book survive contact with a generative pipeline?
A brand book relies on a human reader applying judgement to prose descriptions of logos, colour, typography, tone and messaging; a generative model has no context beyond what is in the prompt and will confidently assemble a plausible version of the brand from everything it has seen about similar companies. A fact pack is a curated list of the exact figures, dates and claims a brand is permitted to state, each traceable to a source.
The failure modes repeat in the same shapes every time:
- Terminology drift. A product feature is called four different things across a campaign, none of them the approved name.
- Invented specifics. A number, certification, or customer count that nobody supplied and nobody can source.
- Regressed claims. A superlative that legal removed years ago reappears, because it is the kind of sentence companies write.
- Tone flattening. Fluent, generic marketing register that could belong to any competitor.
- Market-inappropriate framing. A claim that is fine in the source market and a regulatory problem in another.
None of these are model-quality problems. They are supply problems: the model was not given the thing it needed, so it produced the average of what it had seen.
What artefacts does a generative pipeline actually need?
A pipeline needs five specific artefacts, not a style guide: an approved fact pack, a termbase, an example set, a claims matrix, and a reviewer rubric, each aimed at a different failure mode.
| Artefact | What it contains | What it prevents |
|---|---|---|
| Approved fact pack | Every figure, date, capability and claim the brand may state, each with a source | Invented specifics; stale numbers |
| Termbase | Approved terms per language, with do-not-translate entries and forbidden synonyms | Terminology drift; mistranslated product names |
| Example set | Strong approved output plus negative examples with a note on why each fails | Tone flattening; the model averaging toward generic |
| Claims matrix | Which claims are permitted in which market, and which require qualification | Regulatory exposure created by a translator's reasonable choice |
| Reviewer rubric | Scored checks tied to the four artefacts above, with a defined pass threshold | Review that is an opinion rather than a measurement |
The fact pack is the highest-return item and the one most often missing: a model given the eight numbers a company is allowed to state will use those eight numbers, while a model given nothing will produce numbers anyway, because marketing copy contains numbers. Negative examples matter more than they look — "do not sound generic" is uninterpretable, but three rejected examples with one sentence each on the defect is a specification, and reviewers can score new output against it the same way they score AI-generated images for brand consistency.
How do you design a termbase that survives fifty markets?
A termbase is a structured control surface for approved terminology, not a glossary of word-for-word translations, and it needs several fields beyond a source term and its equivalent:
- Approved term, per language, with the source-language head term.
- Do-not-translate flag for product names, feature names and legally controlled phrases.
- Forbidden alternatives — the plausible synonyms that must not be used, which is what an automated pre-check screens for.
- Context or product scope, because some terms translate differently depending on which product they appear in.
- Pronunciation, phonetically, per language, for anything that will be spoken — brand-name pronunciation is a brand decision rather than a linguistic one, and has to be decided explicitly per market.
- Owner and last-reviewed date, because a termbase nobody owns becomes wrong quietly.
Tracking exceptions rather than suppressing them matters: a term that a market's reviewers keep overriding is a term whose approved translation is wrong, and the exception log is the only place that surfaces it — the same discipline that underpins multilingual AI video localisation.
Is localisation a step, or a set of decisions?
Localisation is a set of explicit decisions made before generation about which elements of an asset are fixed across markets and which may adapt, not a single translation step applied afterward. A claims matrix records which claims are permitted, restricted or forbidden in each market.
| Element | Typically fixed | Typically adapts |
|---|---|---|
| Product and feature names | Yes | No — unless a market-specific name exists |
| Factual claims and figures | Yes | No |
| Regulatory disclosures | No | Yes, per jurisdiction |
| Examples and scenarios | No | Yes, where a local reference is clearer |
| Formality and register | No | Yes — this is where translated copy most often reads wrong |
| Humour, wordplay, taglines | No | Yes, by transcreation from intent rather than words |
| Units, dates, currency, formats | No | Yes, as data-driven fields rather than typed strings |
Register causes the most rework: a translation can be accurate at word level and wrong at the level of how a company should address a buyer in that market, and that judgement needs someone living in the market rather than a fluent speaker abroad who catches grammar but misses register. This is why multilingual AI voice production builds in-market review into dubbing and localisation rather than relying on translation alone.
What should a reviewer actually check?
A reviewer should score each asset against the fact pack, termbase, claims matrix and register expectations for its market, rather than against personal preference. That turns a vague complaint like "the German is off" into a list of arguable, specific defects:
- Factual accuracy against the fact pack — every figure traceable, no additions.
- Terminology against the termbase, including do-not-translate compliance.
- Claims against the market's row in the claims matrix.
- Register and naturalness — would a company in this market address a buyer this way.
- Cultural fit — examples, references, imagery, gestures, anything that reads as imported.
- Technical quality — formatting, units, dates, names, numbers, and for spoken content, pronunciation and pacing.
Setting the pass threshold before work starts — defects per thousand words at each severity, made contractual — avoids turning it into a negotiation after the first delivery. Sampling should be random across the whole delivery rather than only the first section of each file, and a failed sample should escalate to full review of that batch rather than accepting one corrected sample as evidence for the rest, consistent with the layered checks described in human-in-the-loop review of AI content.
What should be automated, and what stays human judgement?
The checks that scale are mechanical ones run before a human sees the asset — forbidden terms present, an approved term absent, a figure missing from the fact pack, a claim not permitted in a market's row, a missing required disclosure, or an unapproved logo file. Everything left after those checks is judgement about register, cultural fit and whether the copy is any good, and that is where a reviewer's time should go. Teams that skip the automated boundary end up paying expensive in-market reviewers to catch banned words, then wonder why review is the bottleneck.
How does Lifewood approach brand governance for AIGC?
Lifewood builds the fact pack, termbase and claims matrix as the first phase of a multilingual AIGC programme, rather than as documentation produced alongside it, because those artefacts are what make later production volume reviewable at all. Review runs in-market across 100+ languages and 40+ delivery centres across 30+ countries, drawing on 56,000+ registered contributors, using a dual-layer human-in-the-loop process held to a 95%+ accuracy SLA, with the rubric scored against the client's own artefacts rather than a house style — the same production discipline covered in how professional AIGC video production works and in Lifewood's AIGC services.
The honest limit is that this is set-up cost with no output attached to it, and it is the phase clients most often want to compress. Compressing it does not remove the work; it moves it into per-asset argument, where it costs more and produces an inconsistent result — one reason enterprises increasingly manage prompts as enterprise assets rather than re-briefing from scratch each time.