Reference · Review a lesson and roll out a prevention package
Review a lesson and roll out a prevention package
A lesson becomes a prevention package: one id, immutable versions, a hash over the content, and a rollout state kept apart from the content. Nothing written by a model publishes itself, and nothing reaches a session that a second person did not approve.
1. Write the package from a verified case
On a resolved case with a confirmed cause and a verified remedy, an owner or admin writes version 1 of a package: the incident it came from, the cause in plain words, the remedy's pull request and digest, the scope (the repository, a service, files, tasks), the explanation, a safe alternative, prerequisites, exceptions, a reproducer pointer, guard pointers, an owner and an expiry. Restricted evidence, a transcript for instance, is a reference the reader resolves through its own grant; the package never carries it.
A version is never edited. A change is version 2, and version 1 keeps its hash and its history.
2. Set the criteria before the results
While the package is a draft, write the promotion criteria: the least reviewed legitimate executions a control set needs, the most false positives it may show against them, the least held-out cases, the least detection on them, the least observed sessions. Once a candidate has been evaluated against them, the criteria are fixed; a number chosen after seeing the results is not a criterion.
3. Run the six legs
Reproduce on the defective revision, verify on the fixed one, detect with the proposed guard, legitimate controls, held-out variants, and the observation in a later session. Each run is bound to the version's content hash and names the code, guard and dataset digests it ran against. A runner that timed out, was denied the network or crashed is an infrastructure error; output that would not read is inconclusive; trials that answered both ways are flaky. None of those is a pass and none is dropped from the record. A reproducer that targets production is refused; a safe fixture reproduces an exploit.
4. A second person reviews
The reviewer is a person, and neither the package's owner nor whoever wrote the version. The approval binds to the hash the reviewer read; a later version starts unreviewed. A rejection or a request for revision returns the version to draft with the note on the move.
5. Pilot, then publish
A pilot names its repositories or devices and is warn-only unless the package is already a required control, which is not withheld to run an experiment. Publication needs the approval bound to this hash. A published package may be suspended with a reason and resumed only while the newest control run is under the false-positive threshold; revocation is terminal and names its reason, and a fix is a new version.
6. Delivery and the next session
A bound device pulls the delta after its durable cursor, stages each version atomically, keeps the curated block in the repository's instruction files without overwriting an edit a person made inside it, and acknowledges delivered and installed by exact version and hash. The next session reads the staged manifest into context and leaves a retrieval receipt; a session with no manifest is told its package protection is unverified, not present. Offline, the device keeps its last authorized manifest and shows it as stale past the policy's age.
7. Read the outcome in its denominators
The ledger reports delivered to N of M targeted devices, executed in N of M eligible sessions, the six guard outcomes as they were executed, a reviewer's false-positive label beside the execution it labels, and a matching recurrence with the failure mode a reviewer assigned. A quiet window with no capture reads unknown. How each home draws that line is on No data is not no incidents; the verification a remedy needs before any of this starts is on Verified recovery.
Last updated