An epoch is an identifier that changes when restart, reconfiguration, or an authority reset invalidates work from an earlier system instance. After Relay restarts from epoch 4 into epoch 5, C42 cannot regain authority merely because its delivery was retried. A local admission gate is the component beside execution that compares the command with current time, epoch, goal state, protective state, source age, and motion limits. For C42, the first mismatch is enough: epoch 4 is not epoch 5, so the gate records a rejection and produces no actuator effect. New command C43, generated from current state S932 in epoch 5, can proceed through the same checks.
Reliability is a transport property
ROS 2 exposes the distinction in its Quality of Service settings↗. History and depth govern queued samples; reliability governs whether delivery is best effort or retried; durability governs availability to late joiners; deadline, lifespan, and liveliness express different timing and availability expectations. Choosing reliable delivery does not by itself bound end-to-end latency or prove that the delivered command still describes the state in front of the robot.
Lifespan can help discard old messages in transport, but semantic validity may be narrower. A command can arrive within a generic transport lifespan after the wrench moved, after its goal was cancelled, or after the controller’s authority epoch changed. Conversely, an old inventory observation might remain valid for an asynchronous report even though it is unusable for collision response. The consumer that knows the physical use must make the final admission decision.
The ros2_control Controller Manager documentation↗ describes a periodic read-update-write loop, update-rate configuration, scheduling and memory settings, overrun handling, and diagnostics. Those mechanisms provide a concrete place to observe timing and apply controller logic. They do not guarantee that arbitrary hardware, kernels, drivers, or application code meet a deadline, and they do not define Relay’s complete stale-command protocol.
Asynchronous learned policies make the issue easier to trigger, not unique to AI. The SmolVLA preprint↗ decouples chunk generation from execution so a robot can keep executing while the next chunk is produced. That supports concurrency between model work and motion. It does not establish a production protocol for rejecting chunks derived from old observations; Relay’s source sequence, epoch, validity, and admission rules are book synthesis layered around the mechanism.
A credible countercase is a single-process controller over a private memory channel where commands are computed and consumed synchronously inside one measured period. Explicit epochs and network-style sequence fields may add no value if restart atomically clears all pending work and the controller can prove that no stale producer survives. Even then, the invariant still exists: a command is admitted only for the state and cycle that produced it. The implementation has encoded validity structurally rather than in a message.
What this does not prove
This note does not prove that ROS 2 reliable QoS is unsuitable for control, that timestamps alone make motion safe, or that rejecting stale commands defines a safe fallback. Clock synchronization, wraparound, queue bounds, cancellation races, restart persistence, and the physical protective response each need their own design and test. The bounded claim is simpler: successful delivery preserves a proposal; only local admission can grant current physical authority.
What field would let your lowest local controller reject a command that is semantically plausible but no longer valid for the state in front of it?
