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.
Diagram: four contexts around one fact, each fact carrying its evidence, source, time and coverage.
The dealgraph is one structured, auditable record of everything that decides a deal. It is built across four contexts. Your company context is declared and versioned: ICP, personas, buying roles, products, pricing, proof points, competitive position, sales process, stages, exit criteria, playbook rules and policy limits. Account, deal and rep context are observed and append-only: firmographics, funding and leadership changes; stakeholders, objections, commitments, requirements and risk; execution, follow-through and method adherence over time. Every fact carries its evidence (the statements behind it, with speaker and timestamp), its source (which system it came from), its time (when it was first observed and when it was superseded) and its coverage (how much of the available input was read). A fact is one of four kinds: observed, derived, inferred absent, or unknown, and the record says which.
A deal cannot be understood from the deal alone. It takes what you sell, who you sell to, what happened, and how your team sells.
Diagram: four contexts, your company declared and versioned, and account, rep and deal observed and append-only, wired to one fact in the middle, champion equals Priya Nair, carrying its evidence, source, time and coverage.
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
Diagram, read bottom to top: the sources you connect, then capture, interpret and resolve, then the dealgraph with its four contexts, then the agents that run on it.
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.
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.
Connected in days. No new system for your reps to learn, and no change to how they work. Everything sits on one record.
The dealgraph as a tool your agents can call, typed, with evidence and coverage. What in-house teams build with it:
Your automations, your models, your tokens.
everything above runs on the same record
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: never asked" 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.