## The problem
Autonomous and semi-autonomous systems — industrial control, robotics, any closed-loop actuator — fail in a specific, well-known way: the system's internal model of the world goes stale (a sensor lags, an external event changes state faster than the loop notices, a network hiccup delays feedback) and the controller acts on the old picture anyway. This is a named failure class in safety engineering (SOTIF/ISO 21448 explicitly covers it) and it is hard to eliminate because "detect that your own state is stale" is a harder problem than "detect that an input is wrong."
## What this control loop does differently
This is a deterministic, recursive control architecture (Rust, runs on CPU, no GPU required) built around one invariant: **authority to act is never inherited from a prior tick — it must be re-earned against present-state evidence every cycle.** Nothing downstream (actuation, memory, output) can proceed on the strength of "it was valid a moment ago."
Three independent checks enforce this, each re-verifying staleness at a different point in the pipeline:
1. Mid-evaluation staleness check
2. Qualification-to-authorization staleness check
3. Authorization-to-actuation staleness check
No single check is load-bearing alone; each is redundant against the others failing.
## What's been measured, not claimed
- **Stale-action rate across all test runs to date: 0.** (`stale_actions_executed=0`), including a 20,000-interaction fully autonomous run with real earned resource cycling (no injected/reset state, no human inputs mid-run).
- **Actuation coverage:** 19,990 of 20,000 interactions in that run resulted in real actuation — the loop wasn't idling, it was under continuous load while maintaining the zero-stale-action guarantee.
- **Bounded, deterministic recovery from perturbation:** under controlled kick tests, the system returns to its stable operating point with measured exponential settling (time constant ≈13.93 ticks, R² ≈0.9998) and no divergence at any tested magnitude.
- **Deterministic replay confirmed** — identical runs reproduce identical decisions, a prerequisite for certification-style audit trails.
- **Robust to a specific hard case:** net-zero disturbances (an external event that changes state and then changes back before the next check) are still caught by a revision counter, rather than being invisible because the "before" and "after" snapshots look identical.
## Where this fits
Not pitched as a general AI-safety framework. The claim is narrower and more checkable: a working staleness-proof authority model for closed-loop control, independent of what's generating the candidate actions (currently tested both with and without a language model driving inputs). Relevant wherever a control loop's failure mode is "acted on outdated information it had no way to know was outdated."
## What I'm looking for
A technical review from someone in controls/robotics/safety-critical systems who can evaluate the specific claim above against the actual test harness and source — not a pitch, a critique. Full source, test logs, and methodo
logy available on request.
Autonomous and semi-autonomous systems — industrial control, robotics, any closed-loop actuator — fail in a specific, well-known way: the system's internal model of the world goes stale (a sensor lags, an external event changes state faster than the loop notices, a network hiccup delays feedback) and the controller acts on the old picture anyway. This is a named failure class in safety engineering (SOTIF/ISO 21448 explicitly covers it) and it is hard to eliminate because "detect that your own state is stale" is a harder problem than "detect that an input is wrong."
## What this control loop does differently
This is a deterministic, recursive control architecture (Rust, runs on CPU, no GPU required) built around one invariant: **authority to act is never inherited from a prior tick — it must be re-earned against present-state evidence every cycle.** Nothing downstream (actuation, memory, output) can proceed on the strength of "it was valid a moment ago."
Three independent checks enforce this, each re-verifying staleness at a different point in the pipeline:
1. Mid-evaluation staleness check
2. Qualification-to-authorization staleness check
3. Authorization-to-actuation staleness check
No single check is load-bearing alone; each is redundant against the others failing.
## What's been measured, not claimed
- **Stale-action rate across all test runs to date: 0.** (`stale_actions_executed=0`), including a 20,000-interaction fully autonomous run with real earned resource cycling (no injected/reset state, no human inputs mid-run).
- **Actuation coverage:** 19,990 of 20,000 interactions in that run resulted in real actuation — the loop wasn't idling, it was under continuous load while maintaining the zero-stale-action guarantee.
- **Bounded, deterministic recovery from perturbation:** under controlled kick tests, the system returns to its stable operating point with measured exponential settling (time constant ≈13.93 ticks, R² ≈0.9998) and no divergence at any tested magnitude.
- **Deterministic replay confirmed** — identical runs reproduce identical decisions, a prerequisite for certification-style audit trails.
- **Robust to a specific hard case:** net-zero disturbances (an external event that changes state and then changes back before the next check) are still caught by a revision counter, rather than being invisible because the "before" and "after" snapshots look identical.
## Where this fits
Not pitched as a general AI-safety framework. The claim is narrower and more checkable: a working staleness-proof authority model for closed-loop control, independent of what's generating the candidate actions (currently tested both with and without a language model driving inputs). Relevant wherever a control loop's failure mode is "acted on outdated information it had no way to know was outdated."
## What I'm looking for
A technical review from someone in controls/robotics/safety-critical systems who can evaluate the specific claim above against the actual test harness and source — not a pitch, a critique. Full source, test logs, and methodo
logy available on request.
