Building a Verified Brand Fact Registry

The fact registry is the internal truth that external measurement is checked against. Without it, “the AI is wrong about us” is a feeling; with it, wrongness becomes a diff between a quoted claim and an approved record.

What a fact looks like

Facts are atomic: one claim, one scope, one evidence trail.

fact: EU data residency (Frankfurt) available
scope: Business and Enterprise plans
since: 2026-03
evidence: Trust Center data residency page · published 2026-03
owner: Head of Security
status: Approved
expires: review 2027-03
visibility: public

Bundled claims (“we’re secure and compliant”) are useless for verification. Scope, dates, and boundaries are what make a fact synthesis-resistant — an assistant paraphrasing “EU residency, Business plans, since 2026-03” has far less room to be wrong than one paraphrasing a marketing paragraph.

The fact state machine

Candidate → Pending approval → Approved → Published
                     ├→ Expired
                     └→ Rejected

• Candidate: extracted by tooling or staff; not yet reviewed by the fact owner;
• Approved: the named owner confirmed it, with evidence attached;
• Published: this version appears in a logged public location;
• Expired / Rejected: no longer usable for conclusions or content.

Only approved facts feed findings and remediation drafts. This single rule prevents the most common failure of brand knowledge bases: confidently publishing what nobody actually confirmed.

The finding/action state machine (separate, on purpose)

Findings and remediation tasks run on their own lifecycle:

Candidate finding → Pending human review → Awaiting client confirmation
→ Confirmed → Ready to publish → Published → Awaiting retest → Closed

Facts describe what is true; findings describe what to do about a discrepancy. Merging them into one status field is how registries drift into fiction. Model, human reviewer, and client are decision-makers recorded on each transition — not a third state machine.

Boundaries are facts too

The most valuable registry entries are often negative: what the product deliberately does not do, which plans exclude a feature, which regions are unsupported. Stated boundaries prevent the expensive failure of being wrongly included — recommended for something you cannot deliver.

Why this becomes an operating asset

The same registry serves your website, sales answers, support macros, documentation — and, increasingly, your own agents, which need approved context as much as external assistants do. Content built from the registry is consistent by construction, and every external claim your company makes gains a traceable origin.

In a 14-day baseline, we build a starter registry of 10–20 facts — just the ones that round of questions requires. The public demo case shows how approved public statements support a customer-facing comparison without exposing internal records.