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 doubts

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

Unasserted execution

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

Unjudged observation

Production tells you what happened: this request took 80ms and returned 200. Nothing tells you whether 200 was the right answer.

1 misread3 close

Unspecified property

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

Wrong specification

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

Missing behavior

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

Emergent failure

Every piece passes on its own. The bug only appears when the pieces are wired together and talk to each other.

2 misread3 close

Untested conditions

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

Correlated blind spot

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

Late effects

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

Not internally consistent

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

Unintended change

The output moved and nobody meant it to. The change was supposed to touch one thing and it touched another.

1 misread4 close

Unreached by tests

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

Does not run where deployed

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

Falls over with a dependency

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

Cannot carry the load

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

Nobody knows where the coupling is

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

Nobody knows where the risk sits

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

Nobody can find out why

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

Every sensor, every doubt

Doubts in the middle, sensors on either side. Hover or click a doubt above, or anything in the graph, to isolate it.

green is misread as closing this doubt closes the doubt before shipping reveals the doubt after the fact dot colour is the family; a sensor is lit on a side only where it has an edge there
Misread as closing it Doubt Closes it, or reveals it after Structural Structural Behavioral Behavioral Test Effectiveness Test Effectiveness Invariants Invariants Adversarial Adversarial Runtime Runtime Change Change Architecture Architecture Evolution Evolution Human Comprehension Human Comprehension No doubt edge No doubt edge Compiler Compiler Contract & Refinement Types Contract & Refinement Types Model Checking Model Checking Schema Validator Schema Validator Static Analysis Static Analysis Theorem Proving Theorem Proving Type Checker Type Checker Contract Tests Contract Tests Example-Based Tests Example-Based Tests Integration Tests Integration Tests Smoke Tests Smoke Tests Snapshot Tests Snapshot Tests Synthetic Monitoring Synthetic Monitoring Branch Coverage Branch Coverage Diff Coverage Diff Coverage Escaped Defect Rate Escaped Defect Rate Line Coverage Line Coverage Mutation Testing Mutation Testing Business Invariants Business Invariants Database Invariants Database Invariants Pre-Promotion Invariant Gates Pre-Promotion Invariant Gates Runtime Invariants Runtime Invariants Statically Checked Invariants Statically Checked Invariants Differential Testing Differential Testing Fault Injection Fault Injection Live Chaos Experiments Live Chaos Experiments Metamorphic Testing Metamorphic Testing Property-Based Testing Property-Based Testing Load Testing Load Testing Observability Events Observability Events A/B Testing A/B Testing API Compatibility API Compatibility Canary Analysis Canary Analysis Error-Budget Impact Error-Budget Impact Shadow Traffic Shadow Traffic Architecture Fitness Functions Architecture Fitness Functions Boundary Sensors Boundary Sensors Dependency Graph Dependency Graph Hotspot Analysis Hotspot Analysis Live Service Graph Discovery Live Service Graph Discovery Change Coupling Change Coupling Incident Correlation Incident Correlation Revert Rate Revert Rate Decision Provenance Decision Provenance Documentation Drift Documentation Drift Independent Review Independent Review Onboarding Experiment Onboarding Experiment Second-Agent Review Second-Agent Review Build Provenance & SBOM Build Provenance & SBOM Continuous Profiling Continuous Profiling DORA Metrics DORA Metrics Distributed Traces Distributed Traces Feature Flag Exposure Telemetry Feature Flag Exposure Telemetry Fuzzing Fuzzing Incremental Build Correctness Incremental Build Correctness Linter Linter Resource Telemetry Resource Telemetry Static Security Analysis Static Security Analysis Time-to-Repair Time-to-Repair Wrong logic0 misread · 11 close Unasserted execution4 misread · 1 close Unjudged observation1 misread · 3 close Unspecified property10 misread · 0 close · 2 reveal Wrong specification6 misread · 3 close · 1 reveal Missing behavior2 misread · 2 close · 1 reveal Emergent failure2 misread · 3 close Untested conditions3 misread · 2 close · 1 reveal Correlated blind spot1 misread · 1 close Late effects2 misread · 0 close · 4 reveal Not internally consistent0 misread · 4 close Unintended change1 misread · 4 close Unreached by tests0 misread · 2 close Does not run where deployed1 misread · 2 close Falls over with a dependency0 misread · 2 close Cannot carry the load0 misread · 1 close Nobody knows where the coupling is0 misread · 5 close Nobody knows where the risk sits0 misread · 3 close Nobody can find out why0 misread · 3 close
The same 59 sensors appear on both sides, grouped by family in the catalog's order. A doubt sits at the average height of the sensors it touches. A doubt with an empty left side is one nothing gets mistaken for. The entries at the bottom have no edge in this vocabulary: some close a doubt it does not yet name, some are raw data that other sensors judge, and some are aggregates with nothing to attribute.

