A why-chain written for a fixed defect reads as a plausible story. How do you tell which links were shown and which were asserted?

## Plausibility is a property of the writing A causal chain written after a defect is fixed is a piece of prose, and prose can be fluent without being true. Every link reads as though it follows from the one above it, because the person who wrote it chose words that make it follow. Nothing in the fluency of the sentence tells you whether anyone looked at anything. This is the failure mode of the technique in ordinary use: not a chain that is wrong on its face, but a chain that is **a story about the defect assembled from what people already believed**, sitting in the record where an explanation should be. The repair is mechanical. A chain is a set of independent claims that happen to be written in a column, so audit them one at a time and ignore how the column reads as a whole. ## Signatures of an asserted link None of these proves a link is false. Each one means nobody has shown it is true. - **Agentless, passive phrasing.** *The validation was missed*, *the value got out of sync*. There is no actor, so there is nothing to go and observe. - **A jump in granularity.** Two links describe a specific value in a specific request and the third says *the design was not fit for purpose*. The jump is where the evidence ran out. - **A motive rather than a state.** *The developer assumed the field was always present* describes what someone was thinking. What can be shown is what the code did and what the data contained. - **Underivable from anything but the report.** If the whole chain could have been written from the defect record's title without opening a single piece of evidence, it adds nothing that was not already assumed. - **Unfalsifiable as written.** Ask what would be different if the link were false. If the answer is *nothing observable*, the link is decoration. - **Agreement offered as support.** *Everyone agreed that is what happened.* A whole room can share one guess, and often does, because they all read the same report. ## What each kind of link needs | The link claims | Kind | What shows it | What does not | | --- | --- | --- | --- | | this condition produced the failure | behavioural | a reproduction with the condition present, and one with it removed | it was the only unusual condition anyone noticed | | the condition was present in that build | state | the data or configuration as it actually stood at the time | someone remembering that it was | | the check did not catch it | detection | the inputs that check ran on and the result it returned | the check exists and the defect escaped anyway | | the change introduced it | timing | the change history, and the failure reproduced either side of it | the change landed shortly before the report | The table is the whole discipline. **Different claims need different evidence**, and the commonest mistake is offering a state fact in support of a behavioural claim: knowing the odd value was in the data does not show it produced the failure until something has been run with and without it. ## Two tests that settle a link 1. **The counterfactual test.** *If this link were false, what would we have seen instead?* A link with a concrete answer can be checked, and often the check takes minutes. A link with no answer cannot be checked by anyone, ever, and should not carry weight in the conclusion. 2. **The pointing test.** *Who can show me the thing that says this is true, right now?* Not who believes it. Something that exists — a reproduction, an extract of the data as it stood, a recorded result, a change history — and a person who can put it on the screen. ## What to do with a link you cannot evidence Do not delete it and do not quietly keep it. **Convert it into an open question with an owner and a way to settle it**: the reproduction to attempt, the extract to pull, the history to read. The written outcome then says exactly what is known and what is assumed, and a reader six months later can tell the difference. A chain of two verified links and one marked open question is far more useful than four links that read beautifully, because the next person knows where to push. ## The cost of a chain that reads well An unevidenced chain does not fail loudly. It fails as a fix that does not stop the defect recurring; as a second report the explanation cannot account for; as engineering time spent hardening the part of the product that happened to be nearest the writer's guess. Then the same defect is relitigated from the beginning, usually by different people, and the earlier analysis is worse than useless because it anchors them. That rework is the real cost, and it reliably exceeds the hour that pulling the evidence would have taken while everyone still remembered the details.