A Green Check Is Not Learning Until the Next Run Reads It

• A current PASS proves one input passed; it does not prove that a later run used a lesson from an earlier failure.
• The minimum receipt chain is failed bytes, one bounded edit, a held-out result, the current hash, and a next-run read status.
• A pinned SkillOpt-Sleep mock run moved held-out evaluation from 0.3333 to 1.0 and blocked a harmful edit.
• That is evidence for a fixed mock acceptance contract, not a production-quality, revenue, or intelligence measurement.

The nightly log ends in PASS. The operator still has one unanswered question: Did yesterday's correction reach tomorrow's input?

That distinction is the whole job of an evidence chain. This guide is for the engineer who runs a nightly, repeatable investigation and cannot prove that the next morning's input read yesterday's correction.

Three states a green check cannot prove

Rewrite means a document or setting changed. It proves only that bytes changed.

Current PASS means the current input passed its check. It proves only that check's verdict for those bytes.

Auditable learning keeps the failure, edit, evaluation, hash, and next-run read receipt together. It can show that an accepted change reached the later execution.

Do not use the third label when only the first two receipts exist.

How to prove five receipts reach the next run

1. Preserve the failure bytes

Keep the failed input, question, score, or post-run measurement. Keep the document or configuration bytes that produced it. Add the failure classification and one run identity.

A score without its input cannot tell you what was corrected. Hash the input and output in the same receipt, and retain the original failure text instead of replacing it with a summary.

2. Make one bounded edit

Change one bounded part: an addition, deletion, or replacement. Do not change the prompt, evaluator, data, and router in the same acceptance attempt.

Microsoft's SkillOpt README calls a skill document “the trainable state of a frozen agent.” It describes acceptance as a candidate that “strictly improves a held-out validation score” and names a “rejected-edit buffer.” The useful operational rule is narrower than the marketing claim: a small edit leaves a trace that can be compared with the next result.

3. Re-evaluate on held-out work

Do not accept a candidate only on the examples that motivated it. Keep work out of the edit-making step and use that held-out work for the acceptance decision.

If the evaluator cannot return a verdict, or the difference cannot be separated from noise, record unknown. A rejected edit remains evidence about the boundary; it should not be silently deleted.

4. Bind the chain to hashes

Put these fields into linked receipts:

• failure: original failure, classification, input hash
• edit: changed bytes or setting, change hash
• evaluation: initial and held-out result, task version
• decision: accept, reject, or unknown, with the reason
• consume: next-run identity, loaded identifier, current hash, read status

If the current bytes do not match the receipt hash, do not attach an old PASS to the new document. The hash is the boundary that says which bytes were evaluated.

5. Require the next-run read receipt

Writing the accepted version to a ledger is not enough. The next execution must report what it loaded.

```mermaid flowchart TD A[Failure bytes] --> B[Bounded edit] B --> C[Held-out evaluation] C --> D[Current hash] D --> E[Next-run read receipt] C --> F{Accepted?} F -->|No or unknown| G[Keep rejected edit] G --> B ```

The read receipt needs at least four values: next-run identity, stable identifier of the loaded file or setting, current hash at load time, and machine-readable read status. If the evaluator reads path B while the accepted version lives at path A, the evaluation can pass while the lesson never reaches the loop.