Reading the edges

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.

What the shape says

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.

By sensor

The same edges, one row per sensor. Each doubt links back to its card.

SensorMisread as closingClosesReveals after
Structural
Build Provenance & SBOM
CompilerNot internally consistent
Contract & Refinement TypesUnspecified propertyWrong specificationWrong logic
Linter
Model CheckingWrong specificationWrong logic
Schema ValidatorNot internally consistent
Static AnalysisNot internally consistent
Theorem ProvingWrong specificationWrong logic
Type CheckerNot internally consistent
Behavioral
Contract TestsEmergent failure
Example-Based TestsMissing behaviorEmergent failureUnintended changeWrong logic
Integration TestsDoes not run where deployedEmergent failure
Smoke TestsDoes not run where deployed
Snapshot TestsUnasserted executionWrong specificationUnintended change
Synthetic MonitoringUnspecified propertyDoes not run where deployed
Test Effectiveness
Branch CoverageUnasserted executionUnreached by tests
Diff CoverageUnasserted execution
Escaped Defect RateWrong specificationMissing behaviorLate effects
Line CoverageUnasserted executionUnreached by tests
Mutation TestingMissing behaviorUnasserted execution
Invariants
Business InvariantsUnspecified propertyWrong logicUnjudged observation
Database InvariantsUnjudged observation
Pre-Promotion Invariant GatesUnspecified propertyWrong specificationWrong logic
Runtime InvariantsWrong logicUnjudged observation
Statically Checked InvariantsUnspecified propertyWrong specificationWrong logic
Adversarial
Differential TestingCorrelated blind spotWrong logic
Fault InjectionUnspecified propertyUntested conditionsFalls over with a dependency
Fuzzing
Live Chaos ExperimentsUnspecified propertyUntested conditionsFalls over with a dependency
Metamorphic TestingWrong logic
Property-Based TestingUnspecified propertyWrong logic
Static Security Analysis
Runtime
Continuous Profiling
Distributed Traces
Load TestingUntested conditionsCannot carry the load
Observability EventsUnjudged observationUnspecified propertyUntested conditions
Resource Telemetry
Change
A/B TestingLate effectsWrong specification
API CompatibilityUnintended change
Canary AnalysisUnspecified propertyLate effectsEmergent failureUntested conditionsUnintended change
Error-Budget ImpactLate effects
Feature Flag Exposure Telemetry
Incremental Build Correctness
Shadow TrafficEmergent failureUntested conditionsUnintended change
Architecture
Architecture Fitness FunctionsUnspecified propertyNobody knows where the coupling is
Boundary SensorsNobody knows where the coupling is
Dependency GraphNobody knows where the coupling is
Hotspot AnalysisNobody knows where the risk sits
Live Service Graph DiscoveryNobody knows where the coupling is
Evolution
Change CouplingNobody knows where the coupling is
DORA Metrics
Incident CorrelationNobody knows where the risk sitsUnspecified propertyLate effects
Revert RateNobody knows where the risk sitsLate effects
Time-to-Repair
Human Comprehension
Decision ProvenanceNobody can find out why
Documentation DriftNobody can find out why
Independent ReviewWrong specificationMissing behaviorCorrelated blind spot
Onboarding ExperimentNobody can find out why
Second-Agent ReviewWrong specificationMissing behavior

Where the vocabulary came from

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.