About
An open reference for the signals software emits — not "code quality metrics," but epistemic sensors: measurement instruments pointed at different failure modes.
Software is increasingly an opaque artifact. We cannot — and increasingly do not want to — fully understand every implementation. Code is produced by agents, by teams we'll never meet, by systems that span services we don't own. The question is no longer "is this code good?" The question is: what independent observations would cause us to update our belief that this software is correct?
We would not call these "quality metrics." We'd call them epistemic sensors. Their job is to reduce uncertainty about a system that we cannot — or increasingly do not want to — fully understand.
The catalog is organized into eleven families of sensors, each asking a different question about the system. Every sensor is characterized along six dimensions: oracle strength, independence, scope, feedback latency, actionability, and predictive vs retrospective. The atlas arranges them as a navigational matrix — families on one axis, confidence stack layers on the other.
Birgitta Böckeler's "guides & sensors" framing. Sensors are tools that give an agent feedback about what it has done. The interesting frontier is guiding sensors, where the feedback itself tells the agent what to do next.
Honeycomb's conception of observability. Don't merely collect predetermined health metrics; preserve enough information to ask questions you didn't know you would need to ask.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
All content on the Software Observatory is published under CC BY-NC-SA 4.0. You are free to share and adapt the material for non-commercial purposes, provided you give appropriate credit and distribute contributions under the same license.