What do you do when a Worker gets it wrong?

Why does this lesson exist?

Because Workers get things wrong, and a product that pretends otherwise is a demo. What matters is what a miss costs you: thirty seconds and a comment, or an afternoon of log archaeology and a support thread.

Everything below is designed for the first one. A Worker you can correct in the moment, with the correction sticking, is a teammate.

How do you work a miss, step by step?

1. Open the run from the case file. Every step on the case file links to the run behind it: what the Worker read, what it changed, which Playbook rules applied, which decisions it grounded itself on, and what it cost. You start from evidence, not a guess.
2. Read what the reviewer discarded. Proctor considers far more than it posts. The findings it dismissed sit one click behind the review, each with its reason. A quiet review you can check is worth something; a quiet review you cannot is not.
3. Correct it where the work is. Answer on the case file, in the pull request, or in the Slack thread the Team is already using. The correction lands in the current item immediately, and the next step reads it.
4. Let the correction become a rule. If it should outlive this item, the Team proposes it as a Playbook rule. A proposed rule is already active; you adopt it in Settings to settle it, or dismiss it if you meant it only this once.
5. Retry a failed run. A provider outage or a flaky sandbox is a retry button, not a support ticket. The run resumes from the last settled step with the same context, and the failure stays on the record.
6. Lower a rung, or ask @yagni. If the record no longer supports the trust you granted, demote the Engagement. And when you want a step explained rather than fixed, ask @yagni in the rail beside the case file: it knows the item, the Team, and the decisions behind it.

What makes a correction stick?

Where it lands. A correction typed into a chat window is a message. A correction on the case file or the pull request is part of the item’s record, so the next run reads it as context and the review reads it as a constraint.

That is also why corrections are worth making carefully. They are the raw material of both the Playbook and the track record a promotion cites.

When should you lower a rung?

When the pattern, not the incident, has changed. One bad plan from an Engagement with fifty good ones is a comment. Three in two weeks is a demotion.

You never have to remember the worst case: reversing something an Engagement shipped on its own lowers it one rung automatically, and the reversal goes on the record. Merges and irreversible acts were gated anyway, at every rung.

What if it keeps getting the same thing wrong?

Then the rule is missing, not the intelligence. Look at what the run read before it worked: if the answer was never written down anywhere, the Worker was guessing in good faith. Write the rule in plain words, scope it to the repository or path where it applies, and the next plan starts from it. That is the loop the whole product runs on, and the Brief will tell you the morning it holds.