Skip to content
Article

What dbt did for the data warehouse, the Truth Graph does for commercial claims

June 2, 2026

Data got a transformation and lineage layer. The claims your company makes to the market never did. Here is the dbt-shaped substrate for marketing knowledge.

Every RevOps lead who has run a warehouse knows the feeling before dbt arrived. Raw tables landed from a dozen sources, analysts copied SQL between dashboards, and no two reports agreed on what “active customer” meant. The numbers were all technically present; none of them were governed.

That is exactly where commercial claims sit today. Your positioning, your pricing, your proof points exist somewhere — in a Google Doc, a deck, an AI prompt, a battlecard nobody updated. The Commercial Truth manifesto argues that marketing is the last function operating without infrastructure for what it produces.

The fix is structurally the same one data teams already lived through. dbt did not store more data; it put a typed, versioned, tested transformation layer between raw tables and the dashboards that consumed them. The Truth Graph does the same for the claims your company makes to the market.

The parallel data teams already understand

Assay’s own brand canon draws the line explicitly. “Code got Git. Finance got the ledger and GAAP. The internet got DNS. Data warehouses got dbt and modern observability” (Source: Assay brand canon v2, §10 Truth Graph manifesto). Marketing — the function that decides what your company is to the market — got none of it.

The canon’s parallel table is precise about the before-state of data: “Spreadsheets emailed around, no lineage, no tests” (Source: Assay brand canon v2, §10). Swap “spreadsheets” for “decks and Notion pages” and you have the marketing org of 2026 verbatim. Same disease, different artifact.

What dbt actually contributed was not a database. It was four primitives: models you define once, version control over those definitions, lineage that tracks what depends on what, and tests that fail loudly when an assumption breaks. A claims substrate needs the identical four — applied to sentences instead of SELECT statements.

Why this matters now, not in 2020

The substrate shift is being forced by AI, the same way cloud warehouses forced dbt. When a query was expensive and rare, ungoverned SQL was survivable. When every analyst ran a hundred queries an hour, the lack of a transformation layer became the bottleneck.

The same inflection has hit commercial claims. “AI has made it possible for any company to send 100,000 ‘personalized’ emails for the price of a cup of coffee,” and the result is what the canon calls a Communication Glut (Source: The New Revenue Stack, Assay 2026). Volume stopped being the constraint; consistency became it.

When the website says one thing, the rep says another, and the AI agent invents a third, you have what that essay names Truth Fragmentation — and it cites that “69% of buyers report encountering vendor inconsistency during their purchase journey” (Source: Gartner 2026, via The New Revenue Stack). A precise reply lift figure for fixing it is not yet published; we report dogfood results as credible intervals, not point estimates.

The four primitives a claims substrate introduces

The Truth Graph turns each commercial claim into a node — the unit that the rest of the stack reads from and writes to. This mirrors the dbt move from loose tables to defined models. The canon lists the node types directly: PositioningStatement, Pillar, Expression, ObjectionResponse, CompetitiveTalkTrack, BuyerArchetype, ProofPoint, PricingTier (Source: Assay brand canon v2, §10).

First, claims become typed and sourced. Today a positioning claim is a sentence in a doc; in the substrate it carries a type, a source attribution, and a confidence score — Assay’s source-type taxonomy makes provenance a required field, not an afterthought.

Second, claims become versioned by default. “Every node has a version history. Every change is a commit. You can diff your positioning against last quarter the way an engineer diffs code against last release” (Source: Assay brand canon v2, §10). This is Git for marketing claims, running underneath the dbt analogy.

Third, claims gain lineage, which the canon calls Cascade. “When the PositioningStatement changes, every Expression that depends on it gets flagged. Every battlecard that quotes it gets flagged. Every AI prompt that grounds in it gets flagged” (Source: Assay brand canon v2, §10). That is dbt run for a repositioning.

Fourth, claims carry tests — outcome evidence attached to the assertion, so a claim reads “what we say, last validated days ago, with a reported credible interval” rather than a bare line in a deck (Source: Assay brand canon v2, §10). Specific lift figures are reported as credible intervals once a holdout clears, not asserted as point estimates here.

A worked example

A deal desk approves new enterprise pricing on a Tuesday. In the ungoverned world, that fact now has to be manually chased into a pricing page, three battlecards, the AE deck, the onboarding script, and the prompt behind your AI SDR. Most of those updates do not happen, which is how a rep quotes a number the deal desk retired weeks ago.

In the substrate, the PricingTier node changes once. Lineage immediately flags every downstream node that referenced the old figure — the same dependency walk dbt performs when a source model changes. RevOps sees the blast radius before anything ships, and the canon describes this exact freshness propagation in The New Revenue Stack: “Instantly, every AI bot, every AE slide deck, and every proposal in the field reflect the new reality.”

The difference is not speed for its own sake. It is that the claim has an owner, a timestamp, and a dependency graph — so a stale number becomes a flagged failure rather than a silent one. That is the whole point of moving from documents to models.

What this is, and what it is not

A claims substrate is not a smarter document store, and it is not RAG over scattered documents. Retrieval over a folder of PDFs leaves every consumer to interpret stale text on its own; a typed graph gives every consumer the same governed fact (Source: The New Revenue Stack).

It is also the layer every AI agent needs as a source of truth. dbt did not replace the warehouse; it made the warehouse trustworthy enough to build on. The Truth Graph plays the same role for the commercial claims your reps and agents already depend on.

Closes / opens

Closes the parallels cluster (LSO §F.6): the question of which infrastructure shift commercial claims are due for has a precise answer — the dbt one. Data got typed models, lineage, and tests between raw tables and dashboards; claims get typed nodes, cascade, and outcome evidence between the canon and every surface that quotes it.

Opens the next question: once claims have lineage, how do you score the quality of that graph — its grounding, calibration, coherence, and auditability — across an entire revenue org, the way a data team scores test coverage?

That scoring problem is the methodology Assay is developing for the Commercial Truth Index, which measures whether the substance an org emits is grounded, calibrated, coherent, and auditable rather than merely present.

This essay is grounded in the Assay brand canon v2 (§10 Truth Graph manifesto) and The New Revenue Stack canon. Methodology for the Commercial Truth Index is in development.

FAQ

Frequently Asked Questions

What does 'dbt for marketing data' actually mean?
It names the missing layer that does for commercial claims what dbt did for raw warehouse tables: typed models, version control, lineage, and tests. Today positioning, pricing, and proof points live in untracked docs. The Truth Graph makes each a versioned, sourced, testable node.
Is this just a content management system for marketing?
No. Content management platforms store finished documents. A claims substrate stores the atomic facts beneath them — each typed, sourced, and confidence-scored — so a single change propagates to every doc, rep, and AI agent at once, the way dbt re-runs every downstream model.
Who owns this layer inside a revenue team?
Usually RevOps, the same function that owns warehouse hygiene and tooling lineage. The positioning owner authors the claims; RevOps governs how they propagate across the stack. Source: Assay brand canon v2, BUY-05 and BUY-02 archetypes.
How is lineage different from a knowledge base?
A knowledge base tells you what a claim is. Lineage tells you what depends on it. When a pricing claim changes, lineage flags every battlecard, deck, and agent prompt downstream — so nothing goes stale silently.