# 3.4 The final 10 percent: evidence review, correction, approval (/ai-worker-paradigm/the-10-80-10-operating-rhythm/final-10-percent) --- type: Document title: "3.4 The final 10 percent: evidence review, correction, approval" description: "How the final 10 percent reviews the evidence, fixes each problem where it came from, and ends with a person's approval." status: stable order: 103.4 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-10-26T22:26:42Z chapter: "03" part: I expert_status: required concepts: [ "3.4" ] last_verified: 2026-10-04 generated: at: 2026-10-26T22:26:42Z by: process:panaversity trust_tier: unverified build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e dirty: true ksor_version: 0.0.60 --- **In everyday life.** A contractor says the bathroom is done. You turn on every tap and check under the sink before you pay, rather than taking "done" as proof. With the contractor, "done" is the status, and the taps and the sink are the evidence you check. The final 10 percent starts with one rule: **a finished run is not a correct run.** "Completed" means the worker stopped without crashing. It says nothing about whether the numbers are right. Dave ran the reconciliation of Midwest Packaging's statement again at 4 p.m. The run was complete, and it even contained the warning he needed: the worker had flagged one register line with a typing error. Dave read the status, skipped the evidence, and approved. The flagged line stayed wrong in the register, and Friday's payment, made from the register, underpaid the vendor by $270. The final 10 percent has three steps: review the evidence, correct, and approve. ### 1. Review the evidence Check the output against the review contract you wrote in the first 10 percent. Work through it in this order. - **Read the flags first.** A flag is the worker telling you where it was unsure, or where a stop rule applied. The warning in Dave's run was a flag. Reading it would have taken a minute and saved $270. - **Clear the approval queue.** Each item waiting there is something the worker was not allowed to do alone: a recommended entry, a drafted reply. Approve it or send it back under your own name. Read each one. An approval you click through without reading is not a review. - **Spot-check the rest, by risk.** Review every critical item and every exception. Then check a sample of the ordinary ones, and take a bigger sample where a mistake would cost more. As a kind of task builds a clean record, the sample can shrink, but it never reaches zero. For each item you check, open the evidence the worker cites, such as the invoice or the statement line, and confirm it says what the worker claims. - **Check the one number.** If the review contract has a success test, apply it. For Dave's reconciliation, do the explained differences add up to the whole gap? If not, the work is not done, however good it looks. The order matters. Flags and the approval queue are where the worker has already told you to look, so they are the cheapest places to find a problem. Spot checks are where you look for what it did not tell you. And the one number comes last, because a correction found earlier may change it. ![Diagram titled "A finished run is not proof of a correct run". On the left, under "What Dave read at 4 p.m.", is a run card, "Reconcile Midwest's September statement", with a green "Completed" badge. A note says the run finished, but that status alone does not show it is correct. A red arrow labeled "Approved based on status" leads to a red box. The wrong line stayed in the register, and Friday's payment underpaid the vendor by $270. The warning was already in the run. On the right, under "Review the evidence, in this order", are four numbered steps. Step 1 is to read the flags first, starting with what the worker was unsure of, mismatches and stop conditions. Beside it, a red flag reads "FLAG: Register line 14 does not match the invoice.", marked "Dave skipped this flag." Step 2 is to review the approval queue, reading each recommendation, and approving or returning each item by name. Step 3 is to check the rest by risk, meaning every critical item and a sample of the others, opening the cited evidence. Step 4 is to reconcile the total. Do the explained differences add up to the whole gap? Below, an amber box reads "Correct the cause". A correction to the output repairs this result, and a correction to the specification or the controls stops it happening again. Keep the case as a test and rerun it. A green box reads "Then approve release, by name". After review, a responsible person allows the work to be sent, filed, paid or published, and for this reconciliation that is Dave. A banner reads: "Read the evidence before approving the work." For a standing worker, also check that the run happened, because silence is not success.](./img/status-vs-evidence.png) *Figure 3.10. Read the evidence, not the status: flags first, then the approval queue, then spot checks and the one number.* ### 2. Correct Decide where each problem came from, and fix it there. - **A small error in the output**, such as a wrong date in one row: fix it in place. - **A problem across the output**, such as every row in the wrong format: send it back to the worker as a revision. - **A problem that came from the setup:** fix the part of the specification it came from, then rerun. The brief did not say which month to reconcile? That is the brief. The worker did not know what a credit note is? That is the knowledge. It read an out-of-date file? That is the inputs. It did something the [Role Contract](../what-is-an-ai-worker/role-contract.md) should never allow? That is the contract. The third kind matters most, because it is the only one that stops the same problem coming back. A correction made only in the output fixes this run. A correction made in the specification fixes every run after it. And when you fix a setup problem, keep the case that exposed it as a test with a known answer. Then the next change to the specification can be checked against it. ### 3. Approve Approval means a named person says yes before the work goes out: before it is sent, filed, paid or published. The authority agreed for the worker says which actions need this. In this chapter's reconciliation, every action that changes something needs it, and the person who approves is Dave. Most approvals happen when you go through the approval queue. The rule is simple. Approve an item only after anything wrong with it has been fixed. Never approve just because its status says "Completed." That was Dave's mistake at 4 p.m. In other work, the worker may be allowed to do routine actions on its own. For this, it needs an approved Authority Envelope, the written limit on what it may do (Chapter 7). Even then, it passes anything unusual to a person, and a person checks its work regularly. In every case, a person decides what the work is for, what the worker may do, and how the work is checked. Approval is not just a click at the end. When you approve, you accept responsibility for the work. ### When the worker runs without you For a standing worker, the final 10 percent does not follow each run. It happens at times you choose, such as Dave's 9 a.m. check each morning (Figure 3.2). The three steps are the same. Two things are different. First, **review whole batches, not single runs.** At 9 a.m. Dave reads every flag raised since yesterday, clears everything in the approval queue, and spot-checks a sample of the rows that went through with no flag at all. That last part is easy to skip, and it matters most. A worker that never raises a flag is either doing perfect work or not noticing its mistakes. Only a spot check tells you which. Second, **silence is not success.** A run that never started raises no flag, and an empty queue looks exactly like a quiet night. So at 9 a.m., Dave also checks that the work happened: did Monday's register run, and did it cover every invoice that arrived? A missing run is a failure too, and it is the one that is easiest to miss. ### Why the review contract keeps this part short With a review contract, you check evidence that was gathered for you, and that takes minutes. Without one, you redo the work to find out whether it was right, and that takes as long as doing it. Delegating saves you time and money mostly because of that difference. Remember Maria in [Lesson 3.3](middle-80-percent.md), who spent 90 minutes on a 75-minute job. She lost her time during the work. Without evidence, you lose your time after the work. You must do the job again to know if it is right. > [!TIP] > **The same correction twice** > > The final 10 percent also feeds the next first 10. A correction you make twice is a signal to diagnose, which means to find the cause. Often the cause is a gap in the specification: a missing line in the instructions, a missing fact in the knowledge, or a missing limit in the Role Contract. But it can also be bad data, a broken tool or an unreliable worker. Fix the cause, keep the case as a test, and the next run needs less review.