Estimates Dressed as Measurements
A 3D printer ran overnight. Its display sat at 35% for over an hour. Not 34%, not 36% — just 35%, perfectly still, while every debugging instinct said stalled print.
Pulling the real telemetry told a different story: the printer's file-position counter was advancing the entire time. The print wasn't stuck. It was nearly half done and running ahead of schedule.
Nothing was broken. The display was never showing a measurement in the first place — it was rendering the slicer's time-based estimates. The counter underneath shows actual bytes of G-code consumed. Two different metrics wearing the same "%" sign.
The Failure Mode Isn't Estimating
Estimates are fine. Estimates are useful. The failure mode is an estimate rendered without its source. It looks like a measurement, so everyone — including you, at 3AM, under pressure — treats it as one.
You've met this pattern before:
- Dashboards "on track" because they compare against plan dates, not delivered work.
- Queues showing "processing" because a heartbeat exists — even when nothing is dequeuing.
- Progress bars that are really just optimism with decimal places.
- "Container Up" reported as service health while the process inside is crash-looping.
In each case the number isn't wrong. It's answering a different question than the one you think you're asking.
Derived vs. Ground Truth
Every telemetry value is one of two things:
Ground truth reads the state of the world directly: bytes consumed, rows written, requests served, current flowing. It costs something to collect, so systems often don't expose it prominently.
Derived values are computed from plans, models, or adjacent signals: estimated completion, predicted arrival, "health" scores, progress percentages. They're cheap, smooth, and human-friendly — which is exactly why frontends love them.
The display in the printer story was derived twice over: the slicer estimated completion times from its own simulation, embedded them as tags in the G-code, and the printer displayed those tags as progress. Nobody lied at any step. The chain just quietly replaced a measurement with an estimate and kept the same icon.
The Question That Saves You
When something looks stuck, don't ask "why did it stop?"
Ask: "what exactly is this number counting?"
Half your false alarms are a derived value standing in front of a ground-truth value one layer down. The layer is always reachable — the counter under the progress bar, the consumer lag under the queue depth, the socket status under the "connected" flag. The discipline is remembering to descend before reacting.
This matters double for automation. A human glances at a frozen 35%, frowns, and maybe checks again later. An alerting rule — or an AI agent watching on your behalf — sees a threshold breach and acts: pages someone, restarts a service, kills a healthy job. Derived metrics plus automated response equals a machine that confidently intervenes on fiction.
A Field Guide
- Label your own dashboards. Every metric is either MEASURED or ESTIMATED. If you can't label it, you don't know what it counts — that's the finding.
- Trace alarms to their sensor. Before acting on any alert, identify the source value. If the chain has a model or a plan in it, the alarm is a hypothesis, not a fact.
- Prefer the ugly number. Ground truth is often awkward — byte counters, log offsets, monotonic sequence numbers. The awkward number that can't be flattered beats the smooth one that can.
- Never automate a response to a derived metric. Automate on ground truth; let humans (or slower, deliberate agents) reconcile the difference.
- Audit the path, not just the value. The printer's display became trustworthy the moment the watcher started reading the byte counter directly. Same data domain, different layer, different world.
Takeaway
The print finished early that morning. The display had said 35% for an hour while the actual work ran at 49% and climbing. No alert was sent, nobody was woken, and the only permanent damage was to the display's credibility.
Your systems are full of numbers that look like measurements and aren't. Before the next 3AM decision — yours or your automation's — ask what the number is actually counting. The answer is one layer down, and it's usually the cheapest debugging you'll ever do.