Robustness, Calibration, and Safe Control › Fallback Policies and Runtime Assurance

The architecture we now describe has a history in safety-critical control under various names; a standard formulation is the Simplex pattern. Split the controller into two parts:

• A performance controller, which may be arbitrarily complex, learned, and unverified. It is the thing that does the task well.
• A safety controller (the fallback), which is simple enough to be analyzed, tested exhaustively, or verified. It is the thing that keeps the system inside the safe set.

A monitor decides which controller is in charge. A formal safety result needs more than a simple controller and a threshold: the initial condition must admit a safe continuation, the decision module must be correct, and switching must preserve that continuation under the declared disturbances and timing. A permanently safe command sequence and correct decision module are explicit assumptions in the Black-Box Simplex formulation. This relocates the verification burden rather than removing it. A finite simulation of our proportional-derivative fallback is evidence about tested episodes, not certification.

The sections that follow name the important parameters: the declared parameter bounds $(k, c, g, f)$, the innovation threshold $Z_{\text{threshold}}$, the fallback tail length, and the CVaR level together with the number of draws and candidates.

The monitor should not assume that accurate training predictions imply a valid safety model under shift. Learned models can participate in a certificate when their error is bounded under defensible assumptions; otherwise a model-only safety check can share the planner's blind spots. Our small damping shift changed empirical coverage modestly, not catastrophically, but that result still does not establish future safety. The toy screen below uses a separate declared scenario to illustrate this separation of responsibilities.

We can posit a separate parameter scenario to illustrate the architecture. Its settings are not independently verified bounds on a physical plant, so calling the scenario conservative does not establish containment. In our example, we use

$$k \ge 0.80, \qquad c \ge 0.0, \qquad g \ge 0.90, \qquad f \ge 0,$$

where:

• $k$: stiffness, the restoring force per unit displacement
• $c$: viscous damping, the drag proportional to velocity
• $g$: actuator gain, how much acceleration one unit of command produces
• $f$: dry friction, a constant drag opposing motion

These lower limits alone do not define a finite parameter box or prove a worst-case trajectory. Our code fixes stiffness and friction and selects damping/gain endpoints greedily along one trajectory. Its choices are illustrative engineering settings, not verified physical bounds. Greedy outward acceleration need not maximize the eventual peak because it changes subsequent velocity and position. The resulting value is a scenario peak, not an enclosure of all reachable states.

For a bounded uncertainty set $\mathcal B$, a disturbance set $\mathcal D$, and known initial state $s$, a formal endpoint reachable set would be

$$\mathcal W_H(s)=\{p_H:\ s_0=s,\ s_{t+1}=f_{b_t}(s_t,\pi_{\mathrm{fb}}(s_t),d_t),\ b_t\in\mathcal B,\ d_t\in\mathcal D\},$$

where:

• $\mathcal{W}_H(x)$: the worst-case forward reachable set of positions after $H$ steps from state $x$
• $p_H$: the position at the end of the horizon
• $p_t, v_t$: position and velocity at step $t$ of the rollout
• $(k, c, g, f)$: stiffness, damping, gain, and friction parameter tuple
• $\mathcal{B}$: the box of declared parameter bounds
• $u_t = \pi_{\text{fb}}(p_t, v_t)$: the fallback action at step $t$

Here $f_{b_t}$ is the discrete plant transition with parameter tuple $b_t$ and disturbance $d_t$; $\mathcal D$ states the permitted disturbances. Safety over the horizon needs every intermediate reachable set, not only $\mathcal W_H$, to lie inside the safe envelope. State-estimation error requires an initial set rather than a single $s$. Infinite-time assurance additionally needs a terminal invariant continuation, and a physical plant requires inter-sample and latency analysis. Gaussian process noise in our simulation is unbounded, so no finite deterministic disturbance envelope covers every draw. A bounded-noise proof would describe a different explicit disturbance model, or a probabilistic result with a stated failure level. None is proved by the scenario screen below.

A complementary signal comes from innovation monitoring: compare predicted and observed next states after an action, normalized by predictive standard deviation. This is a reactive diagnostic, not a reachable-set certificate. The toy combines it with a finite scenario screen; a certified architecture would replace that screen with a justified enclosure and safe continuation test.

$$z_t = \sqrt{\frac{1}{d}\sum_{j=1}^{d} \frac{\left( s_{t+1}^{(j)} - \hat{s}_{t+1}^{(j)} \right)^2}{\sigma_{t+1}^{2\,(j)}}} .$$

where:

• $d$: the state dimension (here $d = 2$, for position and velocity)
• $s_{t+1}^{(j)}$: the $j$-th component of the observed next state
• $\hat{s}_{t+1}^{(j)}$: the $j$-th component of the model's predicted mean next state
• $\sigma_{t+1}^{2\,(j)}$: the model's predicted variance for the $j$-th component
• $z_t$: the root-mean-square standardized innovation; under correct componentwise zero means and variances, $\mathbb E[z_t^2]=1$, not generally $\mathbb E[z_t]=1$

The threshold $Z_{\text{threshold}}$ trades sensitivity against false alarms. Changed dynamics may increase the statistic, but benign noise can also trigger it and small changes may remain undetected. This root statistic is not a chi-square innovation test: the position and velocity innovations are correlated by construction, and we do not whiten their full covariance. The code uses a single-transition threshold and a lower reset threshold, not a smoothed window, formal sequential detector, or calibrated false-alarm probability. The earlier filtering material provides context for residual diagnostics, not a guarantee for this heuristic.

Two details matter. The statistic needs an observed transition, so it cannot prevent harm during that first transition. Its scale also depends on the predictive variance, so overestimated variance can hide errors and underestimated variance can create false alarms. There is no universal one- or two-step detection bound here. Logging innovations, threshold crossings, and selected actions is necessary to distinguish detection from scenario-triggered handover.

The two monitors are complementary:

• The consistency monitor is inexpensive and reactive. It needs at least one observed transition and may miss a shift indefinitely.
• A certified reachability monitor can reject a proposal before execution, provided its enclosure and timing assumptions hold. Our finite scenario screen has this prospective timing but not that certification.

A design may combine these signals, but combining heuristics does not produce a proof. A sound safety condition must remain enforced even when residuals look benign; an innovation test should not override it merely to improve performance. The two signals address different evidence, and their switching logic needs explicit analysis. In the experiment the shield checks the candidate sequence followed by a fallback tail in one deterministic scenario and also responds to innovation threshold crossings.

The declared scenario includes zero damping, but it omits process noise and searches neither all parameter paths nor all disturbance paths. It can trigger unnecessary fallback or accept an unsafe plan. The finite tail is thirty steps, not an invariant-set proof. The shield remains useful as an executable architecture example precisely when these limitations are visible; calling it conservative is not evidence that its peak upper-bounds the actual plant.

We run expected-cost MPC, CVaR MPC, and shielded MPC in nominal and zero-damping environments. Episodes start near the envelope with outward velocity, creating a useful braking stress test. Braking is not necessary in every nominal episode: restoring force and damping can already keep some noise-free trajectories inside. Comparing these controllers measures their combined behavior; it does not isolate manual braking from luck or prove which component caused an improvement.