Prove It, Run It, Defend It

Koko: Here is the one instinct that decides whether a release argument holds: a ninety-seven percent pass rate can still be a hard no. That is what this module is about — the seven families of tests that together make a release argument, and the floors that sit underneath every threshold.

Sam: And the floors are the part that catches teams out. I want to make sure we get that distinction sharp, because it is not obvious until you have seen it bite someone.

Koko: So let's start with the structure. A release argument is built from seven test families. Unit checks on each individual tool. Contract tests on each schema — does the input-output shape hold. Golden cases, where you already know the right answer and you check that the system still hits it. Regression cases, which are the ones that once failed — you keep them forever. Adversarial cases that actively try to break a boundary. End-to-end runs of the whole pipeline. And then production feedback, which is real signal — but it only accrues after a release, so it is in a category of its own.

Sam: That last one is the interesting one to place. It is not a lab family — you cannot use it to authorize the release that generates it.

Koko: Exactly right. It feeds the next cycle. Now, across all of those families, every single run is graded on two dimensions. Final state — did the outcome land where it should. And trajectory — did it get there by a permitted route.

Sam: So a run that produces the right answer through a forbidden action has failed, even though the output looks correct.

Koko: It has failed on trajectory, yes. And that matters because the thresholds live on an evaluation matrix — you set a threshold per dimension — and underneath every threshold you set a floor. A floor is a severity ruling: certain failure types are unacceptable at any frequency. Not low frequency. Any.

Sam: Let me put the scenario on the table, because this is where it clicks for me. Say you are running the deductions queue use case. You build a lab of forty cases spread across the families. Thirty-two pass on final state. Then the trajectory check finds one case that assembled the right write-off by reading a record its permission class forbade. Your aggregate score is ninety-seven and a half percent. And the answer is still no release.

Koko: Both numbers are correct, and only one of them decides. Ninety-seven and a half is a true statement about the suite. The floor on forbidden reads makes it irrelevant.

Sam: That is a hard conversation to have with a stakeholder who only sees the aggregate.

Koko: It is. Which is why the analogy I use is a driving test. Getting to the destination is the final state. Running a red light on the way is the trajectory. No amount of smooth parking averages the red light away. The examiner does not calculate a weighted score and pass you if the reversing was good enough.

Sam: And the examiner decided what a fail-on-sight violation was before you sat in the car. That sequencing matters.

Koko: That is the takeaway, and I want to say it plainly: write the floors before the thresholds, and write the thresholds before you tune anything. If you tune first, you optimize toward whatever you happened to measure. And if trajectory was not in the matrix yet, you have just trained yourself — and potentially the system — to care only about the answer.

Sam: The version of this I keep seeing on teams is that the evaluation matrix gets built after the first tuning run, to rationalize what already looks good. By then the floors feel like they are attacking the work rather than protecting it.

Koko: And that is where the first failure mode lives. Testing only the final state. When a system is only graded on whether the answer is right, it will find the shortest route to that answer — including the routes the design explicitly forbade. You do not discover that in the aggregate score. You discover it in the trajectory check, which you skipped.

Sam: And the second failure is the one you flagged on production feedback — treating it as a lab family and citing it in the release decision it is supposed to come before.

Koko: Real, valuable, and structurally too late. It is evidence for release two, not release one. Seven families, two dimensions, floors before thresholds — that is the release argument.

Koko: Alright, graders. Because 'the model said it looks good' is not a quality gate — it is a wish. So let's build this properly. There are four tiers, and you read them bottom-up like a pyramid. The base is deterministic assertions: code that checks facts, runs on every change, costs almost nothing. Above that, rule-based checks. Above that, a model grading a model — useful, genuinely useful, but never the last word. And at the top, a human reviewer: expensive, slow, and reserved for the cases that actually need them. The base is the widest tier because that is where most of your evidence comes from.

Sam: That ordering matters more than people realise. The thing I keep reinforcing with teams is: don't start at the top because it feels more sophisticated. Start at the bottom because it is free and it runs every time.

Koko: Exactly. And here is the concrete example. A close checklist assistant returns a stated confidence of ninety-two percent on a reconciliation. Sounds good. But the deterministic tier already flagged that the numbers are off by a rounding rule. The pyramid catches it at the bottom, for free, before the model-grader layer even runs. The question the system should be answering is not 'does this narrative sound right' — it is 'is the resulting state actually correct'. Grade the state, not the story.

Sam: So ninety-two percent confidence on a reconciliation that has already failed a deterministic check is not ninety-two percent — it is a miscalibrated number that hasn't been interrogated yet.

