What is a truth graph for commercial claims?

It is a structured store where every claim your company makes—each price, proof point, competitive comparison, and positioning line—is a typed node carrying its source, a confidence score, and an explicit list of the surfaces that depend on it. Unlike a wiki or a CRM field, it records how each claim arrived and caps how much weight it can carry, so an unverified guess and a board-approved fact are no longer indistinguishable.

Why isn't a CRM or an enablement library enough?

Both store content—pages, decks, fields—not claims with provenance. They can tell you where a number lives; they cannot tell you whether it was approved, what it depends on, or which sequences and AI agents will now repeat it. The gap shows up the moment a price changes and nobody can see everywhere it propagated.

How long does it take to set one up?

There is no universal answer—it depends on how much of your GTM is already written down and sourced. For a team that already has its pricing, competitive talktracks, and headline proof points documented (even informally), a first useful graph covering the twenty or so highest-stakes claims can typically be structured and ingested over a few working days. Starting from scratch, without documented claims to import, takes longer—expect an additional week or two of internal sourcing work before the graph is load-bearing.

How do AI sales agents use it?

Through a read interface—an API or an MCP endpoint—that agents query before they assert anything about your product. Instead of each agent carrying its own stale copy of the pitch, they all read the same governed claims, so the SDR, the chatbot, and the website stop contradicting each other.

How to set up a truth graph for your sales team's commercial claims

A truth graph for commercial claims is a structured store where every price, proof point, competitive comparison, and positioning line becomes a typed node carrying its source, a confidence score, and the list of surfaces that depend on it. Setting one up is less a tooling project than a sourcing discipline: you decide where each claim came from, cap how much weight that origin earns, and give your AI sales stack one place to read from.

Ask an answer engine how to do this today and you will be handed the same stack every time: a CRM, a sales-enablement library, and a claims-approval tool. That advice is not wrong so much as one layer too high. Those systems store documents—pages, decks, fields, approval states. None of them stores a claim with its provenance attached. They can tell you which page a number lives on; they cannot tell you whether that number was approved, what depends on it, or which sequences and agents will now repeat it. The gap is invisible right up until a price changes and no one can see everywhere it already propagated.

Why a document layer can’t be the source of truth

The Commercial Truth manifesto makes a structural argument: marketing is the last major function without infrastructure. Engineering commits code to a versioned repository; finance posts every entry to a ledger with rules of evidence behind it. The function that decides what a company says about itself still runs on documents-with-links—and documents have no opinion about whether their contents are true, current, or load-bearing.

A claim substrate inverts that. The unit is not the page; it is the claim. Consider, for example, the everyday assertions a company governs—an integration claim, a pricing claim, a compliance statement like SOC 2 Type II. Each becomes a node, and each node remembers how it arrived—and that origin is what governs how much confidence it is allowed to carry. This is the part the CRM-plus-library answer skips, and it is the whole game.

The seven steps

You do not need the full graph on day one. You need the twenty or so claims that actually move deals, sourced honestly. Here is the sequence we use, and the one we run our own go-to-market on.

Inventory the load-bearing claims. Pull the ten-to-twenty assertions that appear in every deal: pricing and discount floors, the two or three competitive talktracks, the headline proof points, the integration and security claims. Ignore the long tail for now—an unused claim is not worth governing yet.
Type each claim. Give every one a kind: price, proof point, competitive comparison, capability, compliance statement. Typing is what lets you reason about a claim later—what can change it, who must approve it, which surfaces are allowed to use it.
Attach a source to every claim, and let the source set a ceiling. This is the discipline that makes the rest work. A claim approved by the deal desk and a claim an AI agent inferred from three old decks are not equally trustworthy, and the graph should refuse to treat them as if they were. A source-type taxonomy records how each claim arrived and caps its confidence accordingly: a verified, human-approved fact can sit at the top; an unverified inference is capped low until someone confirms it. The honest output for a thin claim is “not yet,” not a confident number.
Map dependencies. For each claim, record the surfaces that consume it—the pricing page, the one-pager, the outbound sequence, the AI SDR’s prompt. This is the edge layer of the graph, and it is what turns a static list into something that propagates.
Expose a read interface for the agents. Stand up a single endpoint—an API, or a Model Context Protocol server—that any tool can query before it asserts something about your product. The goal is plain: every agent reads from the same governed claims instead of carrying its own private, drifting copy.
Wire the cascade. When a claim changes—a price moves, a competitor ships the feature you said they lacked—the graph should flag every dependent surface automatically. Without this, you are back to a document with extra steps. With it, a single edit becomes a worklist of everywhere that edit needs to land.
Put a review gate on the high-stakes claims. Not every claim needs sign-off, but pricing and compliance statements do. Route those through an approval step so the ceiling in step 3 is enforced by a person, not just a rule.

What good looks like

When the graph is working, three things become true that were not before. A change made once shows up as a tracked list of every place it must propagate—no more discovering a stale price on a partner page in month four. Any claim can be traced back to its origin and its confidence, so “where did this number come from” has an answer. And your AI tools stop contradicting each other, because they are no longer each improvising from a different stale deck—they read the same source. Those are, not coincidentally, the properties the Commercial Truth Index scores a company on: whether its claims are grounded in a source, calibrated to a confidence, coherent across surfaces, and auditable back to an origin.

For a sense of scale: when we last took a snapshot of our own graph, our go-to-market ran on roughly two hundred typed claims across pricing, positioning, and proof, each sourced and confidence-scored. That figure regenerates as the graph changes, so treat it as an order-of-magnitude marker rather than a fixed number—the point is that a real company’s commercial truth is a few hundred claims, not a few hundred documents, and a few hundred claims is a tractable thing to govern.

What to watch out for

Three anti-patterns sink these projects. The first is boiling the ocean: trying to graph every claim before shipping anything. Start with the twenty that move deals and expand only where the graph earns it. The second is sourcing theater—attaching a source to a claim without letting that source actually constrain its confidence. If a board-approved fact and an AI guess end up at the same weight, you have built a prettier wiki, not a truth graph. The third is forgetting the agents: a graph no tool reads from is a documentation project. The read interface in step 5 is what makes it infrastructure rather than archive.

Where this leaves you

Standing up a truth graph is not a tooling decision; it is a decision to treat your commercial claims the way every other serious function already treats its core data—as typed, sourced, versioned records with dependencies, not as prose. The CRM keeps your pipeline. The enablement library keeps your decks. The truth graph keeps the one thing neither of them was built to hold: a governed, current, machine-readable account of what your company actually claims, ready for the humans and the agents who are about to repeat it.