What is a typed knowledge graph for marketing claims?

A knowledge graph where every commercial claim — a price, proof point, competitor comparison, or positioning statement — is a node with a declared type, a source, a confidence score, and explicit links to every surface that depends on it. The typing is what lets software reason about a price differently from a battlecard.

How is it different from a generic knowledge graph?

A generic graph stores nodes and edges of any kind; the database is available off the shelf. The novel part is typing the nodes as commercial claims and enforcing source-type ceilings and cascade propagation on them — the schema for claims, not the graph itself.

How big is a real commercial claims graph?

Assay runs its own canon on one: roughly 700 typed nodes as of a 2026-05-27 snapshot, regenerated from the live database before publication. A customer at $50M ARR would run an estimated 5,000-20,000 nodes.

Does a claims graph replace our wiki or CRM?

No. It sits beneath them as the claim layer they read from. The wiki still hosts long-form docs and the CRM still owns the deal record; the graph governs the claims those tools reference so they stay accurate.

A typed knowledge graph for marketing claims

A knowledge graph is a generic thing — nodes and edges, the structure behind a search engine or a recommendation feed. A typed knowledge graph for marketing claims is narrower and more useful: every price, proof point, competitive comparison, and positioning statement becomes a node with a declared type, a source, a confidence score, and an explicit list of every surface that depends on it. The graph is old technology; typing it for commercial claims is the part nobody had built.

The Commercial Truth manifesto argues marketing has never had infrastructure — the schema discipline a database imposes on application data, or a type system imposes on code, applied to what a company says about itself. A graph alone does not deliver that discipline. A typed graph — where each claim is a first-class object with rules about how it can change — does.

For a VP of GTM, the payoff is a different board meeting. The avoided question — what is actually working in our positioning — has only ever had an anecdotal answer because the claims lived in prose nobody could query. When the claims are typed nodes, the question becomes a query.

Why “typed” is the load-bearing word

Most teams already have a knowledge graph in spirit: a wiki, a CRM, a folder of decks, all cross-linked. What they lack is types. A page about pricing and a page about a competitor are the same kind of object to the system — a blob of text — so the system cannot reason about them differently.

Typing changes that. A node declared as a pricing claim can carry an expiry; a competitive talktrack can be flagged stale the day the competitor ships; a positioning statement can cascade to every surface that quotes it. The schema is what lets the software help — the same reason a CRM beat a spreadsheet of contacts.

Each type earns its own behavior. A pricing node can carry a region and an expiry; a proof point can require a customer-confirmed source before it leaves draft; a competitor node can subscribe to the rival it describes and raise its hand the moment that rival ships. None of that is reachable when every claim is the same undifferentiated text.

What every node carries

In the version Assay runs on, every claim node carries six things:

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

Source: Assay’s dogfood case study and source-type vocabulary.

The source type is the honest part. A claim an AI inferred from scattered docs caps at 0.50 and cannot outrank a board-approved fact at 1.00 — final_confidence = min(source_ceiling, computed_score). Confidence is bounded by provenance, not by how sure the model sounds.

Two of those fields do quiet, heavy work. Status keeps draft thinking out of customer-facing surfaces until a human promotes it. Edges are what make a change propagate instead of rot — the difference between updating a claim and updating every place that claim is quoted.

A worked example, at the scale we run it

This is not a thought experiment; it is how Assay’s own canon runs. As of a 2026-05-27 snapshot, roughly 700 typed nodes hold the company’s positioning, pricing, competitive intelligence, and proof — about 80 positioning nodes, around 480 across the product canons, 42 competitor nodes, and the rest spanning verticals, use cases, governance, and essays.

The source-type distribution is published, not asserted: roughly 60% first-party verified, 25% first-party unverified drafts, and small slices of second-party, third-party, and AI-derived claims — the AI-derived share capped below human-verified by construction. These figures are approximate; exact counts regenerate from the live database before any external use. Reporting them as a range rather than a false-precision number is itself the calibrated posture the graph exists to enforce.

When one node changes, the dependents are flagged. A single positioning-line edit in May propagated to 14 downstream nodes — brand canon, product canons, pricing copy, and a shelf of expressions — resolved in one cascade-review pass. A second edit the same month, one word changed across the canon, flagged the brand canon, all eight product canons, and a shelf of expression seeds; the propagation is the same machinery whether the change is a price, a positioning line, or a single word.

What it isn’t

A typed claims graph is not a generic graph database; the database is the easy part, available off the shelf. It is not an AI content generator; it governs whether what gets generated is true, not how much gets generated. And it does not replace the wiki or the CRM — it sits beneath them as the claim layer they read from.

The distinction matters because the generic version is crowded and the typed version is empty. Graph databases are a solved, commodity layer. A typed schema for commercial claims — source ceilings, cascade edges, and an audit trail attached to each claim — is the part that did not exist, and the part everything above it depends on.

Closes / opens

For the operator, the test is simple: can you point at any claim your company makes and see its type, its source, its confidence, and everything downstream that depends on it? If not, you have documents about your claims, not a graph of them.

The methodology Assay is developing for the Commercial Truth Index scores exactly these properties — source coverage, source-type distribution, confidence-ceiling compliance — across vendors, including Assay itself. The typed graph is what makes a vendor scorable at all.

Closes the dogfood cluster’s concept seat (LSO §F.20): the difference between a graph and a typed graph of commercial claims. Opens the migration question — how a team moves its claims out of prose and into types without stopping the business to do it.

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