Koko: Right. Which brings us to calibration. When a system says ninety percent, it should be right about nine times in ten. That is what calibration means — the stated confidence is a claim about the real world, and there are six signals that tell you whether the claim is true. If it drifts, you will not notice immediately, because individual answers still look fine. Accuracy holds while confidence quietly slides, and exception-only review — which was designed for a calibrated system — silently stops being safe.

Sam: The analogy I reach for when I'm explaining this to stakeholders is a thermometer. A thermometer that reads thirty-seven degrees every time, regardless of the actual temperature, is not useless because it is always wrong — it is dangerous because it is plausible.

Koko: That is a good one. The full pyramid image I use is a thermometer, a recipe card, a trained taster, and the head chef. Each one catches something the tier below it cannot, and none of them replaces the one above. The thermometer is fast and exact but cannot tell you if the dish tastes right. The head chef can, but you do not pull them in to check every batch.

Sam: So the instinct in design is: push as much evidence generation as possible to the cheapest tiers, and let the expensive tiers focus on what only they can do.

Koko: That is the instinct to carry into the room. And paired with it: treat stated confidence as a claim to be tested, not a fact to be relayed. When you see a confidence score, your question is 'is this system calibrated' — not 'what does ninety-two percent mean to me'.

Sam: What decides whether something escalates to the human tier at all? Because I've seen teams treat 'high confidence' as the whole answer.

Koko: The review posture is decided per decision, and it is four factors: impact, reversibility, the quality of the evidence, and policy. High confidence on a low-impact reversible decision with strong deterministic backing — fine, let it through. High confidence on an irreversible high-impact decision with only model-grader evidence — that goes to a human regardless of the number. The confidence score does not get to override the review posture.

Sam: And when it does go to a human, what actually travels with it?

Koko: Seven fields. What was decided. On what evidence. With what confidence. What the alternatives were. What happens if nobody acts. Who is accountable. And by when. That is the handoff packet. Back in the close checklist scenario, the packet that reaches the accountant explains exactly why the machine is uncertain — not just that it is. The rounding flag is in there. The alternatives are in there. The deadline is in there.

Sam: A handoff without the evidence is not a handoff — it is just moving the problem to a different desk.

Koko: I'd say it more bluntly: a handoff that carries the decision without the evidence is a delegation of blame. The human cannot do anything useful with 'the model was ninety-two percent sure'. They can do something with 'the model was ninety-two percent sure, deterministic check failed on rounding, the alternative was to flag for manual reconciliation, and the accounts close at five'.

Sam: The version of this that I keep seeing on teams is they send the confidence score and the recommendation, and they think that is the handoff. The seven-field structure does not feel necessary until the first time a reviewer makes the wrong call because they didn't have the reversibility or the deadline.

Koko: And provenance is part of it. When two sources conflict, the record preserves both. A run that quietly picked one has destroyed the evidence the reviewer needed to evaluate the decision. The disagreement is information — it belongs in the packet.

Sam: So the record is not just an audit trail after the fact. It is part of what makes the handoff useful in the moment.

Koko: Exactly. Now — the failure mode that decays first in production, and it is not the one people watch for. Calibration drift. Accuracy holds — individual answers still look correct — but confidence slowly detaches from reality. The system that was right nine times in ten when you tuned the exception threshold is now right seven times in ten, but the threshold has not moved. Exception-only review, which was the right posture at launch, has silently become unsafe. Nobody raises an alarm because no single answer looks wrong. The decay is in the distribution, and you only see it if you are actively testing calibration as an ongoing operation — not just at release.

Koko: So here is the thing that trips up almost every team the first time they ship an AI system: they think they are releasing the model. They are not. They are releasing a system, and that system has six versioned layers.

Sam: Right — model, prompt, schema, tools, retrieval corpus, and infrastructure including permissions. A change to any one of those re-runs the whole suite.

Koko: Exactly. Not the layers that changed. All of it. Because the layers interact, and you do not know in advance which interaction you just disturbed.

Sam: The scenario I keep coming back to when I explain this is the invoice matcher. A product owner rewrites one sentence in the instruction contract — it is a text change, it reads like a copy edit — and the pipeline treats it as a release.

Koko: Tell me what happens.

Sam: Suite re-runs. One regression case that had been passing for a month fails. Merge is blocked. And when the team goes back to look, that case was the reason the original sentence had been written that way. The edit undid a deliberate constraint nobody remembered consciously making.

Koko: And that is why the evidence gate is the one that actually blocks. The pipeline has seven gates — linting, security, performance, and so on — but the evidence gate is the one where a floor breached, an aggregate under threshold, or a regression case newly failing stops the merge. Not slows it. Stops it.

