# Deviation log — append-only template The deviation log is what makes a frozen method survivable. Methods are wrong sometimes; the discipline is not "never be wrong," it is **"never quietly fix it."** Version 1.0 · 2026-09-09 --- ## The three rules 1. **Nothing above the freeze line is ever edited.** Not typos, not clarifications. If it is wrong, it is wrong in the record and corrected here. 2. **Every entry is timestamped relative to the run** — before it started, during it, or after it ended. This is the credibility axis: a clarification written before the first measurement costs nothing; the same words written afterwards are a different claim. 3. **A verdict produced by the frozen rule is not revised** because the rule turned out to be flawed. Record the flaw, record the true observation beside it, and specify the fix for the next version. ## Entry format ``` **D · ** ( the run) What the method said: … What was actually done: … Why: … Effect on results: … (or "none") Fix for the next version: … (or "none needed") ``` ## Header block ``` Executor: Run ID: Date: Frozen hash: (before / after) ``` --- ## What counts as a deviation — and what does not Distinguishing these keeps the log meaningful. Logging everything dilutes the signal until nobody reads it; logging nothing is the failure it exists to prevent. | Kind | Example | Log it? | |---|---|---| | **Interpretation** — the method was ambiguous and you chose a reading | "Empty rule set" read as "test rules removed", not "file emptied" | **Yes** | | **Operationalisation** — the method named a metric but not how to judge it | Deciding what body content distinguishes a real success | **Yes** | | **Addition** — a field or safeguard the method did not specify | Adding a timeout wrapper; adding a `note` column after the required ones | **Yes** | | **Compliance** — you did exactly what the method said, choosing an unconstrained detail | Picking a free port when the method said "a free port" | **No** — a note at most | | **Product naming** — labels for logs or phases | Naming three configurations A / B / L | **No** | A useful test: *would a reader who only saw the frozen method be surprised by what you did?* Surprise means log it. ## Two entries worth writing well **When the method turns out to be wrong mid-run.** The temptation is to fix the rule and re-score. Do not. Record: the flaw, which cells it affected, what the true observation was, and that **the verdicts were left as the frozen rule produced them**. Then specify the correction for the next version. A study that quietly rescored under a better rule is indistinguishable, from the outside, from one that rescored to get a nicer answer. **When an attempt is aborted and restarted.** The only question a reader has is whether the restart was result-dependent. Answer it explicitly: - what broke (be specific — a bug, not "an issue"); - **whether any result had been looked at when the decision was made** — this is the load-bearing fact; - that the aborted attempt's raw output was kept, and where. A restart decided before any results were seen is ordinary engineering. The same restart decided afterwards is a different act, and no amount of description makes it the first one. ## Closing the log Before publishing, confirm: - [ ] The frozen region hashes to the value recorded before the run. - [ ] Every entry states before / during / after. - [ ] No verdict was revised to match a post-hoc understanding. - [ ] Deviations that were interpretations of the method are distinguished from choices made freely within it. - [ ] Anything the log reveals as a method defect is carried into the next version, not silently dropped.