Wrong logic
The code compiles, type-checks, and has the right shape. It still returns the wrong answer. Anything that only looks at structure cannot see this.
0 misread11 close
The Framework
What does a passing type check, a green test suite, or 90% coverage actually prove about the code, and what is it mistaken for proving? Removing doubt is the job every sensor in the catalog does, and each one removes a different doubt. This page names 19 of them and maps every sensor onto them.
No sensor in the catalog measures correctness. Each one answers a narrower question, and the composition rule says how those answers add up: not by counting green checks, but by ruling out specific ways the software could be wrong, one at a time. A check that rules out nothing new adds nothing, however green it is.
A doubt is one specific way the software could be wrong. The logic is wrong even though it compiles. The tests ran the code but asserted nothing about the result. The change altered something nobody meant to touch. For each doubt, the page asks three questions of every sensor. Does a clean result from this sensor close the doubt, for what the sensor was pointed at? Does it only reveal the doubt after the fact, once the damage has reached production? Or is its clean result commonly misread as closing the doubt when it does not?
The doubts come first. Then a graph that draws all three answers at once, then the same edges laid out by sensor for when you arrive with a tool in mind, and last, where the vocabulary came from.
The code compiles, type-checks, and has the right shape. It still returns the wrong answer. Anything that only looks at structure cannot see this.
0 misread11 close
The tests ran this code, so coverage says it is tested. But no test checked the result, so a wrong result would pass too.
4 misread1 close
Production tells you what happened: this request took 80ms and returned 200. Nothing tells you whether 200 was the right answer.
1 misread3 close
Every check you wrote passes. The bug is in something nobody thought to write a check for, so no check can fail.
10 misread0 close2 reveal
The check passes, and the check is wrong. The proof, invariant, or snapshot describes what the author believed the system should do, and the author was mistaken.
6 misread3 close1 reveal
The feature was never built. There is no code to test, mutate, or watch, so every sensor stays quiet about it.
2 misread2 close1 reveal
Every piece passes on its own. The bug only appears when the pieces are wired together and talk to each other.
2 misread3 close
It works with the traffic, data, and failures you tried. Production has different traffic, different data, and failures you did not try.
3 misread2 close1 reveal
The sensor checks the code against something else: a second implementation, a mock, the old version, another AI model. If that other thing has the same bug, the two agree and the sensor reads green.
1 misread1 close
The damage shows up after you stopped watching. A two-week experiment cannot see the users who leave in month three.
2 misread0 close4 reveal
A call site and the thing it calls disagree: wrong type, wrong field name, a shape the schema does not allow. The program is at war with itself before it runs.
0 misread4 close
The output moved and nobody meant it to. The change was supposed to touch one thing and it touched another.
1 misread4 close
No test executes this code at all. Whatever it does, the suite has never seen it happen. The rung below unasserted execution.
0 misread2 close
It worked on the laptop and in CI. In the target environment a config value is missing, a port is wrong, or the service never comes up.
1 misread2 close
Everything works while every dependency is healthy. When one of them is slow or dead, the system does not degrade, it collapses.
0 misread2 close
It is correct at ten requests a second. At a thousand it times out, runs out of memory, or falls behind and never catches up.
0 misread1 close
Modules were meant to be separate. Whether they still are, and which ones lean on which, is not something anyone can see without a map.
0 misread5 close
Trouble is not evenly spread. A few files or services cause most of the reverts and incidents, and nobody has looked at which ones.
0 misread3 close
The code is this way for a reason, and the reason is not written anywhere a newcomer can reach. The docs describe a different system.
0 misread3 close
Doubts in the middle, sensors on either side. Hover or click a doubt above, or anything in the graph, to isolate it.
The misread edge is deliberately narrow. Every sensor that does not close a doubt leaves it open, which is nearly the whole catalog for any one doubt and not worth drawing. What the dashed edges mark is the specific mistake: 90% coverage taken as tested, a green canary taken as a safe release, "formally proven" taken as correct. That is the misreading each entry's "What it cannot detect" section was written to head off.
A solid edge does not mean the sensor settles the doubt outright. It settles it only for what the sensor was pointed at. A proof rules out wrong logic for the property someone wrote down, and for nothing else. A test rules it out for the examples it was given. A canary rules out an unsafe release for the metrics it compares. Outside that, the doubt is still open. That is the composition rule in one sentence, and it is why two sensors that close the same doubt count once.
Retrospective sensors get their own edge. Escaped defect rate cannot close late effects before shipping; it is the sensor that shows, months later, that the doubt was real. The catalog's predictive versus retrospective dimension is the same distinction.
The doubts are not the families under another name. If each family closed one doubt and no other, this page would be the catalog page again. Instead the edges cut across the families. Unasserted execution splits one family: the coverage sensors are misread as closing it, and mutation testing, in the same family, closes it. Wrong specification draws its closers from two families and its misreadings from three. Three doubts, nobody knows where the coupling is, nobody knows where the risk sits and nobody can find out why, are about the codebase's future rather than its correctness, and they are what the evolution and comprehension families exist for.
Two doubts are nearly unclosable from inside the catalog. Missing behavior and wrong specification both end at human review and outcome sensors. And wrong logic has an empty left side: nobody reads a clean compile or type check as correct code. The belief engineers actually hold is that a class of bugs is gone, which is true.
The same edges, one row per sensor. Each doubt links back to its card.
Ten of the doubts were mined from the "What it cannot detect" section of every entry, which is where the catalog names what it leaves open. That method finds the catalog's residue, not its coverage: a doubt the catalog closes well never appears there, because no entry is worse at it than the sensor that owns it. The other nine came from asking every sensor the first pass left with nothing to close what it does close.
Every edge was then stated as a plain assertion, "most engineers think a passing X shows Y" or "X ensures Y", and judged true, partly true, or false by reviewers who saw only the assertion. The false ones were removed, and they were mostly misreadings: the reviewers' repeated finding was that engineers know what a compiler does not prove. No closing edge was judged fully true.