A request like “tidy the downloads folder, then summarise what changed” is not one action. It is a sequence, and sequences get interrupted by restarts, failures, approvals that take a while, and the owner changing their mind. JARVIS runs such work as missions: durable records that survive interruption and can always explain where they are.
Durable from the first moment
The mission engine saves a mission to its SQLite store, in write-ahead-log mode, before step one runs. There is no separate checkpoint object. Instead, “every step’s inputs, outputs and status are written to SQLite as they happen”. Because the record is complete, a mission can be resumed without any of the language model’s conversational context. The state lives in the database, not in a prompt.
States
| Level | States |
|---|---|
| Mission | PENDING, RUNNING, PAUSED, PAUSED_FOR_APPROVAL, SUCCEEDED, FAILED, CANCELLED, COMPENSATING, COMPENSATED |
| Step | PENDING, RUNNING, SUCCEEDED, FAILED, SKIPPED, COMPENSATED |
PAUSED_FOR_APPROVAL is its own state because waiting for the owner is normal, not a failure. A mission can sit there until the owner answers, and nothing in it runs in the meantime.
Admission
Before a mission runs, it must be admitted:
- One executor. A single-executor claim token ensures only one runner owns the mission.
- Capabilities. Every capability the mission needs must be evidenced by the capability twin, the system’s record of what currently works.
- Intent contract. Steps with consequences need an intent contract that was shown to the owner. It is versioned and cannot change while it executes.
- Conflicts. Clashes with the owner’s existing commitments are surfaced.
Admission exists so that a mission fails early and cheaply, at the start, rather than halfway through with some effects already applied.
The step loop
Each step goes through the same loop:
- Check for a pause or cancel.
- Pause for approval if the step needs one.
- Refuse to retry a step that is not idempotent.
- Persist the step’s state.
- Run the handler through the governance chain.
- Check the budget.
- Read the result back.
Budgets cover wall-clock time, model use, tokens, cost and tool calls. A stall detector catches work that is stuck or looping. Retries apply only to steps that are safe to repeat. Repeating a non-idempotent step, such as sending a message, could do the thing twice.
Failure and compensation
When a mission fails, compensation runs newest-first: the most recent completed step is undone first, then the one before it, and so on. Later steps often depend on earlier ones, so unwinding in reverse order avoids undoing something that a later step still relies on. Where the outcome of a step cannot be determined, its postcondition stays UNRESOLVED rather than being assumed.
Restart: offer, never auto-resume
After a restart, a recovery report lists each resumable mission with its cursor, the point where it stopped. JARVIS offers to resume, and it is “never resumed” automatically.
Why not resume automatically? A restart often means something went wrong. The situation that justified the mission may have changed, and a step that was mid-flight may or may not have taken effect. Resuming blindly could repeat an effect or act on stale assumptions. The owner decides, with the recovery report in front of them.
Simulation
A mission can be simulated before it runs. The simulation route returns a result labelled SIMULATED / not_proof and has no effects. The rule is explicit: “Simulation never grants authority or certifies effects.” A clean simulation does not let any step skip admission, approval or verification. See research for how simulation fits the wider predict-before-act behaviour.
A known gap: the intent ledger
Checkpoint notes from 18 September 2026 recorded that no production code constructed the IntentLedger, the component that holds intent contracts. As a result, multi-step plans containing an irreversible command were refused. That failure mode is safe, because nothing irreversible could slip through without a contract, but it blocked legitimate work. Later work targeted this gap. Whether it is fully closed is uncertain, and this page does not claim that it is.
Many hands, one mission
Missions can be split among specialist roles within fixed depth and fan-out limits. On the Advanced Systems branch, which is not merged into production, specialist progress is also checkpointed in the mission store. See agents.
What is not proven yet
- Live readings are historical. The mission reading is from 16 September 2026, and the journeys are from before 17 September 2026.
- Surviving a machine reboot is not proven. The project explicitly does not accept killing a process as a substitute for a real reboot.
- The intent-ledger gap may or may not be closed.
- Registry mission rows are TESTED, not live-probed.
- Specialist checkpoints are on the Advanced branch only.
- Journey J8, speech interrupted while a mission continues, is fixture-tested only.