AM.
Back to Overview

Designing a Review Queue for Missing and Stale Observations

Mandate & Focus

Design study · Fictional waste observation review — independent design

By Design 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

Technical FAQ

Does a zero reading prove a container is empty?
No. It is a numeric observation under a particular procedure. Its time, quality, units and physical accuracy still matter. A missing record must not be converted into zero.
Is fifteen minutes a recommended freshness limit?
No. It is an invented parameter in the synthetic fixture. Actual age limits require a decision-specific policy and evidence about the observed property and consequences.
What has actually been implemented and tested?
An offline Python classifier and synthetic software tests check value, timestamp, cutoff and classification rules. No sensor, review interface, collection policy or AI assistant has been evaluated.

Ready to architect operational leverage?

Available for fractional executive leadership, enterprise architecture consulting, and board-level technical advisory.

Initiate Dialogue ↗