A Zero Reading Is Different from No Reading

A bin reports zero percent full. Another bin has sent no reading. A third last reported zero yesterday. An operational dashboard can make all three look reassuring if it fills gaps with zero or keeps the last value without its age.

Those displays support different conclusions. A recorded zero is an observation under a particular procedure. Silence is missing evidence. An old zero describes an earlier state. For intelligent public infrastructure, preserving that distinction is a practical foundation for decisions, whether a person, a rules engine, or an AI assistant reads the data.

This essay uses fictional waste-container telemetry to propose an evidence contract. It describes no deployed sensor network, municipal partnership, observed overflow reduction, or model experiment. The accompanying offline reference demonstrates classification rules using synthetic records only.

Describe what the number means

Before discussing freshness, identify the observed property, asset, unit, sensor and procedure. A fill estimate, a collected mass and a completed visit are different observations. None can substitute for another just because they share an asset identifier. A zero fill estimate does not prove that a collection occurred.

The W3C and OGC sensor ontology associates observations with an observed property, a feature of interest and a procedure. That vocabulary provides a useful conceptual starting point; it does not establish whether a particular device is calibrated or its estimate is accurate. The proposal here uses those distinctions without claiming conformance to an ontology implementation. [2]

Keep units explicit. For the fictional example, values are fill percentages between zero and one hundred. A missing value stays absent. A text label, a negative number, or a value beyond the declared range needs validation rather than silent conversion. Zero must survive validation as a legitimate numeric input.

Keep the observation clock separate from arrival

Record when the measurement applies and when the application received it. If a device reconnects and uploads an old observation, receipt is recent while the observed state is old. Measuring age from arrival would make delayed evidence appear current.

SensorThings API 1.1 distinguishes phenomenon time from result-generation time, and also defines optional quality and validity information. Its result-generation timestamp is not automatically an application's receipt timestamp. The application needs to preserve its own receipt boundary when that distinction matters. [1]

There is another subtlety: the API specifies a server-time default when a submitted observation omits phenomenon time. A timestamp's presence therefore cannot, on its own, establish that a device supplied the measurement time. Preserve whether the time was measured, inferred or defaulted. In this proposed contract, an unknown observation time cannot become a fresh observation through a server default.

Give missingness a visible state

Keep at least three questions separate: is there a record, is its time interpretable, and is it usable for this decision? A record may exist but carry a suspect quality flag. Another may have a trusted timestamp but exceed the age limit. Both should remain inspectable.

The companion reference uses six states: missing, not yet received, unknown time, suspect, stale and current. These are original application choices, not standard-mandated labels. Current means only that this narrow contract accepts the value, time and declared quality flag. It does not mean the physical estimate is correct or that a collection should be scheduled.

Do not collapse all exclusions into a failed-sensor count. A delayed upload, an absent device, an unknown timestamp and a suspect measurement suggest different investigations. Keep the reason beside the last value, and keep the last value out of the current-decision population when it fails the contract.

Choose age limits for the decision

Declare the decision time and the maximum accepted observation age. The fictional fixture uses fifteen minutes solely to demonstrate a boundary. That number is neither a municipal service objective nor a recommended sensor interval.

A useful threshold depends on how quickly the property changes, the consequences of being wrong, communication conditions and the available response. A planning view and an urgent exception review may need different contracts. Name the contract version when producing a summary so later threshold changes do not quietly rewrite its meaning.

Define the edge precisely. The reference accepts an observation exactly at the limit and labels an older one stale. It rejects inconsistent known timestamps rather than assuming a clock correction. A real system would need an explicit clock-error policy; accepting uncertainty silently is a different choice.

Preserve what was known at the decision

For a retrospective comparison, exclude records received after the decision time even when their observation timestamps are earlier. Otherwise a proposed predictive policy could benefit from evidence its operator did not possess. Save the original receipt history; a later export that contains only the newest value cannot reconstruct that boundary.

Keep later information available for a separate retrospective account. A late record can help explain a past event without becoming knowledge available to the earlier decision. This investigation concerns whether evidence was usable at that moment, extending the earlier collection-ledger work on recorded service counts.

Make an AI summary preserve uncertainty

If an assistant explains the dashboard, supply the state and decision contract alongside each value. Ask it to distinguish current observations from historical context and to identify missing evidence. A fluent sentence must not turn an unobserved container into an empty one.

Retain the source record and the deterministic classification behind the explanation. Evaluate whether the assistant preserves exclusions, units and timestamps before trusting its summary. No assistant was evaluated here; the offline checks concern classification behavior only.

The companion Design study sets out a proposed review flow. The research pack provides a fixed synthetic fixture, executable reference, tests and reproduction guide. Field calibration, policy simulation and actual operational outcomes remain separate work.