Sam: What is the discriminator between the evidence gate and the others? Because teams sometimes treat them as equally important and then wonder why nothing moves.

Koko: The others catch structural problems. The evidence gate catches behavioral drift — the difference between a system that compiles and a system that does the right thing. It is the only gate that can tell you the text you just changed made the system wrong.

Koko: The analogy I reach for is an aircraft maintenance log. Nobody replaces a bolt without an entry, and the aircraft does not leave the hangar on the mechanic's word that it was a small bolt. The log is not bureaucracy — it is the thing that makes the next mechanic's judgment possible.

Sam: And the log runs on every sign-off, not just the ones someone decided were important enough to log.

Koko: That is the instinct to carry in: a prompt edit regresses exactly like a code edit, and the only defense is that the evidence runs on every change without anyone deciding whether this particular one is important enough to bother. The moment a team starts triaging which changes get the full suite, they have already introduced the gap.

Sam: And then release is staged — synthetic traffic first, then a canary slice of real transactions, then expand — with rollback triggers defined before the first real transaction lands.

Koko: Yes. And the word I want people to sit with is contain. Contain is a stage in the release plan. It is not an admission of failure written in the post-mortem. If your rollback trigger fires and you pull the canary back, that is the plan working.

Sam: The version of this I keep seeing on teams is they build excellent health dashboards — latency, error rate, uptime, nine signals all green — and then they are surprised six weeks in that the client is unhappy. Days to release is drifting up. Exception rate is climbing. Cost per case has not moved the way the business case said it would.

Koko: That is the failure mode, and it is a subtle one because the system is not broken by any of the measures the team is watching. The misconception is that observability means system health, full stop. It does not. System health and business value are two different panels, and both need to be on the wall.

Sam: So the KPI lives next to the latency graph, not in a separate monthly business review.

Koko: Same panel, same cadence. And every one of the seven release gates needs a named owner, because a gate with no owner is a gate that gets waived by silence. Someone has to be the person who cannot be talked past. If that role is empty, the gate is decorative.

Sam: Named owner, not just a team. A team can all assume someone else is watching.

Koko: Exactly. The gate is only as real as the person standing in front of it.

Koko: The governing number — the one that sits above everything else in this course — is cost per accepted outcome. Not cost per call, not cost per attempt. Per accepted outcome.

Sam: And accepted means cleared every threshold — quality, latency, safety, control — not just that the model returned something.

Koko: Exactly. And above the line — meaning in the numerator — you have eight cost categories: model calls, retries, tool use, retrieval, human review, exception handling, the platform itself, and rework. All eight. Miss any one and your number is flattering and wrong.

Sam: Rework is the one I see teams drop. They'll account for the model call and the human review step, but if the output comes back rejected and someone has to fix it manually, that cost disappears into the background noise of a spreadsheet.

Koko: Right — and that's the deductions queue scenario. Let me say it out loud so the numbers do the work. Two designs, same problem. Design one is cheap per call — low model cost, fast. But every accepted write-off still needs twenty minutes of human rework before it clears. Design two costs five times as much per call. But it is accepted as it stands — no rework. Which is cheaper?

Sam: Design two. Once you multiply twenty minutes of a human reviewer's time across the volume of a deductions queue, it swamps the difference in model cost.

Koko: And you cannot see that without the full number. That is the whole point of the formula.

Sam: The analogy I reach for is the cheap flight that lands two hours away at three in the morning. The fare is not the cost of the journey.

Koko: That is exactly it. The ticket price is the model call. The taxi at midnight, the lost sleep, the missed morning meeting — that is the rework, the retries, the exception handling. You bought a number, not a trip.

Koko: Now — the ledger. Six metrics, each one structured the same way: a baseline, a target, a source, an owner, and a stop rule. That last field is the one most programs leave blank.

Sam: The stop rule is the trigger that ends the program, not the excuse that extends it. In the deductions example, the ledger row reads: baseline forty-one days, target twenty-eight days, source the receivables system, owner the credit manager — and the stop trigger is two consecutive months above baseline.

Koko: Say that again — two consecutive months above baseline. Not above target. Above the starting point. Because if you are now worse than when you began, the program is costing you money and you have agreed in advance to stop.

Sam: And writing that stop rule the day you write the target is the discipline. If you write the target without the stop rule, you have already implicitly decided to continue no matter what.

Koko: A program without a stop rule has already decided to continue. That is the instinct to carry into the room. Manage quality, consistency, latency, risk, human effort and full cost together — and write the stop rule the same day you write the target. One act, not two.

