Chapters
- 01 · Show the Facts Behind the Result
- 02 · Show Which Rule Mattered
- 03 · Separate Facts From Inference
- 04 · Communicate Unknowns and Confidence
- 05 · Route Ambiguous Cases for Review
- 06 · Support Overrides Without Erasing History
- 07 · Protect Human-Owned Decisions
- 08 · Capstone: Review and Resolve Three Decisions
15 min · Interactive exercise
Capstone: Review and Resolve Three Decisions
Work a real queue as the reviewer and validate the whole policy.
Every other lab in this pillar put you in the designer's chair. This one does not.
You are the reviewer. Three items are in the queue, the policy you wrote is what generated them, and you are about to find out whether it works from the side that has to use it.
The three cases
A conflict on the deciding field. Two sources disagree about company scale, and scale is what the answer turned on. The explanation should show both values, both sources, both observation dates, and name the rule that needed the field. You should be able to resolve it without opening another system.
An inference presented as an inference. No revenue on record; the decision estimated and routed. The display should mark the estimate, show what it was inferred from, and let you confirm or correct it. If you find yourself unable to tell which values were observed, Chapter 3's rule is not implemented.
A recommendation you disagree with. You hold context the system cannot see. Override it, choose a reason from the list, and check afterward that the recommendation is still readable beside your decision. If your override replaced it, Chapter 6's rule is not implemented.
What this actually buys you
Two things, and the second is the one that compounds.
The immediate one is that people use the system. An answer somebody can inspect gets weighed rather than ignored or obeyed, which is the only relationship with an automated decision that survives contact with a real week.
The lasting one is that you can find out whether it is any good. Because the recommendation survives every override, because every result names the rule that decided it, and because every override carries a reason from a countable list, you can answer questions no unexplained system can: which rule gets overridden most, whether override rate is rising in one segment, whether the disagreements cluster where the evidence is inferred rather than observed. Every one of those is a specific instruction for what to fix next.
A decision system without this is not just opaque. It is unimprovable, because nothing it produces tells you where it is wrong.
Carry this into your business
Pick the automated decision your team argues about most and ask which rule it overrides most often. If nobody can answer, that is the whole gap, and it is a smaller piece of work to close than it looks.
GTM Lab
Saved locallyReview Policy
sample-review-policy · v1 · draft
Work the queue
Every other lab in this pillar put you in the designer's chair. This one does not. You are the reviewer, three items are in the queue, and the policy you wrote is what generated them.
- Two sources disagree about company scale, and scale is what the answer turned onConflict on the deciding field
The explanation should show both values, both sources, both observation dates, and name the rule that needed the field. You should be able to resolve it without opening another system. - No revenue on record; the decision estimated and routedInferred value on the deciding field
The display should mark the estimate, show what it was inferred from, and let you confirm or correct it. If you cannot tell which values were observed, Chapter 3 is not implemented. - A recommendation you disagree with, because you hold context the system cannot seeReviewer judgment
Override it, choose a reason from the list, and check afterwards that the recommendation is still readable beside your decision. If your override replaced it, Chapter 6 is not implemented.
Run all 11 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.