The dealgraph
The dealgraph is a structured, auditable record of a deal, built from the sources a sales team already has. Every fact in it carries its evidence, its source, its time and its coverage. This page explains what it holds, how it is built, and why you can trust it.
Illustrative: the dealgraph for Northwind Retail, a new business deal, as a matrix of source-linked facts. 984 recorded facts, of which 54 are inferred, and 90 missing details with no source, one tile per recorded fact or open question. Four contexts. Rep, the seller's relevant context and activity: 224 facts, 11 inferred, 20 missing. Deal, needs, stakeholders, commitments, commercial discussions, progress and unresolved questions: 268 facts, 20 inferred, 28 missing. Account, the customer's business, people, systems and external developments: 262 facts, 16 inferred, 26 missing. Your company, your products, pricing, playbooks, collateral and company knowledge: 230 facts, 7 inferred, 16 missing. Six sources, each the primary source of some of the facts, inferred ones included; a fact may have several sources and missing details have none. CRM, 18 records, primary source for 200 facts. Email, 65 messages, 194 facts. Calendar, 7 meetings, 70 facts. Calls, 7 recordings, 196 facts. External data, 4 providers, 86 facts. Declared by you, 21 documents, 238 facts. Three tile states: a recorded fact, a tile filled in its source color; an inferred assessment, the same fill with a dot in the middle; a missing detail, a hollow tile, for example budget confirmation not found in the reviewed evidence. Five callouts. Observed, rep: talk ratio 62% across 7 recorded calls; 7 transcripts measured; highest on discovery calls at 71%; call analysis, updated today. Observed, deal: Stu Deel is the confirmed champion; 3 supporting sources; “Lead with store-ops savings; keep the integration timeline to one page.”; email, 14 Aug, Stu Deel. Missing, deal: no clear business case documented; 0 sources, not found in the reviewed evidence; held as an open question until a customer-side business case appears in the evidence; deal record, last checked today. Observed, account: Northwind appointed a new COO, effective 1 Oct; 2 supporting sources; “Northwind Retail names Priya Anand Chief Operating Officer.”; press release, 2 Sep. Inferred, your company: five case studies match this deal; 5 company documents assessed; the documents are company-provided, the match to this deal is an assessment; playbook library, reviewed 4 Sep.
Capture.Every payload is kept exactly as it arrived, so a better extractor improves the past as well as the future.
Interpret.What was said is turned into what it means against your company context, so “champion” means what your playbook says it means.
Resolve.People and companies are matched across sources, conflicts are decided in a fixed order of authority (your declared context, then your CRM, then facts already persisted, then web and enrichment only when the record cannot answer), and the losing candidate is kept with the reason it lost.
Every source, internal and external, ingested, interpreted and structured. Each fact carries the evidence behind it, where it came from, when we learned it, and how much of the picture we actually saw.
The statements behind the fact, with speaker and timestamp, and the candidates it beat, with the reason each lost.
Which system the evidence came from, and which producer and prompt version turned it into a fact.
When it was first observed, when it was superseded, and by what. History is append-only; nothing is overwritten.
How many inputs were read, how many failed, and what was never mentioned at all. Unknown is an answer.
A fact is one of four kinds: observed derived inferred absent unknown, and it says so
I'll take this to Marcus and push for Q1 budget.
Query any field across the whole book, see what each value rests on, and overrule it. A correction is not a ticket. It becomes the highest-authority fact in the system.
Illustration: the data workbench, a structured query across the book with the selected claim, its supporting evidence, the rejected candidates, and the accept, override and flag producer controls.
RevOps is the function most likely to block AI-generated deal data, precisely because they cannot inspect it. This is the inspection surface.
A correction is not a ticket. Overrule any fact from the workbench and the correction writes a user-authority claim that supersedes the producer's, permanently. The record remembers who made it and when. Flag a producer and the same mistake is caught across the book.
Reps stay where they work and your automations keep firing. But a CRM field holds a value, and nothing that lets anyone check it.
champion__c = "Priya Nair"A value, written by us so nobody has to type it. That is genuinely useful: the field is populated, the report runs, the workflow fires.
And that is all it can hold. Not the three statements behind it, not the two candidates it beat, not the fact that fourteen of fourteen inputs were read, not that she was a supporter in July and a champion by August.
The schema was never built to carry any of that, and no amount of custom fields fixes it.
champion = Priya Nair · confidence 0.86
I'll take this to Marcus and push for Q1 budget.Priya Nair, Gong, 12 Aug · +2 more, Gmail and Gong
The same fact, with everything that makes it defensible: challengeable by a person, usable by an agent.
Your CRM stays clean. Your automations keep firing.Because the record underneath holds what the CRM never could. Write-back is a projection, not the original, which is also why the record survives a CRM migration.
Everyone touching a new customer asks a different question of the same record, and every answer names what it rests on.
| Role | The question they ask | What they get |
|---|---|---|
| Rep | “What changed on my deals since Friday?” | Ranked actions with the reason attached, and a champion alert before the forecast call. |
| Sales leader | “Which of these commits are real?” | Deal inspection without a pipeline review. Evidence per deal, not a color. |
| RevOps | “Where is our data actually thin?” | Coverage per dimension, and who owns fixing it. No more spreadsheet reconciliation. |
| CRO | “Will the number hold, and why?” | Pipeline health with the reasoning attached, and fewer surprises at the board. |
| Finance | “How good is the pipeline behind it?” | Slippage and discount patterns from deal facts, not stage percentages. |
| Enablement | “What separates our best reps?” | Behaviors that actually correlate with winning, with the evidence behind them. |
| Marketing | “What comes up in deals we win?” | Objections counted for the content roadmap. ICP validated against closed deals. |
The dealgraph is one structured, auditable record of everything that decides a deal. It is built from the sources a sales team already has, across four contexts: your company (declared and versioned), the account, the deal and the rep (observed and append-only). Every fact in it carries its evidence, its source, its time and its coverage, meaning how much of the available input was actually read.
A CRM field holds a value and nothing else. It cannot hold the three statements behind a champion, the two candidates that lost and why, the fact that fourteen of fourteen inputs were read, or that the value was different in July. dealmkr writes the value back to your CRM so nobody has to type it, and keeps everything that makes it defensible in the record underneath. Write-back is a projection, not the original, which is also why the record survives a CRM migration.
Open any fact and you see the statements that support it, with speaker and timestamp; the candidates it beat and why each lost; how many inputs were read and how many failed; when it was first observed and when it was superseded; and which producer and prompt version wrote it. Facts are one of four kinds: observed, derived, inferred absent, or unknown, and the record says which.
The record resolves the conflict and writes down the decision. Authority runs in a fixed order: your declared company context first, then your CRM, then facts already persisted from calls, email and documents, then web and enrichment sources only when the internal record cannot answer. The losing candidate is kept, with the reason it lost.
It says so. If budget has never come up across twenty-two inputs, the record holds "budget: not found in 22 inputs" as a fact, and counts it as a gap rather than a pass. An unreadable or unclassified value always fails toward gap present, never toward no gap.
Yes, from the data workbench. A correction is not a ticket. It writes a user-authority claim that supersedes the producer's, permanently, and the record remembers who made it and when. You can also flag a producer so the same mistake is caught across the book.
Company context is what you declare: ICP, personas, buying roles, products, pricing, proof points, competitive position, sales process, stages, exit criteria, playbook rules and policy limits. It is versioned so that an artifact built in October resolves against October pricing even after the price list changes, and so that "champion" means what your playbook says it means, not what a generic model assumes.
Yes. dealmkr reads your CRM and writes facts back to the fields you choose, so reports keep running and automations keep firing. The record underneath holds what the CRM cannot.
Evidence-backed, AI-supported, on purpose. Not because a model improved, but because what you know about your deals finally accumulates instead of evaporating.