Correct the rule behind a case

Open a case and go to its Prevention section. The Governing rule row names the rule that applied: the lesson the case's remedy points at in your lessons store, otherwise the newest prevention package written from the case, otherwise the case's own lesson draft. A case with none of these says so, and the Correct this rule control is disabled until a lesson is drafted.

Write what the rule gets wrong and what it should say, for example: our check only looks back 8 hours, these span 12; widen it to 16. That sentence becomes the change's rationale, kept with it for good.

Where the sentence changes a number the rule contains, RepoOps drafts the new wording without a model, in every field that carries that number. When the sentence is anything else, or names two numbers the rule both contains, it says why and opens the rule's own fields for you to edit. On the desktop app you can instead tick Ask the model to draft the wording: it uses your own Anthropic key, counts against the planner's daily call cap, and the form tells you plainly when no key is configured. The hosted app makes no model call for this. A corrected guard pattern has to compile, or it is refused.

Each proposal shows the rule as it stands and as corrected, word by word, with who proposed it, how the wording was drafted and a digest over the change. Proposals stay on the case, newest first, with a line on its timeline.

Run the backtest lists the past cases in the repository whose decision the corrected rule would change, and puts the rule as it stands beside the rule as corrected: how many cases each fires on, how often those were real incidents, and how well each separates real incidents from false positives. Every past case is predicted only from the cases that opened before it, so its own outcome never feeds its prediction. A resolved case counts as real, a false positive as clean, and an open case is left out. Under ten predictions the panel says there is not enough decided history rather than showing a number.

Only a lesson's guard pattern decides a case. A correction to a rule's wording alone says it decides nothing differently. A prevention package also shows its six validation legs and whether its version meets its promotion criteria; how those legs run is on Verify a remedy before rollout.

A person decides; nothing approves itself, and a machine actor is refused. An approval binds to the rule as it was when the correction was proposed: if the rule changed since, propose again against the rule as it stands.

An approved lesson change is written to the lessons store, which refreshes the lessons block every session reads. An approved change to the case's own lesson becomes its next lesson draft, which the lesson review admits. An approved package change becomes the package's next version as a draft, which takes its validation legs and a second person's review before it reaches anyone, as on Review a lesson and roll out a prevention package. On the desktop a package change is approved on the hosted case, where its versions are minted.

Every decision stays on the proposal with who decided, when, their note and what rolled out, and is said on the case timeline. It is also appended to a hash chain: on the desktop the repository's rule-corrections journal, signed like the other journals; on the hosted app a chain over the case's decisions, each entry's hash covering the one before. A rejection changes no rule and is recorded the same way.