Sensor family 06
Runtime
“What is it actually doing?”
What belongs here
These sensors describe what the system actually did, in the wild, with no expected answer to compare against. They have the weakest oracles in the catalog and the widest scope: they cannot tell you something is wrong, only what happened.
Contested placements
Load Testing is a chosen-input experiment rather than a passive observation and could sit in Behavioral or Adversarial. It is here because what it measures is runtime behaviour under conditions the code cannot see for itself.
Where its signals arrive
- Production behavior — Production stage. What is it actually doing in the real world?
The atlas places every family on the same lifecycle grid; the framework defines the six dimensions each entry below is characterized along.
Entries (5)
Continuous Profiling
Where did computation actually go? Not “CPU is 82%” but “this function consumed 40% of the time in these specific requests.” A sensor of resource reality.
Distributed Traces
What path did this particular operation take? A sensor of execution flow across service boundaries — the span tree is itself a signal.
Load Testing
Does the system behave under the traffic it claims to handle? A load test drives generated requests at a target rate and measures what breaks — latency, errors, throughput — before real users do.
Observability Events
Traditional monitoring says: “CPU is 82%.” Observability says: “Show me the requests that are slow, and let me figure out what those requests have in common.” The distinction is fundamental.
Resource Telemetry
CPU, memory, IO, network, GC, queues. Traditional monitoring — useful but limited. Low cardinality, low dimensionality, predetermined questions. Resource telemetry is the weakest runtime sensor.
Adjacent families
- Previous: Adversarial — Can we make our evidence of correctness fail?
- Next: Change — What did this change actually affect?
- All of them: the complete catalog (this family is also anchored there at /catalog/#runtime).