What You Are Building
You are building a control path that sits between a robot's planner and its actuators, so that no physical action reaches a motor, arm, cutter, valve, or infusion pump until a governor has decided the action is safe enough to take right now. When the governor cannot establish that confidence, the system defaults to a safe, non-acting state rather than executing the pending command anyway.
This is the problem faced by anyone shipping a surgical tool actuator, an industrial manipulator, an infusion pump, or a mobile robot that shares space with people. The planner is usually optimistic: it computes a trajectory and issues it. But sensing degrades, an operator enters the work envelope, a needed observation goes stale, or the environment shifts in a way the plan did not anticipate. In those moments you do not want the last confident command to keep running. You want the machine to fall back to something safe, and you want a record of why.
The architecture described here comes from the Confidence-Governed Actuation inventive step, disclosed in U.S. Provisional Application No. 64/049,409. It is an approach you implement yourself, not a package you install.
Why the Obvious Approaches Fall Short
The two conventional approaches are the interlock and the emergency stop. An interlock is a hard condition wired ahead of an actuator: if a guard door is open, the motor cannot run. An emergency stop is an operator-triggered or fault-triggered cut that halts motion. Both are real, useful, and standard functional-safety practice. Neither is what this guide replaces, and neither should be removed.
The structural gap is that these mechanisms are binary and uncredentialed. An interlock either permits or blocks; there is no middle behavior between full execution and complete cessation. An e-stop is a single signal with no notion of who issued it, whether that authority was legitimate, or how often it has been invoked. And critically, conventional sensor-to-actuator control terminates at the actuator command: the system issues the command and moves on, without comparing the observed effect against the expected effect, and without leaving a reconstructable record of why the action was permitted.
So when confidence quietly erodes, a binary interlock sees nothing to trip on, and the last confident command keeps executing. The disclosed architecture addresses this by making every actuation pass through a graduated, credentialed evaluation, with a safe non-acting mode as the natural low-confidence outcome rather than an exceptional one.
The Architecture
The spec describes a confidence-governed execution primitive. Its core idea is that every physical actuation, of a braking system, a manipulator arm, a surgical tool actuator, a medical-dispensing actuator, a valve, and so on, is treated as a governed action that must be evaluated before it executes. The evaluation is done by a composite admissibility evaluator that considers the proposed actuation jointly with the observations the unit has consumed and other cognitive inputs. This is the physical-space extension of a confidence governor that, in the cited work, modulates an agent's readiness to act.
Four elements make the safe-idle fallback work.
First, graduated actuation modes. Instead of permit-or-deny, the disclosed mode selector maps the admissibility determination onto a range of modes. The spec enumerates, among others: a disabled mode where the actuator does not execute and the non-execution is recorded; a simulated mode that dry-runs without physical effect; an advisory mode that records what would have been done; a consultative mode that requests confirmation from a human operator or higher-authority endpoint and waits; a partial mode at reduced magnitude, rate, or scope; a constrained mode subject to added limits; a stage-gated mode that executes in stages with re-evaluation between them; and a full mode at nominal execution. As confidence rises the selector moves toward more autonomous modes; as it falls, the selector moves toward less autonomous modes. Your safe-idle fallback is the disabled mode: the low-confidence terminus of this ladder.
Second, per-actuator confidence thresholds. Each actuator carries thresholds that gate execution at each mode. A high-consequence actuator, the spec names propulsion in traffic, weapon-system terminal actuators, and medical-dispensing actuators, requires elevated admissibility across multiple contributing factors before it executes at full mode, while a low-consequence actuator such as an indicator light requires only baseline admissibility. Thresholds are dynamically modulated: an actuator with a depleted capability envelope, or operating where forecast uncertainty is high, runs under elevated thresholds. This is how "unsure" becomes "stay idle" automatically.
Third, execution readiness that degrades and recovers. The spec describes a confidence governor that reduces execution readiness proportionally as governance-credentialed inputs are lost at runtime, down to an infrastructure-denied mode operating on the unit's own sensors with governance-policy-defined conservatism, and restores readiness as corroborating observations accumulate again. In-progress actuations can be de-escalated mid-execution to a constrained, partial, simulated, or disabled mode when a newly arriving input indicates reduced admissibility.
Fourth, reversibility awareness. A commitment-point evaluator classifies actuations by reversibility and identifies, for a staged actuation, the stage beyond which continuation becomes irreversible. Before that commitment point, a drop in admissibility can interrupt the sequence without incurring the irreversible final stages. For a cutting tool or a dose, this is the difference between backing off and committing.
Throughout, the spec requires lineage recording: every evaluation, every mode selection, every de-escalation, every commitment-point transit, and the post-actuation verification outcome are recorded so the decision can be reconstructed afterward. A post-actuation verification step compares observed effects against expected effects and can raise thresholds for that actuator when discrepancies recur.
How to Approach the Build
The following steps are illustrative and faithful to the disclosed structure. You are implementing them yourself.
Interpose a governor between planner and driver. No actuation command should reach a physical driver except through this stage. The proposed actuation identifies an actuator, a command, and parameters.
Define your admissibility inputs. Decide what evidence feeds the confidence determination: fresh sensor observations, staleness of required inputs, whether an operator is in the envelope, capability-envelope state, forecast uncertainty. The spec treats admissibility as composite; you choose the contributing factors.
Enumerate modes for each actuator class and pick your idle mode. At minimum, wire disabled, some reduced modes (partial, constrained, simulated), a consultative mode, and full. Your safe-idle fallback is the disabled mode. Decide what "idle" physically means for each actuator, holding position, retracting, or ceasing dispensing.
# Illustrative only; faithful to the disclosed mode-selection structure.
def select_mode(actuation, admissibility, thresholds):
if admissibility < thresholds.disabled_floor:
return "disabled" # safe-idle fallback: do not execute, record it
if admissibility < thresholds.constrained:
return "consultative" # ask a human / higher authority, then wait
if admissibility < thresholds.full:
return "partial" # reduced magnitude / rate / scope
return "full"
Set per-actuator thresholds by consequence, and modulate them. Give high-consequence actuators elevated floors. Raise thresholds when the capability envelope is depleted or forecast uncertainty is high, so degraded conditions push the selector toward idle without hand-written per-case rules.
Make readiness degrade at runtime. When credentialed inputs are lost, lower readiness and let the raised thresholds pull actions down the mode ladder. Support mid-execution de-escalation so an action already running drops to a reduced or disabled mode on a new adverse input.
Classify reversibility and detect the commitment point. For staged, irreversible actuations, identify the last stage before continuation is irreversible, and allow interruption before it. Prefer reversible or late-commitment paths where admissible.
Record lineage and verify effects. Write each decision, mode selection, and de-escalation to a provenance record. After execution, compare observed against expected effect, and let recurring discrepancies raise that actuator's thresholds.
What This Does Not Give You
This is an architecture, not a drop-in library, and there is no package to install. Every component above is something you build and integrate into your own control stack. The disclosure is a patent filing describing the approach; it is not benchmarked, not certified to any safety-integrity level, and not a production-proven product. Nothing here reports performance numbers, because the filing does not, and you should not assume any.
It does not replace your interlocks, your e-stops, or your functional-safety certification obligations. Treat it as a governance layer above those mechanisms, not a substitute for them. It gives you a graduated, recorded, confidence-driven path to a safe-idle default; it does not by itself guarantee any particular safety outcome, and the correctness of your thresholds, your admissibility inputs, and your definition of "idle" for each actuator is entirely your responsibility. Where an actuator has no meaningful non-acting state, the disabled mode is not automatically the safe choice, and you must reason about that case yourself.
Disclosure Scope
The architecture in this guide, including the confidence-governed execution primitive, graduated actuation modes, per-actuator confidence thresholds, reversibility-aware commitment-point evaluation, and lineage-recorded actuation provenance, is disclosed in U.S. Provisional Application No. 64/049,409. This guide is educational. It describes an approach a developer can build; it is not a warranty, not a certification, and not an offer of software. Any implementation, and its fitness and safety for a given deployment, is the responsibility of the implementer.