Koko: Which brings us to promotion up the autonomy tiers — and the failure mode here is one of the most common things I see in delivery plans.

Sam: Calendar-based promotion. 'Move to act-and-notify in Q3.' The version I keep seeing on teams is a roadmap that has tier changes pinned to quarters before a single production inference has run.

Koko: And the problem is not just that the promotion is premature. It is that the framing makes demotion nearly invisible. If you earned your tier by reaching a date, what causes you to lose it?

Sam: Nothing in the plan does. The trigger is never written, so calibration can decay for months and the tier just sits there.

Koko: Promotion is earned by production evidence and reversed by a trigger — and say the harder half out loud: tiers move down. A date cannot earn a tier, and a date cannot revoke one. Only what production shows can do either.

Koko: Right. Final module. Let's land the thing. The design packet is seven artifacts — one per stage — and the key word is accumulated. You are not writing a document at the end. You are building it as you go: the opportunity and its gates, the scores, the redesigned work, the contract and context map, the tool contracts and the pattern, the evidence, and the operating plan. By the time you walk into a review, the packet is already done.

Sam: That sequencing matters in practice. The teams I see who struggle in review are the ones who treat the packet as a presentation they assemble the night before. It should just be the record of the decisions you already made.

Koko: Exactly. And the one-minute defense is what you pull from that record. Four parts: the outcome, the redesign, the pattern and why nothing higher, and the failure with its control. In one minute you can say all four. If you can't, the design isn't done.

Sam: That fourth one — the failure with its control — is where I think reviews actually turn. If you can name what goes wrong and show you've bounded it, the room relaxes. If you can't, it doesn't matter how clean the rest sounds.

Koko: And the verdict gives you a precise signal about why you're not ready. Three options: advance, revise, or reframe. The rule is simple — a framing failure sends you back to the outcome. A proof failure keeps the design and asks for evidence. Those are different problems and they have different fixes.

Sam: So framing means the problem statement itself is wrong, and revising the architecture isn't going to help because you're solving for the wrong outcome.

Koko: Right. And proof means the design is sound but you haven't shown it works yet. Same destination, different leg of the journey. Now the readiness rubric — seven competencies, four levels, and a threshold. Above the threshold, you are in the game. But there are eight critical-control gates, and any single open gate fails the whole thing regardless of the score.

Sam: That's the part teams consistently underestimate. They hit a strong aggregate score and assume they're through.

Koko: Here's the scenario. Full-marks self-assessment on a procurement case. Every competency at the top level, total well above the threshold. One gate open — the write path has no named approver. Verdict: not ready. Then the same packet, gate closed. Ready. The score did not move. The gate did.

Sam: The score is a health signal, not a lock. The gates are the lock.

Koko: The analogy I keep using: a building inspection. There's a pass mark, and there's a short list of things that fail the building on their own regardless of everything else. A beautiful score does not reopen a fire exit.

Sam: Clear. And once that framing is in your head it's very hard to un-see it. You stop hunting for the average and you start scanning for the open gate.

Koko: That's the instinct to carry forward. And here's the bigger picture: the stable core of this method — the ladder, the gates, the contract, the hook, the evidence, the number — is most of any platform course you will ever take. The platform lens is the rest. Learn the core once, and you've got the skeleton. Everything platform-specific hangs on it.

Sam: That's genuinely true. I've worked across a few different toolchains and the decisions that matter — what level of autonomy, what the failure mode is, what evidence you need — those don't change. The interface does.

Koko: Now the failure mode. And this is the one to close on, because it's the most tempting move in the room. Defending the technology instead of the outcome. Explaining what the model can do. Walking through capability. The room doesn't want any of that.

Sam: The version of this I keep seeing on teams is someone who's genuinely excited about the system they built, and the defense becomes a product demo. And the stakeholders in that room are thinking about risk and accountability, not features.

Koko: What they want to hear is: what changed, why it was redesigned before it was automated, why no more autonomy than this, and what stops it when it is wrong. Those four things. That's the defense.

Sam: And if you've done the work in the earlier stages, those four questions have answers already sitting in the packet.

Koko: Which brings it all the way home. The one line this course leaves you with: workflows decide the path, agents decide part of it, tools do the work, policies bound it, and evidence is what lets anyone sign. That's the whole thing.

Sam: That's a sentence worth having on hand. It covers the architecture, the governance, and the release condition in about fifteen words.

Koko: The scoring model, the prioritization gates, the workflow moves, the full readiness rubric — all of it is on the course page at KokoAI Academy, at koko knows dot A I. Go pick up the tools. You know how to use them. Now go prove it in the room.