Sensor family 09
Evolution
“Does this look like changes that caused trouble before?”
What belongs here
These sensors read history rather than the current artifact. They are retrospective and statistical — they answer “does this look like changes that caused trouble before?” and can never be a verdict on one specific change.
Contested placements
DORA Metrics describe the delivery system rather than the software, and Incident Correlation overlaps Runtime. Everything here is a base rate: useful for directing attention, useless as proof.
Where its signals arrive
- User outcome — Outcome stage. Does the system produce the intended result for users?
The atlas places every family on the same lifecycle grid; the framework defines the six dimensions each entry below is characterized along.
Entries (5)
Change Coupling
Which files repeatedly change together? A sensor of hidden coupling — the repository itself becomes a sensor, no code reading required.
DORA Metrics
Change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate.
Incident Correlation
Which components correlate with production failures? A sensor of operational risk concentration, measured from observability events.
Revert Rate
How often does this area get reverted? A black-box sensor of maintainability — you don’t need to understand FooManagerFactoryImpl, you can observe: 27 changes in six months, 8 reverts, 4 incidents…
Time-to-Repair
When this component breaks, how long does it take to restore? A sensor of maintainability measured in hours, not in subjective assessment.
Adjacent families
- Previous: Architecture — Is the system becoming harder to reason about?
- Next: Human Comprehension — Can another observer understand and challenge this?
- All of them: the complete catalog (this family is also anchored there at /catalog/#evolution).