JARVISLabs

The governance chain as built, and why the E-stop is checked at every layer

The simple story is proposal, policy, approval, E-stop, execution. The code works differently. The E-stop comes first and is re-checked at four points, approvals are consumed inside the policy decision, and nothing is done until the world has been read back.

4 min read

Diagrams of assistant safety usually draw a straight line: the model proposes an action, a validator checks it, a policy engine decides, an approval is requested, an emergency stop sits somewhere near the end, and the action runs. JARVIS’s governance kernel implements the same ideas in a different order, and the differences matter. This entry follows a model-composed step through the code as it stands and explains why the E-stop appears four times.

One kernel, no side doors

The constitution forbids a parallel architecture, so there is exactly one of each piece: PolicyEngine, ApprovalRegistry, EStop, IntentLedger, AuditTrail, EvidenceStore, ActionLedger and ProviderGateway. Every effect goes through the same kernel, whether it came from the model, a mission, an automation, a gesture or a stored protocol. The automation boundary calls PolicyEngine.decide first and can only narrow the result. The network gateway runs E-stop, host allowlist, SSRF check, policy, budget reservation, call and reconcile, in that order. Gestures reach the same policy decision as spoken commands.

A step through the chain

When the model wants something done, its tool calls are gathered into a ToolProposal. The record type is documented as “never an instruction or effect authority.” The rule in compose.py is blunter: “THE MODEL PROPOSES; THE RUNTIME DISPOSES.” From there, dispatch_command runs these stages:

  1. Intent contract, for consequential missions only. The contract is versioned and immutable while the mission executes.
  2. Grant allowlist. A command the ToolAuthority has not granted ends as REFUSED_UNAUTHORISED.
  3. Barge-in check at the step boundary. If the owner has started speaking, the step ends as ABANDONED_ON_BARGE_IN, and no effect is left half-applied.
  4. E-stop. STOPPED_BY_ESTOP.
  5. Irreversible-class guard. REFUSED_IRREVERSIBLE.
  6. PolicyEngine.decide, which is fail-closed: any unexpected exception becomes DENY. It runs its own fixed order: E-stop, device consent, owner-root path check, proof-gated self-improvement, standing authority (ALLOW), approval-required (consume an approval, or return NEEDS_APPROVAL), and otherwise DENY. Every decision is appended to the hash-chained audit trail and opens an action-ledger item.
  7. Executor. Normalise the command, compute the expected state, read the world before, run the effect and discard its return value, then observe.
  8. Verification. Observed against expected gives VERIFIED, REJECTED, UNVERIFIED, FAILED or REFUSED. The plan halts on anything except VERIFIED.
  9. Receipt. A ToolReceipt records whether the effect is true, false or unknown. It goes into the plan report and the append-only evidence store.

The action ledger’s lifecycle runs REQUESTED, POLICY_CHECKED, AWAITING_APPROVAL, APPROVED, EXECUTING, VERIFYING, COMPLETED. COMPLETED cannot be reached without passing through VERIFYING.

Three corrections to the simple story

Approvals live inside the policy decision. The approval registry is consumed at step six of decide, not as a later stage. That placement means an approval can only satisfy the specific policy branch that asked for it. An approval-required action cannot acquire standing authority, and twelve action classes always need approval. They include sending messages, publishing, deleting data, changing credentials, bulk downloads, unrestricted shell, hardware actuation, printing and mutating desktop controls.

Approvals are bound to the exact object. Each approval is bound to the owner, the action and the object, where the object is identified by a SHA-256 of a canonical descriptor. That defeats the attack where an approved file or window is swapped for another before execution. Approvals expire after five minutes by default and cannot be replayed. Six named attacks are exercised in tests/security/test_the_six_approval_attacks.py.

The “validator” is several layers. It is each command’s own normaliser, the grant allowlist, the irreversible-class guard and, for missions with consequences, the intent contract. Each layer can refuse on its own.

Why the E-stop is checked four times

The E-stop is checked before every plan step, again as the first step inside PolicyEngine.decide, again when an approval is consumed, and again in the provider gateway. “No approval can override E-Stop.” The latch persists across restarts, and an unreadable latch counts as engaged.

The repetition exists because time passes between the layers. A plan can be approved, then wait for a slow window to appear, then reach the executor several seconds later. If the stop were checked only at the start, a trip during that wait would be ignored. If it were checked only at the executor, a model could still spend budget on a provider call after the owner had pressed stop. Each check guards a different window: planning, deciding, consuming an approval and leaving the machine.

The same idea appears in newer work. Advanced Systems CAD commits are fenced on the E-stop generation, so a trip and re-arm between calculation and file publication is detected. The spatial scene’s spin preview has to renew a short E-stop lease while it animates.

What the evidence shows

On 17 September bounded probes against booted processes recorded the fail-closed policy engine, the E-stop and the prompt-injection detector as LIVE in the registry. The 16 September capability model classified SECURITY/AUTHORITY and ACTION VERIFICATION as PROVEN_LIVE on the owner’s machine.

The most concrete stop measurement came two days later. During a local image-generation mission, with the GPU rendering, an E-stop was acknowledged in 19.4 ms, and all three owned processes had settled by 374.68 ms. No process survived, the mission ended in a failed state with “solve cancelled before publication”, and no artifact was published. That was a single run on one path.

The physical printer shows how far the rule reaches. A measured E-stop trip ran its local handlers in 0.872 ms while the printer reported it was building. The pause command was sent and acknowledged, but whether the printer actually paused is recorded as unproven. The print start gate itself refuses every caller, by design.

Open edges

The constitution sets an E-stop budget under 150 ms mid-utterance. A measured 31 ms spin-stop in the Advanced Systems scene was labelled by the project as “not worst-case 150 ms qualification”. A checkpoint of 18 September found that no production code constructed the intent ledger, so any multi-step plan containing an irreversible command was refused. That failure mode is safe, but it means such plans can never run. Later work targeted the gap, and whether it is fully closed is uncertain. Most governance rows are TESTED rather than LIVE, and none is formally verified.