Sensor freshness and command authority need separate clocks

A fixed camera and a mobile robot can observe the same workcell at different times. The newer network arrival may be the older observation. Buffering, a reconnecting gateway or uneven processing can change arrival order without changing when the physical event happened. A shared mission view needs to preserve that distinction rather than quietly presenting the last received value as current truth.

A useful observation record identifies the source, capture time, arrival time, clock assumptions, relevant calibration context and uncertainty. When one of those is missing, show the gap. Arrival time can establish when a system learned something; by itself it cannot establish when the scene looked that way.

A temperature trend used to schedule maintenance may tolerate a different observation age from a workcell-occupancy check. Define the intended use, the consequence of stale evidence and what other observations can corroborate it. A single global timeout conceals those differences and encourages operators to treat unrelated sensors as interchangeable.

Preserve disagreement as well. If a camera suggests a clear station while the last device record shows an occupied resource, neither a favourable model confidence nor a newer arrival should silently erase the conflict. The next task may need a new observation, a device-state query or a human review, depending on the application boundary.

The official ROS 2 documentation distinguishes deadline, lifespan, liveliness and reliability policies. These address different delivery or participant conditions. A middleware lifespan can limit message availability; it does not, by itself, establish that the remaining data is suitable for a particular mission decision.

The application still needs to connect the observation to its task and permitted use. Retain the capture reference, explain what the model derived from it and record any transformation. If several sensors contribute to an assessment, preserve their individual time context rather than assigning the fused result an unexplained single timestamp. ROS 2 is external technical context here, not a claim of a completed NODERIQ adapter.

Suppose an operator approves a specific service-kit transfer for one destination within a defined validity window. A later image can improve the scene evidence, but it does not extend that instruction to another station or renew expired permission. Conversely, an approval that remains valid does not make an old occupancy observation usable again.

Check both conditions at the relevant admission boundary and preserve the reason for a hold. Bind the approved intent to its identity, scope and validity. When the proposed action changes, route the change to the responsible authority instead of treating a general approval as continuing permission for every new plan.

In NODERIQ, the useful interaction connects a selected device or task to the source observation, recommendation, review and outcome. The public console offers a controlled browser scenario for inspecting stale context and evidence-linked objects. Its frame references are illustrative, and it has no connected camera, live fleet or physical dispatch.

Our sensor and network evaluation work starts by mapping which decisions depend on which observations. The deliverable is a set of task-specific freshness rules, a source and clock record, explicit unknown and conflict states, and test cases for delayed or missing data. The physical sensor, controller and operating site still need separate acceptance; the proposed host/QEMU study is not a sensor-validation result.