A Truth Graph implementation case study

Every VP of GTM has been asked the question they cannot answer with data: what is actually working in our positioning? The honest reason it has no answer is architectural — the claims live in prose, and prose cannot be queried, versioned, or propagated. This is a case study of the implementation that changes that, built and run on Assay’s own canon.

The Commercial Truth manifesto argues marketing has never had infrastructure — the schema discipline engineering gets from a repository, finance from a ledger. A Truth Graph is what that discipline looks like applied to commercial claims. The implementation question is concrete: what does it take to stand one up, and what does it enforce once it exists?

Buyers who have not seen a typed claims graph reasonably ask whether it is shipped or a roadmap slide. The proof offered here is that Assay’s own positioning, pricing, competitive intelligence, and proof already run on one — the same schema, engine, and endpoints customers get. The numbers below are an approximate snapshot, regenerated from the live database before publication; reporting them that way is the calibrated posture the system enforces.

What a Truth Graph implementation actually is

Strip it to the primitive: every commercial claim is a node, and every node carries a typed schema. In the version Assay runs on, each node holds six fields:

• node_type — the typed schema (positioning statement, pillar, pricing, competitive talktrack, proof point, objection response, and so on)
• id — a stable identifier for cross-reference
• status — draft, approved, or archived
• source_type — how the claim arrived, with a confidence ceiling
• confidence_score — a number in [0,1] that respects the ceiling
• edges — explicit references to every dependent node

This is the schema discipline a database imposes on application data, applied to the function that never had it. The graph database underneath is ordinary technology. The typing — and the rules attached to each type — is the part that does the work.

A single node makes it concrete. The claim Starter tier is priced per seat at the published rate is one node: type pricing, status approved, source first-party verified, confidence near 1.00, with edges to the pricing page, the proposal template, the deal-desk policy, and the AI SDR’s allowed-claims set. Change that one node and every edge is a path the change can travel.

Enforcing the source-type ceiling

The detail that makes it more than a database is the ceiling. Each node’s source type carries a maximum confidence it can reach, and the stored score is min(source_ceiling, computed_score). An AI extraction from a third-party page caps at 0.60 however certain the model is; a board-approved fact can reach 1.00.

Enforcement is data-driven, not hard-coded. The ceilings live in a lookup table that the continuity rule reads from, so adding a source type is a one-row change rather than a code release. The same continuity rule is where an early audit found a real failure — an AI extraction had been allowed to overwrite a higher-authority source because the rule did not fire on the AI-derived type. The ceiling is the fix that makes “the model was confident” stop outranking “a human verified it.”

And there is a standing invariant. A query for any stored node whose confidence exceeds its source ceiling must return zero rows — if it ever does not, that is a bug, asserted in CI rather than trusted by convention.

Cascade propagation

A claims graph earns its keep when one node changes. Each node declares edges to the surfaces that depend on it, so an edit walks the dependency graph and flags every downstream node for review.

A concrete event from Assay’s canon: in May 2026 a single positioning line was updated, and the cascade flagged 14 downstream nodes — the brand canon, several product canons, pricing copy, and a shelf of expressions. The flagging is automatic; the resolution is a human-approved review queue, by design. Autonomous canon-update is gated on review, not assumed.

A second event the same month — swapping one word across the canon, from AI to apps — flagged the brand canon, all eight product canons, and roughly twenty expression seeds, resolved in one pass. This is not a feature demo; it is the actual propagation behavior on the actual canon.

What the propagation rides on is the source-type discipline underneath. Of the roughly 700 nodes, about 60% are first-party verified and a quarter are unverified drafts, with small slices second-party, third-party, and AI-derived. The AI-derived share is held below human-verified by the ceiling, so a cascade never promotes a guess into approved copy.

What the operator queries

For the person who owns positioning, the implementation shows up as a different daily motion. Instead of searching folders to learn whether a battlecard is current, they query a node and read its state — source type, confidence, last verification, and the surfaces that depend on it.

A claim near its ceiling with a recent verification is safe to quote. A claim capped low, or flagged stale because the competitor it describes just shipped, surfaces in the review queue before it reaches a buyer. The inspection that used to be tribal knowledge becomes a property of the record.

This is where source typing pays off in practice. A rep does not have to know that a price was AI-extracted from a stale page; the node’s ceiling already held it back, and the badge already says so. Trust moves from the person to the record.

The audit layer

Every change writes a hash-chained audit-log entry — which node changed, who changed it, when, and the evidence behind it. The chain is independently verifiable.

That is what lets a buyer ask why does this claim read this way and get an answer regenerable from primary records rather than a recollection. The trail is the difference between “trust us” and “verify us.”

What it does and doesn’t prove

The implementation is honest about its edges. Not every node is promoted from draft to approved; the canon has known stale cells; the flagging is automatic but the resolution is human work. The roughly 700-node canon is a fraction of customer scale — a customer at $50M ARR would run an estimated 5,000-20,000 nodes. The architecture scales; the operational discipline at that scale is the work ahead.

Stating that plainly is not a hedge. It is the same calibrated posture the source-type ceiling enforces on every claim in the graph — confidence bounded by evidence, not by tone.

Closes / opens

For the technical buyer, the question was is this built or is it a promise. The answer is that the canon running this company runs on it. For the operator, the test is whether any claim you make can show its type, source, confidence, and dependents — if it cannot, you have documents, not a graph.

The methodology Assay is developing for the Commercial Truth Index scores these same properties across vendors, Assay included, with no preferential treatment. A vendor that runs on its own substrate can be measured on it.

Closes the dogfood cluster’s implementation seat (LSO §F.20): the architecture, not the demo. Opens the scale question — what changes in the cascade and review-queue design between a 700-node canon and a 20,000-node customer graph.

This essay is grounded in Assay’s dogfood case study, Truth Graph product canon, and source-type vocabulary. Node counts are an approximate 2026-05-27 snapshot, regenerated from primary records before publication. Methodology for the Commercial Truth Index is in development.