Field note · Doctrine
Reporting absence: why an operations platform should refuse to estimate.
The most useful thing an operations platform can tell you is sometimes that it does not know. Most software is engineered to never say it.
The default behaviour of software is to fill gaps
When a required input is missing, most systems reach for one of three moves: a default value, an interpolation from neighbouring data, or the silent reuse of the last known number. Each move is invisible to the person reading the screen. The dashboard looks complete. The report exports cleanly. Nobody can tell, looking at the output, which numbers stand on measurement and which stand on convenience.
In a consumer product this is a rounding error. In infrastructure operations it is a liability with a delay on it. An operator pricing technical losses against an estimated conductor specification is pricing fiction. A utility reconciling settlement against interpolated consumption is reconciling against a guess. A statistician publishing an indicator over a silently filled gap is publishing a number that cannot be defended when someone asks, two years later, where it came from.
The two paths a missing input can take. The silent estimate is refused at the database layer, so it can never occupy a measurement field. The absence is recorded with its reason, and the interface reports it as unavailable together with the data age and what would resolve it.
Absence as a first-class value
Our systems treat a missing input the way an accountant treats a missing receipt. The absence is recorded, it has a reason attached, and it blocks the computations that depend on it. Where a figure cannot be computed, the system returns the absence itself: which input is missing, why the computation refuses to proceed, and what would resolve it. The interface renders that state explicitly, and where data is stale it renders the age of the data next to the value, so that a number arriving from a site that last synced days ago is never mistaken for a number from this morning.
The critical design decision is where this is enforced. If the rule lives in the interface, it is a convention, and conventions erode under deadline pressure. We enforce it at the database layer: a derived figure that lacks its required physical basis is a write the database refuses. The application cannot be talked into storing an estimate as a measurement, because the schema itself does not permit the confusion.
What it costs, and what it buys
The honest cost is that our dashboards sometimes say less than a competitor's demo. A screen that shows UNAVAILABLE where a rival shows a confident figure loses the first meeting. We accept that trade, for two reasons.
First, every number the system does show is one the operator can act on and defend, and operators discover quickly which kind of number they are holding. Trust in a system's outputs is not built by density of information. It is built by the absence of surprises.
Second, the gaps themselves become operational information. A site whose telemetry is consistently absent is telling you something about that site. A field team whose captures repeatedly arrive without a required attachment is telling you something about that workflow. When absence is recorded rather than papered over, it can be managed like anything else that is measured.
Where the estimate belongs
None of this is an argument against estimation. Forecasts, projections and inferred values are legitimate and often essential. The discipline is in labelling: an estimate is stored as an estimate, carries its method and its inputs, and is never allowed to silently occupy a field that claims to be a measurement. The moment a system lets those two categories blur, every downstream number inherits the ambiguity, and no amount of dashboard polish gets it back.
