Chapters
- 01 · Turn a Vague Request Into a Decision
- 02 · Name the Owner and Business Purpose
- 03 · Define the Allowed Outcomes
- 04 · Choose the Required Evidence
- 05 · Separate Hard Rules From Interpretation
- 06 · Add Unknown and Review Outcomes
- 07 · Decide What May Happen Next
- 08 · Capstone: Complete the Decision Card
15 min · Interactive exercise
Capstone: Complete the Decision Card
Validate the whole card against a set of records and approve version 1.0.
Each section of the card is defensible on its own. The outcome set is closed. The evidence requirements are stated. The rules are ordered and the veto is explicit. The action map gates on risk.
None of that proves the card works, because every section was written while looking at that section. The failures that matter are the ones between sections: an outcome with no action row, a rule that can only be satisfied by evidence the card marks prohibited, an escape hatch whose default is an outcome the action map forbids the system to take on its own.
Run the records, not the sections
The capstone runs the assembled card against a set of records chosen so that each one lands on a different part of it: Priya's request with complete evidence, the regional non-profit who is the outcome set's whole reason for existing, the staffing agency who should stop at the direction rule, the enormous company whose test message should be vetoed before any threshold is evaluated, the record with nothing usable on it that should return unknown rather than a pessimistic answer, and a record whose decision never returns and should hit the timeout, take the defined default, and be marked as defaulted rather than decided.
What this actually buys you
A Decision Card that passes its own capstone can be handed to someone who was not in any of the conversations, and they will build the thing you meant. That is the entire test.
It also gives you something to argue with. The definition is now a document rather than a behavior, which means a disagreement about routing is a disagreement about a sentence somebody can point at, resolved in a meeting, instead of a disagreement about what the system appears to be doing, resolved by whoever is willing to open the automation.
And it is what makes the next guide safe. Once the outcomes, the evidence, the rules, and the action limits are written down, adding a model to the interpretive rules is a bounded change to one section, with a specification to test it against. Without the card, adding a model means finding out what your decision was by watching what it does.
Carry this into your business
Hand your finished card to somebody who was not in the room and ask them what the system will do with a specific awkward record. If they can answer from the card, it is done. If they ask you a question, the answer to that question is the section you have not written yet.
GTM Lab
Saved locallyDecision Card
sample-decision-card · v1 · draft
Run the record set
Six records, each chosen to land on a different part of the card. Every section held up alone; this is the first time they have to hold up together.
- Priya Shah, matched account, complete evidenceRoute to a seller
The clean path. Every required input observed, nothing estimated. - Regional non-profit, genuine question, far below scaleKeep and nurture
The outcome set’s whole reason for existing. - Staffing agency above the revenue threshold, selling to usNot a prospect
Stops at the direction rule, which no threshold could have caught. - Global manufacturer, clears every threshold, message reads "test test"Not a prospect
Vetoed by an interpretive rule before any threshold is evaluated. - Free email, company name "n/a", two-word messageNot enough information to decide
Unknown rather than a pessimistic answer nobody judged. - Decision triggered and never returnedRoute for review, marked defaulted
Hits the timeout, takes the defined default, and is not recorded as decided.
Run all 10 validation checks
The checks test the seams between sections, since every section was written while looking at that section. Each runs by its stable ID and reports pass or fail with a reason.