Blog · Running the work

Governance, and one source of truth for brand facts

Published 29 September 2026 · Updated 8 October 2026 · 7 min read

Governance, and one source of truth for brand facts
Photograph: kimak kimbek / unsplash

The short answer: Governance for brand facts means one internal register that holds every claim about your company an engine might repeat, each with a named owner, a last-reviewed date, and a list of every place that fact is published. One canonical page carries the stable version. Everything else is downstream of it. Without that register, the facts drift apart quietly, and an answer engine picks whichever version it happened to retrieve.

The failure is not that engines lie about you. It is that they are correct about an old version of you, or correct about one of three versions you are currently publishing.

Why the drift happens at all

A brand fact lives in more places than anyone remembers. The homepage, the about page, the pricing page, the careers listing, the footer of every PDF, a directory profile nobody has logged into since the Series A, a conference bio, a partner's integration page, a help centre article, the structured data in the template.

Each one was written by a different person at a different time. None of them was wrong when it shipped. Then the headcount changed, or a plan was renamed, and exactly two of the eleven places got updated, because those were the two somebody could remember.

A retrieval system does not know which of those pages is newest or most authoritative. It fetches candidates, keeps passages, and writes. If three of your own sources disagree, the model resolves the conflict by hedging, by picking the most repeated claim, or by preferring a third party that sounds more settled than you do. Hedging reads as absence. The most repeated claim is often the oldest, because it has had the most time to be copied.

What a fact register actually looks like

It is a table, not a platform. Six columns do the job.

The claim. Written as one sentence an engine could quote verbatim. Not "pricing starts at a competitive rate". Write the number.

Stable or volatile. Stable facts change every few years: legal name, founding year, headquarters city, category. Volatile facts change every quarter: price, headcount, supported integrations, customer count. Separating them lets you re-review the volatile block monthly without reopening the whole file, and it tells a reader which parts of the page to trust after six months.

Owner. A role, not a person who may leave. Finance owns the price. Legal owns the entity name. The person who owns the fact is the only one who may change it.

Last reviewed. A date, not a status. "Current" is not a date.

Published where. Every URL and surface the claim appears on, including the ones you do not control: your structured data, your directory profiles, your knowledge panel inputs. This column is the whole point. It turns an update from a vague intention into a checklist.

Evidence. The filing, the invoice, the board deck, the dashboard screenshot. A fact with no evidence behind it is a preference, and preferences drift.

Twenty to forty rows covers most companies. If yours runs past a hundred, you are recording opinions, not facts.

The canonical page, and the markup that mirrors it

One page should carry the stable set in plain readable HTML: who you are, what category you sit in, when you started, where you are, what you sell. Google's own guidance on organisation structured data recommends putting that markup on the homepage or on a single page that describes the organisation, rather than repeating it site-wide, and it asks that the name you use there matches the name you use everywhere else, which is the same governance point stated as a markup rule.

Two things make that page work rather than decorate it.

The markup must mirror the visible text exactly. If the page says 2019 and the JSON-LD says 2018, you have not published one fact, you have published a contradiction in a machine readable format. We see this most often when the schema block lives in a template that was written once and never touched again.

The identity properties must be filled in. Organization in schema.org carries a set of them that most sites ignore: legalName, foundingDate, numberOfEmployees, identifier, sameAs, and the formal registry codes leiCode, duns, naics and iso6523Code. All of those exist in the current vocabulary, version 30.1, released on 16 September 2026. A registry code is the strongest disambiguation signal a company can publish about itself, because it is externally verifiable and it is unique in a way a name is not. If two companies share your name, the code is the thing that separates you.

Worth saying plainly: Google has stated there is no special structured data required to appear in AI Overviews or AI Mode. Markup is not a ticket. It is a way of saying the same thing twice without ambiguity, which matters because of what happens next.

Where the fact goes after it leaves your site

Your register has an outbound half. Facts you publish get copied into places you do not control, and those copies become the sources engines reach for when your own site is thin or slow.

The open knowledge graph is the clearest case. Wikidata held about 118.8 million content items in the archived capture nearest 31 August 2025, taken on 6 September 2025, and it is a structured, openly licensed, heavily reused layer that sits underneath a great deal of downstream description. A claim that reaches it propagates. A wrong claim that reaches it propagates equally well, and it takes longer to remove than it took to add. Knowledge graphs, Wikidata and brand facts covers the mechanics of that, and Wikipedia, and the brand facts engines inherit covers the encyclopaedic layer above it, which has its own sourcing rules you do not get to override.

The governance implication is small and strict. When a fact changes, the owner updates the canonical page, the markup, and every row in the published-where column, in one sitting. Partial propagation is worse than no propagation, because it creates a disagreement where there used to be a consistent error.

The drift check you can run this week

Pick your eight most load-bearing facts. For each one, search your own domain for the claim and read every result. Then ask four engines the plain question, once with retrieval on and once off, and write down what each returns and what it cites.

You are looking for three things. Places where your own pages disagree with each other. Places where a third party is cited instead of you for a fact you publish. And facts that come back with retrieval off, from the model's own memory, in a version you retired. That last category is the slowest to fix and the most useful to know about.

Half an hour of this usually surfaces something. The self-check has the rest of the first pass, and The first 90 days of AEO work puts the register in the sequence where it belongs, which is early, before anyone writes new pages on top of facts nobody has agreed on.

Ownership is the part that decides whether this survives contact with a quarter. In-house or agency for AEO is worth reading on that question, because an outside team can build the register and run the drift check, and an outside team cannot be the owner of your pricing. Somebody inside has to hold the column.

Honest limits

We cannot tell you how long a corrected fact takes to displace an old one in a given engine. It depends on crawl cadence, on how many third parties repeated the old version, and on whether the claim sits in training data as well as in an index. Corrections to your own pages have shown up within a crawl cycle in our work. Corrections to what a model recalls without retrieval have taken model releases.

We also cannot show that a tidy register raises citation share on its own. What it does is remove a class of wrong answers you would otherwise argue with for months, and make later measurement interpretable, because you know what the right answer was supposed to be.

FAQ

Who should own the fact register? One role inside the company, usually whoever owns the website rather than whoever owns the brand. Individual rows get delegated to the function that generates the fact. Finance owns price, legal owns entity details, people operations owns headcount.

How often should it be reviewed? Volatile rows monthly, stable rows twice a year, and every row immediately on a funding round, rename, acquisition, pricing change or office move. Those five events cause most of the drift we find.

Is a dedicated facts page enough on its own? No. It is the canonical copy, and it only helps if the rest of your site agrees with it and the markup mirrors it. One tidy page sitting above eleven stale ones changes very little.

What if a third party publishes a fact about us that is wrong? Fix your own canonical source first, so there is something correct and current to point at, then raise it with the third party through whatever correction process they offer. Chasing the copy before fixing the original tends to produce a second round of the same argument.

Sources

Related reading

The first 90 days of AEO workIn-house or agency for AEOKnowledge graphs, Wikidata and brand factsWikipedia, and the brand facts engines inheritWhen the model makes something up about youQA for changes meant to move AI visibility