Governance in JARVIS is not a filter in front of the model. It is the only route to the world. A model proposal, a mission step, an automation, a gesture or a protocol message all reach effects through the same fail-closed kernel. The constitution forbids a parallel architecture, so there is exactly one of each piece: one PolicyEngine, one ApprovalRegistry, one EStop, one IntentLedger, one AuditTrail, one EvidenceStore, one ActionLedger and one ProviderGateway.
Why insist on one of each? Two policy engines can disagree. Two approval stores can each hold a different truth. A safety property that holds in one path and not another does not hold. A single kernel means a fix made once applies everywhere.
The chain as implemented
The simplified story usually drawn is “proposal, validator, policy, approvals, E-stop, executor, observation, receipt”. The code differs from that story in three ways. The E-stop comes first and is checked repeatedly. Approvals are consumed inside the policy decision. The “validator” is several layers. For a model-composed step, the order is:
- Proposal. The model’s suggestion becomes a
ToolProposal. It carries no authority. - Intent contract. Only consequential missions need one. It is versioned, it was shown to the owner, and it cannot change while it is executing.
- Grant allowlist. A command that has not been granted is refused as unauthorised.
- Barge-in check. If the owner has interrupted, the plan is abandoned at the step boundary. No effect is left half-applied.
- E-stop. If the E-stop is engaged, the step stops here.
- Irreversible guard. Irreversible action classes can be refused outright at this point.
- Policy decision.
PolicyEngine.decideruns. Any unexpected exception inside it becomes DENY. - Executor. The command is normalised, the expected state is computed, the world is read before acting, the effect runs (its return value is discarded), and the world is observed again.
- Verification. Observed state is compared with expected state.
- Receipt. The outcome is recorded and stored as evidence.
- Lifecycle. The action ledger records every stage.
Each command also normalises its own inputs. That is one more layer of “validation” that sits inside the command rather than in the chain.
Inside the policy decision
PolicyEngine.decide works in a fixed order. It checks the E-stop again. Then it checks device consent, then whether a path lies inside the owner’s permitted roots, then whether a self-improvement is backed by proof. Only after those checks can standing authority allow the action. If the action class needs approval, the registry tries to consume a matching approval, and if there is none the answer is NEEDS_APPROVAL. Anything else is denied. Every decision is appended to the hash-chained audit trail and opens an item in the action ledger.
Verification, receipts and lifecycle
A step ends in one of five outcomes: VERIFIED, REJECTED, UNVERIFIED, FAILED or REFUSED. A plan halts on anything but VERIFIED. The receipt records whether the effect is true, false or unknown. Its artifacts go into the append-only evidence store. A separate verification service can later corroborate a result as VERIFIED or REFUTED, or leave it COMPLETED_UNVERIFIED.
The action lifecycle is REQUESTED, POLICY_CHECKED, AWAITING_APPROVAL, APPROVED, EXECUTING, VERIFYING, then COMPLETED, or else FAILED or ROLLED_BACK. COMPLETED cannot be reached without passing through VERIFYING.
Approvals
An approval in JARVIS is narrower than “yes, go ahead”. Each one is:
- Owner-bound. Only the owner can grant it.
- Action-bound. It covers one action.
- Object-bound. It carries a SHA-256 hash of a canonical description of the target, so swapping the object after approval invalidates it.
- Expiry-bound. It lasts five minutes by default.
- Non-replayable. It is consumed on use.
Twelve action classes always require approval. They include sending messages, publishing, deleting data, changing credentials, bulk downloads, unrestricted shell, hardware actuation, printing and mutating desktop controls. An action that needs approval can never acquire standing authority. The security suite tests six named attacks on approvals. No approval can override the E-stop.
The E-stop can be triggered by hotkey, from the HUD or by voice, and it silences speech and cancels missions and effects. The constitution sets it a budget of under 150 ms mid-utterance. That is a target. The one related measurement, a 31 ms spin-stop on the Advanced Systems branch, was explicitly labelled as not a worst-case qualification.
Side doors reuse the kernel
Paths that do not start with the model still pass through the same pieces:
- Automation. The automation boundary calls
PolicyEngine.decidefirst and can only narrow the result, never widen it. - Autonomy envelope. Hard boundaries cannot be widened.
- Network. Outbound calls go in this order: E-stop, host allowlist, a server-side request forgery check, policy, budget reservation, the call, and reconciliation.
- Gestures and protocols. Both follow the same path as a model proposal. See perception.
Five distinctions the system never collapses
These pairs look alike and are treated as different things everywhere in JARVIS.
DISPATCHED is not VERIFIED
Sending a command proves nothing about its effect. When JARVIS opens an application, the step counts as VERIFIED only if an independent re-read of the desktop matches what was expected. On the desktop, a window move whose re-read geometry does not match is rolled back, not reported as done. A generic “invoke” with no independent check that the application reached its goal stays UNVERIFIED.
SIMULATED is not EXECUTED
A mission can be simulated before it runs. The simulation route labels its output SIMULATED / not_proof and has no effects. A clean simulation does not let the real run skip a single gate. The same rule applies to slicer print-time estimates on the engineering page.
HTTP SUCCESS is not EFFECT SUCCESS
A 200 response means a request was accepted, not that the world changed. For this reason the executor discards an effect’s return value and reads the world back instead. When an effect returned but the observer could not read back its result, the HUD shows COMPLETED-UNVERIFIED, never green. Handing a print job to the printer path is described in the project’s own words as asking, not doing.
STALE is not CURRENT
Evidence expires. A resolved window target holds a 20-second identity lease. After that, an action on it is refused with “target identity is unknown or expired”. Capability registry LIVE states decay after 24 hours. A referent in conversation that has gone stale becomes a question, not a guess.
CAPABILITY is not AUTHORITY
Being able to do something is not permission to do it. The capability registry separates what exists from what is GRANTED or WITHHELD. On the Advanced Systems branch, capability discovery “has no execution or grant method”, so asking what JARVIS can do cannot cause anything to happen. Specialist roles are scope ceilings, not permissions. See agents.
What is not proven yet
- Live readings are historical. The governance LIVE states date from 17 September 2026 and have decayed under the 24-hour rule.
- Most governance rows are TESTED, not live. This includes approvals, the audit trail and the evidence store. Their tests pass, but no dated live probe is on record.
- The intent-ledger gap is uncertain. Notes from 18 September 2026 recorded that production did not construct the intent ledger, so multi-step plans containing an irreversible command were refused. That failure mode is safe, but it limits what JARVIS can do. Later work targeted the gap, and whether it is fully closed is uncertain.
- The E-stop’s 150 ms budget has not been qualified at worst case.
- Nothing here is formally verified. The properties above rest on code review, tests and bounded live probes, not machine-checked proofs.