The Atlas

Sensor Atlas

A navigational map of the sensor landscape. Each row is a sensor family — a question you're asking about the system. Each column is a stage of the software lifecycle — when the signal becomes available, from authoring the code on the left to observing real-world outcomes on the right. For the narrative version of how evidence accumulates, see the confidence stack.

Use the atlas to orient yourself. What question are you asking? Find the row. When can you afford to learn the answer? Find the column. Empty cells are questions nobody instrumented at that stage yet.

Build
Test
Deploy
Production
Outcome
01 Structural
Compiler Contract & Refinement Types Linter Model Checking Schema Validator Static Analysis Theorem Proving Type Checker
Build Provenance & SBOM
02 Behavioral
Contract Tests Example-Based Tests Integration Tests Snapshot Tests
Smoke Tests
Synthetic Monitoring
03 Test Effectiveness
Branch Coverage Diff Coverage Line Coverage Mutation Testing
Escaped Defect Rate
04 Invariants
Statically Checked Invariants
Pre-Promotion Invariant Gates
Database Invariants Runtime Invariants
Business Invariants
05 Adversarial
Static Security Analysis
Differential Testing Fuzzing Metamorphic Testing Property-Based Testing
Fault Injection
Live Chaos Experiments
06 Runtime
Continuous Profiling Distributed Traces Load Testing Observability Events Resource Telemetry
07 Change
Incremental Build Correctness
API Compatibility
Canary Analysis Shadow Traffic
Feature Flag Exposure Telemetry
A/B Testing Error-Budget Impact
08 Architecture
Boundary Sensors Dependency Graph Architecture Fitness Functions Hotspot Analysis
Live Service Graph Discovery
09 Evolution
Change Coupling
DORA Metrics
Incident Correlation Revert Rate Time-to-Repair
10 Human Comprehension
Decision Provenance
Independent Review Second-Agent Review
Documentation Drift
Onboarding Experiment
← What question are you asking? (sensor families)
← earlier / cheaper   |   later / closer to reality →
Lifecycle stages

10 families at a glance

01 Structural "Is this artifact internally coherent?" 02 Behavioral "Does it do what we expect?" 03 Test Effectiveness "Do our tests actually detect failures?" 04 Invariants "What must always be true?" 05 Adversarial "Can we make our evidence of correctness fail?" 06 Runtime "What is it actually doing?" 07 Change "What did this change actually affect?" 08 Architecture "Is the system becoming harder to reason about?" 09 Evolution "Does this look like changes that caused trouble before?" 10 Human Comprehension "Can another observer understand and challenge this?"

How the families lean on each other

Sensor families are not a stack — evidence from one family routinely depends on another family having done its job. Arrows point from the family that leans to the family it leans on, labelled with a sensor that carries the connection. Hover a node to isolate its neighborhood. Drawn from the cross-references inside the catalog entries themselves; only the strongest links are shown.

Family dependency graph Arrows point from the family that leans to the family it leans on. 44 edges shown. See the text list below the graph for the full edge set. behavioral leans on change structural leans on adversarial structural leans on behavioral invariants leans on runtime runtime leans on change adversarial leans on invariants adversarial leans on test-effectiveness structural leans on invariants change leans on evolution change leans on adversarial behavioral leans on invariants test-effectiveness leans on behavioral change leans on test-effectiveness architecture leans on behavioral Contract Tests, Smoke Tests, Synthetic MonitoringSmoke Tests Build Provenance & SBOM, Contract & Refinement Types, Static AnalysisStatic Analysis Build Provenance & SBOM, Contract & Refinement Types, Schema ValidatorSchema Validator Business Invariants, Database Invariants, Runtime InvariantsRuntime Invariants Distributed Traces, Load Testing, Observability EventsLoad Testing Fault Injection, Live Chaos Experiments, Metamorphic TestingFault Injection Fuzzing, Metamorphic Testing, Property-Based TestingFuzzing Model Checking, Theorem Proving, Type CheckerType Checker A/B Testing, Error-Budget ImpactA/B Testing Canary Analysis, Shadow TrafficShadow Traffic Contract Tests, Smoke TestsSmoke Tests Escaped Defect Rate, Mutation TestingMutation Testing A/B TestingA/B Testing Boundary SensorsBoundary Sensors Structural Behavioral Test Effectiveness Invariants Adversarial Runtime Change Architecture Evolution Human Comprehension
Family dependency graph (text)
  • Adversarial leans on Behavioral via: Property-Based Testing
  • Adversarial leans on Change via: Fault Injection
  • Adversarial leans on Invariants via: Fault Injection, Live Chaos Experiments, Metamorphic Testing
  • Adversarial leans on Runtime via: Live Chaos Experiments
  • Adversarial leans on Structural via: Static Security Analysis
  • Adversarial leans on Test Effectiveness via: Fuzzing, Metamorphic Testing, Property-Based Testing
  • Architecture leans on Behavioral via: Boundary Sensors
  • Architecture leans on Change via: Dependency Graph
  • Architecture leans on Evolution via: Hotspot Analysis
  • Architecture leans on Runtime via: Live Service Graph Discovery
  • Architecture leans on Test Effectiveness via: Hotspot Analysis
  • Behavioral leans on Adversarial via: Example-Based Tests
  • Behavioral leans on Change via: Contract Tests, Smoke Tests, Synthetic Monitoring
  • Behavioral leans on Invariants via: Contract Tests, Smoke Tests
  • Behavioral leans on Runtime via: Synthetic Monitoring
  • Behavioral leans on Structural via: Contract Tests
  • Behavioral leans on Test Effectiveness via: Example-Based Tests, Snapshot Tests
  • Change leans on Adversarial via: Canary Analysis, Shadow Traffic
  • Change leans on Behavioral via: API Compatibility, Feature Flag Exposure Telemetry
  • Change leans on Evolution via: A/B Testing, Error-Budget Impact
  • Change leans on Runtime via: Feature Flag Exposure Telemetry
  • Change leans on Structural via: Incremental Build Correctness
  • Change leans on Test Effectiveness via: A/B Testing
  • Evolution leans on Architecture via: Change Coupling
  • Evolution leans on Change via: Revert Rate
  • Evolution leans on Runtime via: Incident Correlation
  • Invariants leans on Adversarial via: Runtime Invariants
  • Invariants leans on Behavioral via: Pre-Promotion Invariant Gates, Runtime Invariants
  • Invariants leans on Change via: Pre-Promotion Invariant Gates
  • Invariants leans on Runtime via: Business Invariants, Database Invariants, Runtime Invariants
  • Invariants leans on Structural via: Runtime Invariants, Statically Checked Invariants
  • Runtime leans on Change via: Distributed Traces, Load Testing, Observability Events
  • Runtime leans on Human Comprehension via: Observability Events
  • Runtime leans on Evolution via: Observability Events
  • Runtime leans on Invariants via: Observability Events
  • Structural leans on Adversarial via: Build Provenance & SBOM, Contract & Refinement Types, Static Analysis
  • Structural leans on Behavioral via: Build Provenance & SBOM, Contract & Refinement Types, Schema Validator
  • Structural leans on Change via: Build Provenance & SBOM
  • Structural leans on Invariants via: Model Checking, Theorem Proving, Type Checker
  • Structural leans on Test Effectiveness via: Type Checker
  • Test Effectiveness leans on Adversarial via: Mutation Testing
  • Test Effectiveness leans on Behavioral via: Escaped Defect Rate, Mutation Testing
  • Test Effectiveness leans on Change via: Diff Coverage
  • Test Effectiveness leans on Evolution via: Escaped Defect Rate