Record the inverse trap, where a correct prediction is thrown away - #86
Conversation
Every trap in this section is over-reach: narrating past an observation, believing a negative a query could not have produced, trusting a tool that exited 0. This one runs the other way, and its remedy is not more caution because caution is what produces it. Checking a claim against measurement and dropping it when the two disagree is the right instinct. What is missing is asking which of the two is more likely to be wrong before assuming it is the prediction. A number derived from first principles that contradicts the world is at least as likely to be a finding about the world. This repository nearly tripped it on 1,052. The figure was derived three ways before any deploy proved it, and the host measured 0 shared inodes across every release for weeks. The tempting reading was that the estimate was wrong; it was exact, and the world was broken, because the restore had never run. Treating the disagreement as a defect rather than as bad arithmetic is what found it. The host tripped it in the other direction on the same mechanism and recorded it there. Kept here because the shape is re-trippable by this repository, which carries several counts that are derived rather than observed. Also removes a duplicate the general form introduced. "A rule naming a target that does not exist" now appears once as a class and once as the dead-pin incident, and the class points at the incident rather than restating it, so a reader meeting the second does not have to work out whether it is a different case. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates the project’s “traps” documentation to record an additional failure mode (“inverse trap”) where a correct derived prediction is prematurely discarded because measurements disagree, and removes a duplicated statement by pointing the general rule at its concrete incident.
Changes:
- Adds a new trap entry describing the “inverse” case where measurement disagreement can indicate an issue with the world/system, not the prediction.
- Reworks the “rule naming a target that does not exist” bullet to avoid duplicating the same example twice, deferring detail to the incident entry.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The reference called its target the "dead-pin trap", a name appearing nowhere, so a reader had nothing to search for. It now quotes the distinctive part of the actual entry, "reads as coverage", which is present once as the trap and once here. Quoting the whole lead phrase was tried first and stutters, since it is also the wording of the reference itself. And a comma after "above", where two clauses ran together. Both found by Copilot review on #86. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ptr727
commented
Aug 9, 2026
Recording the second fix here, since that thread was already resolved when I went to reply to it and the fixing commit would otherwise be written down nowhere.
Fixed in 1c1fdc6, comma added after "above". |
Every trap in that section is a form of over-reach — narrating past an observation, believing a negative a query could not have produced, trusting a tool that exited 0. This one runs the other way, and it came out of the agent channel with the host side supplying the remedy.
Its remedy is not more caution, because caution is what produces it. Checking a claim against measurement and dropping it when the two disagree is the right instinct. What is missing is asking which of the two is more likely to be wrong before assuming it is the prediction. A number derived from first principles that contradicts the world is at least as likely to be a finding about the world.
Why it belongs here rather than only in the host's notes
This repository nearly tripped it on 1,052. The figure was derived three ways before any deploy proved it, and the host measured
0shared inodes across every release for weeks. The tempting reading was that the estimate was wrong.It was exact. The world was broken — the restore had never run. Treating the disagreement as a defect rather than as bad arithmetic is what found it.
The host tripped it in the other direction on the same mechanism, striking a
~670 M for ten releasesfigure as wrong when it had been right all along and had simply never once been true. That instance is recorded there beside its own resolution; the class is kept here because it is re-trippable by this repository, which carries several counts that are derived rather than observed.One duplicate removed
Adding the general form in #82 left "a rule naming a target that does not exist" stated twice — once as a class and once as the dead-pin incident, both with the same example. The class now points at the incident rather than restating it, so a reader meeting the second does not have to work out whether it is a different case. Nothing is deleted; the detail lives once instead of twice.