By Anant MishraDesign study
Fictional design and synthetic software reference only. No sensor network, municipal partnership, AI evaluation, field trial or collection improvement is claimed.
Design feature 01
Six synthetic records
Design feature 02
Explicit decision cutoff
Design feature 03
Field evaluation pending
Executive Summary
Distinguishing zero, absent, stale, suspect and late telemetry at a declared decision boundary, with an offline synthetic classification reference.
Architectural Deep Dive
A fictional review queue with explicit evidence limits
This Design study proposes an observation-review component for a fictional waste-collection planning system. It would help an operator understand which container-fill observations are usable at a declared decision time. Every asset and reading in the worked fixture is synthetic. No sensor network, municipal customer, field trial, route optimizer or AI assistant was deployed or evaluated.
The narrow implementation delivered with this study is an offline classifier and software tests. It demonstrates timestamp and value-handling rules. The wider review interface and operating process remain proposed. Passing those software checks establishes neither sensor accuracy nor a better collection policy.
Start with one property and one decision
The proposed decision is whether a fill estimate may enter a current planning input set. It does not itself select a vehicle or authorize a missed visit. The input property is fill percentage, with a declared numeric range from zero to one hundred. The fixture's fifteen-minute maximum age is an invented demonstration parameter, not an operational recommendation.
Each record identifies a fictional asset, its value, an observation timestamp when known, an application receipt timestamp, a time-origin label and a declared quality flag. The W3C and OGC sensor ontology distinguishes the feature being observed from its property and procedure. This design borrows that conceptual separation; it is not a claim of standards conformance or device validation. [2]
A production adapter would also need verified sensor identity, procedure and units. The reference assumes those fields have already been resolved for this single property. It does not implement ingestion, authentication, deduplication or the selection of a latest record from a history.
Work through six synthetic records
At the fictional decision time of 10:00 UTC, one record reports zero at 09:55 and arrives at 09:56. Its declared quality is accepted and its time origin is observed. It is current under the demonstration contract. Another asset has no record and remains missing.
A third reports zero at 09:00 and arrives at 09:59. Its recent arrival cannot rescue an observation that is an hour old. A fourth has an unknown measurement time, even though receipt time exists. A fifth carries a suspect quality flag. The sixth was observed at 09:58 but arrives at 10:02, after the decision.
The fixture expects one current record and one in each of the other five states. These are invented input classifications, not a measured availability rate. Only the current zero is eligible for the narrow planning input; it still does not prove physical emptiness.
Keep time provenance at the adapter boundary
SensorThings API 1.1 provides phenomenon and result-generation times, quality information and optional validity intervals. It also defines server defaults for omitted times. An adapter must therefore preserve what a timestamp represents instead of treating any populated time field as a device measurement. [1]
The reference uses an explicit observed-or-unknown origin flag. An unknown origin produces an unknown-time state even if a timestamp string is present. Application receipt is a separate field. Result-generation time, uncertainty intervals and device-clock correction remain outside the reference's scope.
For known observation times, the parser requires an explicit UTC offset and rejects time ordering that is inconsistent with receipt. It does not estimate or repair clock offsets. A real deployment would need a reviewed tolerance policy for clock uncertainty rather than borrowing this strict assumption unnoticed.
Specify precedence and preserve the cutoff
A missing record is missing. For a supplied record, validate its structure and declared range first. If it arrived after the decision cutoff, classify it as not yet received before considering its quality or age. The decision cannot use it.
Among visible records, unknown observation time takes precedence, followed by suspect quality, then excessive age. A record exactly fifteen minutes old is current under the invented fixture rule. This deterministic order ensures that combined problems produce a reproducible primary reason. It does not claim that secondary problems disappear.
Keep the original record available for inspection. The reference returns the numeric value with the classification and a separate eligibility flag; downstream consumers must honor that flag. A production system should enforce the input boundary structurally and test that excluded values cannot silently reappear in an AI summary.
Propose a review path without pretending it exists
The proposed operator view would group missing, unknown-time, suspect and stale records for investigation, with the asset and available source history. Records not yet received would remain excluded from historical decision replay. The operator could request a fresh observation or use a documented alternative procedure.
Any later correction should retain who changed the interpretation, why, and when. Do not replace the original receipt time to make a late record appear timely. A later factual reconstruction and a replay of what was knowable answer different questions.
What can be reproduced today
The AM-RP-002 preparation pack links the reference, six-record fixture, counterexample tests and contract guide. They run offline without hardware, credentials or a model. The earlier collection ledger and its counting definitions remain unchanged.
The companion essay explains the broader decision boundary. Before claiming operational value, the design needs authorized data, verified sensor procedures, representative histories, reviewed clock and age policies, a real interface, and evaluation of both decisions and human review. No field effectiveness, DGX experiment, peer review or scholarly indexing follows from this release.
Proposed approach
- Implemented
- Offline classification reference
- Proposed
- Operator review workflow
Sources
- SensorThings API Part 1: Sensing, version 1.1 — Open Geospatial Consortium; reviewed 5 November 2026
- Semantic Sensor Network Ontology, 2017 Recommendation — W3C and OGC; reviewed 5 November 2026
Related reading
Read the publishing standards or suggest a correction.