Every AI project I start begins with a document that has no code in it. Before a model is chosen, before a workflow is drawn, the discovery record gets written down. If the record cannot be filled in honestly, the build does not start.
This is not a requirements doc. Requirements docs describe what someone asked for. The discovery record describes what is true: how the work runs today, what a wrong answer costs, and what would prove the whole project wrong. Most AI projects that fail were honest at kickoff. They just never wrote any of this down, so the honest version of the project never got a chance to exist.
Who does the work now
The real sequence, not the org chart: which people touch the thing, in what order, with what interruptions. On the LeadsON platform, the workflow that mattered was not the one in the diagram. It was the one the operators ran, with workarounds that had never been written anywhere. A system built for the org-chart version of the workflow gets bypassed within a week. A system built for the real one gets used.
Which decisions the system supports
Every field in the record names a decision the system will touch, and for each one it records who currently makes it, on what evidence, and with what right. This is the field that separates assistance from accountability. The system may propose, sort, draft, or route. The decision that carries consequence stays with a named human, and the record says who, before the first line of code.
What a wrong answer costs
Decisions get graded before the build, not after the incident. Reversible output gets lightweight review. A wrong answer costs an edit. Painful-to-reverse output gets human judgment before execution. Costly-when-wrong output never executes unattended. The consequence class determines the machinery: you don't need the same control around a suggested email draft that you need around a pricing change that reaches customers.
What is assumed, and who owns the assumption
Every discovery contains assumptions: that the data is current, that the API behaves, that the person who described the workflow described all of it. The record lists them and names who owns each. An unnamed assumption is an unowned risk. When the assumption breaks, and one always does, the owner is already holding it.
What would prove it wrong
The last field is the one most projects skip: the falsification condition. What evidence, observed in the field, would mean the approach is wrong? Not "what does success look like." Everyone writes that. What would make us stop? A project that cannot name what would disprove it cannot tell you when it has failed, and those projects run for quarters after they should have stopped.
What the record prevents
The record is where scope arguments go to die. When a new feature request arrives mid-build, the question is not "can we" but "which field of the record does it change, and does that field still hold?" When production behavior contradicts the plan, the record is what tells you whether the plan or the observation is wrong, because the record says what you believed, in writing, dated, before you were invested in being right.
This is the same discipline CaseFlow runs as source: the discovery record exists as a typed artifact in the repo, and the workflow can't promote a stage whose record fields are empty. The document is not adjacent to the build. It is part of the machinery.
When to skip it
Never, for a consequential build, but the record scales. A two-week assistive tool gets a two-page record: who, which decision, what a wrong answer costs, what proves it wrong. An enterprise platform gets the full instrument. The point is not paperwork. The point is that a build that starts with written truth can be argued with. A build that starts with vibes can only be defended.
A build that already started without the record can still write it mid-flight, and a late record beats a project that can only be defended.