# 3.6 The three failures (/ai-worker-paradigm/the-10-80-10-operating-rhythm/three-failures) --- type: Document title: "3.6 The three failures" description: "The three ways the rhythm breaks, and three questions that show where to look first when delegated work goes wrong." status: stable order: 103.6 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-10-28T12:13:01Z chapter: "03" part: I expert_status: required concepts: [ "3.6" ] last_verified: 2026-10-04 generated: at: 2026-10-28T12:13:01Z by: process:panaversity trust_tier: unverified build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e dirty: true ksor_version: 0.0.60 --- **In everyday life.** A dinner party can go wrong in three ways. Nobody told the cook about a guest's allergy, so the cook had no brief: the first 10 was skipped. You stood over the cook all evening, doing too much in the middle: the 80 was micromanaged. Nobody tasted the sauce before serving it: the last 10 was skipped. Each failure belongs to one part of the rhythm, and each has its own fix. Brightline's October 1, the day in this chapter's story, showed all three. | Failure | What it looks like | Why people do it | What it costs | The fix | | --- | --- | --- | --- | --- | | **Skipping the first 10** | A one-line request. No period, no limits, no stop rule, no evidence asked for | It feels faster. It is the habit of the chatbot era | The wrong result, or the right one reached in the wrong way. The time saved at the start is lost doing the work again | Write the four parts and the five review questions, and question the plan before the run. Save a setup you will reuse as standing instructions | | **Micromanaging the 80** | Approving every harmless step, feeding work in one item at a time, retyping drafts, steering each step | Low trust, often after one bad result | You end up doing the work by hand again, and paying for the worker too | Move the worry into the first 10: a stop rule, narrower authority, a smaller first task, or a dry run | | **Skipping the last 10** | Accepting "Completed", forwarding work unread, approving because it looks professional. For a worker that runs alone: never reading the batch, or taking an empty queue as a quiet night | The output looks finished, and there is a lot of it | Often the costliest, because unchecked errors reach vendors, customers or the accounting records under your name | Read the flags first, clear the approval queue, spot-check by risk. A named person approves, and nothing leaves before that | Each failure also leaves a sign you can spot afterward: - **The worker did what you said, not what you meant.** That points to the first 10: the brief left something out. - **The result was right, but it took as long as doing it yourself.** That points to the middle 80: you did part of the worker's job. - **The warning was in the output, and nobody saw it.** That points to the final 10: the evidence was there, and the review skipped it. ### Maria's mistake: caution in the wrong place Maria, the office manager, shows the second failure. She used the worker to build the invoice register for Friday's payments. She did not trust it, so she approved every step by hand. It took her 90 minutes, and doing the job by hand takes about 75. Her caution was not wrong. Money was at risk, and three days earlier, on Monday, September 28, a fake email had almost tricked the company. **Her mistake was where she put the caution.** It belonged in the first 10 percent, in two places. A stop rule in the brief, such as "ask me before adding any invoice over $5,000", gives the same protection on every run. And a dry run on last week's invoices, before the real work starts, would have shown her whether the worker deserved her trust at all (see [Lesson 3.2](first-10-percent.md)). Either one protects the money, and neither makes her do the work twice. ### Where to look first When delegated work goes wrong, find which of the three parts broke before you fix anything. Fixing the wrong part is common: people retrain the worker when the brief was vague, or rewrite the brief when nobody read the evidence. Ask three questions, in order. 1. **Did the specification say it?** Check everything the worker was given: the brief, the standing instructions, the knowledge, the Role Contract, and any company policy. If none of them told it the period (which month), the limit or when to stop, start with the first 10 percent. Fix the part of the specification the line belongs in, and keep the case as a test (see [Lesson 3.2](first-10-percent.md)). 2. **Did the worker act against it?** If the worker went beyond what it was allowed, or did not stop when a rule applied, start with the middle. Look at the worker's record of the run, and at its inputs and permissions. And ask a second question: *could* the worker break the limit? If it could, the limit was only written down, not enforced. Fix the permission as well (see [Lesson 3.3](middle-80-percent.md)). Chapter 11 teaches this diagnosis in depth. 3. **Was the problem visible in the evidence?** If the warning was there and nobody read it, start with the final 10: fix the review, not the worker. If the problem was not visible, find out why. The review contract may have asked for too little evidence (a first-10 fix). The worker may have left out evidence it was asked for (a middle-80 fix). Or a source may have been wrong (a fix to the inputs). Failures can combine, so treat the answer as the first place to look, not the only one. ![A decision flow titled "When delegation goes wrong: where to look first". Three questions, asked in order, guide the investigation, and failures can combine. From "A delegation went wrong", question 1 asks "Did the specification cover it?" It means the brief, instructions, knowledge, Role Contract and policy. No leads to "First 10% · Setup gap". Fix the relevant part of the specification, keep the case as a test, then rerun. Its example is Dave's 9 a.m. one-line request. Yes leads to question 2, "Did the worker act against it?", meaning it went beyond its authority or did not stop. Yes leads to "Middle 80% · Execution gap". Look at the run record, the inputs and the permissions. Repair the enforcement wherever a forbidden action was possible. No leads to question 3, "Was the problem visible in the evidence?", such as a flag, a cited source or the reconciliation total. Yes leads to "Final 10% · Review gap". Improve the review, with flags first, the approval queue, checks by risk, and the totals. Its example is Dave's 4 p.m. unread flag. No leads to "Why was the evidence missing?" If it was not asked for, look at the review contract and the setup. If it was asked for but left out, look at the worker. If a source was wrong, look at the inputs and how sources were chosen. A side panel reads "Also check the time cost". It describes a correct output that saved little or no time. Too much steering can move the work back to the person, so look at the interruptions and the rework. Clearer stop rules, a dry run and narrower authority mean fewer interruptions are needed. Its example is Maria's 11 a.m. register, 90 minutes instead of 75. A second panel, "A starting point, not a verdict", says the questions show the first place to look, so check for other failures too. A banner reads: "Locate the failure, repair its cause, and test again."](./img/which-part-broke.png) *Figure 3.12. Where to look first. Three questions, asked in order, point to the first place to investigate. One failure shows up as lost time, not errors, and the questions miss it.* ```yaml interactive="gates" title: Which part broke? intro: Pick one of October 1's three failures, and watch where the three questions point. requestsLabel: October 1 checksLabel: The three questions, in order checks: - ask: Did the specification say it? - ask: Did the worker act against it? - ask: Was the problem visible in the evidence? requests: - label: "9 a.m.: Dave's one-line request" results: - status: stop note: No. Nothing told the worker that this task must change nothing. verdict: First 10 percent tone: warn outcome: Start with the first 10 percent. Fix the part of the specification the line belongs in, and keep the case as a test. - label: "11 a.m.: Maria's register" results: - status: pass note: Nothing was missing. The register was correct. - status: pass note: No. The worker did nothing wrong. - status: pass note: No. There was no problem to see. verdict: Middle 80 percent tone: plain outcome: "The three questions miss this one, because the register was correct. It shows up as lost time: 90 minutes for a job that takes about 75 by hand. Look at what Maria did during the middle." - label: "4 p.m.: Dave's second run" results: - status: pass note: Yes. Dave said which month to reconcile, and told the worker to change nothing. - status: pass note: No. The worker flagged the line with the typing error, just as a worker should. - status: stop note: Yes. The flag was in the evidence the worker brought back. Nobody read it. verdict: Final 10 percent tone: warn outcome: "Start with the final 10 percent. Fix the review, not the worker: nobody had a set time to read the worker's flags." ``` > [!IMPORTANT] > **The three failures at Brightline** > > At 9 a.m. Dave gave the worker a one-line request. The table he got back was a **first-10 failure**: nothing told the worker that this task must change nothing. > > At 11 a.m. Maria's register was a **middle-80 failure**, caused by the person rather than the worker. The three questions would not find it, because her register was correct. This failure shows up as lost time, not as errors. If a delegated task takes you as long as doing it by hand, look at what you did during the middle. > > At 4 p.m. Dave approved the reconciliation and attached it to the month-end close, the paperwork that closes September's accounts, without reading it. The worker had flagged a typing error in the register, and Friday's payment later underpaid the vendor by $270. That was a **final-10 failure**. The worker did its job, and the reviewer did not. > > None of Brightline's three failures was the worker's. All three came from how people briefed, watched or reviewed. That will not always be true: workers do make mistakes, which is why question 2 exists. But it is the right place to start, because the parts people own are the parts people can fix today.