How to build a product-truth and claims-evidence system

A messaging deck starts ageing as soon as a product, price or customer result changes. The old claim often survives in a sales deck or workflow long after somebody corrected the homepage.

A product-truth system gives those claims a maintained home. Websites, launches, seller guidance and AI workflows can draw from the same approved facts, while reviewers can still see the source, owner, limitations and approval history.

What the system has to answer

A team should be able to answer five questions without searching several decks:

1. Who is this product or offer for?
2. Which problem and outcome does the company lead with?
3. What exactly does the product do today?
4. Which evidence supports each important claim, and where are its limits?
5. Who can approve a change to the answer?

This becomes worth building when product facts change often, several teams publish market-facing work or AI workflows need a controlled source.

What belongs in the system

Copying an old messaging deck into a database will preserve its blind spots. Start with linked records that can change independently.

Audience

Include the audience name, situation, buying role, priority problems, desired outcomes, relevant alternatives, disqualifying conditions and the owner of the decision. Keep direct customer language linked to its source rather than turning every interview phrase into an approved message.

Product

Include the product or capability name, plain-language definition, availability, supported use cases, prerequisites, limitations, region or plan differences, source owner and last verification date.

Claim

Each consequential claim needs:

• the exact approved wording;
• the audience and surfaces where it may be used;
• claim type: factual, comparative, outcome, directional or opinion;
• evidence links;
• qualifications and exclusions;
• approval status and approver;
• valid-from, review and expiry dates; and
• superseded wording where relevant.

Evidence

Store the source, owner, collection method, date, applicable audience or configuration, permission or usage rights, relevant passage or data, limitations and the claim it supports. A link alone is fragile; the system needs enough context for a reviewer to understand what the source actually proves.

Message

Messages combine approved audience, product and claim records for a defined buying situation. They should reference those source records rather than duplicate their content invisibly. That makes it possible to find every page, deck or workflow affected when a claim changes.

Follow one claim when the product changes

Take an illustrative B2B reporting product. Its homepage and sales deck both say, “Cuts monthly reporting time by 40%.” The wording came from a customer study on the enterprise configuration. The study has an owner, a collection date, permission for use and a note explaining which teams were included.

That one sentence is enough to test whether the system works.

First, find every version already in circulation

Start with the website, launch material, core sales deck, product documentation and customer communication for this one product. AI can pull out candidate claims and group near-duplicates. A person still has to decide whether “40% faster reporting” and “save almost half the reporting time” are the same claim, and whether either wording is approved.

The chosen claim enters the register as an outcome claim for a named audience. Its evidence record contains the relevant data and passage, collection method, date, owner, usage rights and limits. If the study supports only the enterprise configuration, that boundary belongs beside the wording. Missing or weak support stays visible as unsupported, partially supported, expired or awaiting approval.

This is also where the commercial choices enter. The priority audience, problem, outcome, alternatives and differentiated value cannot be inferred by averaging old documents. The company has to choose them.

Approval connects the sentence to every place that uses it

Once an authorised reviewer accepts the evidence and wording, the claim record points to each website page, launch asset, seller guide, customer communication and workflow that repeats it. Messages for different buying situations reference the approved record instead of keeping hidden copies.

An AI workflow can now retrieve the current claim for the intended audience or draft a bounded adaptation. It must carry the source and approval state with the output. If an adaptation drops the enterprise qualification or changes the meaning, reject it, save the example and add it to the evaluation set. A model cannot approve its own interpretation of the customer result.

Then the product changes

Suppose a release replaces the reporting process measured in the original study. Save the new product fact without erasing the prior version. The links from the claim reveal every dependent message and published surface. AI can prepare an impact summary with those links, but the product and evidence owners decide whether to qualify, replace or retire the 40% claim.

The proposed edits then go to the editor, subject expert or legal reviewer responsible for release. Publication is recorded against the decision history. An internal field change may trigger this review; it must never silently rewrite a public claim.

Price changes, new market conditions, competitor claims, customer-evidence permissions and legal assessments can open the same review route. A calendar check still catches evidence that expires quietly. If customer permission is withdrawn, remove that evidence from eligible outputs and identify every published use. When a source conflicts with the claim, preserve both versions and send the conflict to the qualified owner.

A large product update may affect many records. Batch the impact review if that makes the work manageable, while keeping approval at the individual claim or governed-group level. A missing evidence owner blocks full approval until somebody accepts the gap.

The change is the real acceptance test

After the release, a reviewer should be able to trace the old and replacement claims to their evidence and owners. The system should show every affected surface, keep unsupported and expired records out of AI retrieval, and prevent a draft product fact from reaching the public site. A later owner should understand why the wording changed without calling its creator.

Build this first thread in Airtable, Notion, a database or another tool the team already maintains. Stable identifiers, source links, visible states, permissions and a named maintainer matter more than the brand of database. Add automation after people can update the records correctly by hand.

For help resolving the audience, value and claims before building the system, see Positioning & Product Value. For help connecting the records to working automations, see AI Product Marketing Operations.