Nine stages, one request
How JARVIS thinks
From the moment the owner asks to the moment something is remembered, a request passes through nine stages. The model is only one of them, and it never holds authority. Follow a real recorded request through all nine.
The worked example is a real turn from the 22 September 2026 capture session, quoted from its turn record:
Stage 1 of 9
Request
The owner speaks or types. Speech is transcribed on the local GPU and checked: is this the owner, and is it addressed to JARVIS? If that is uncertain, JARVIS stays silent. A typed request enters the same loop at the next step.
Why it exists. A system that acts on the wrong voice, or on a sentence not meant for it, is unsafe before it has done anything.
In the recorded example
“Run the thermal bench simulation and show me the engineering results.” (typed)
Stage 2 of 9
Context
A lane classifier picks Reflex, Cognition or Mission in about 30 ms. Words like “it” and “that” resolve through a context stack whose slots are RESOLVED, STALE or UNBOUND; a stale referent makes JARVIS ask instead of guess. A context compiler then assembles what the model will see, within a token budget, without silently cutting required sections.
Why it exists. Most real requests are vague. Guessing what “it” means is how assistants act on the wrong thing.
In the recorded example
Lane: Cognition. The request names its target (the thermal bench case), so nothing had to be resolved from earlier turns.
Stage 3 of 9
Cognition
The language model reasons about the request with the tools it is offered. Those tools come only from JARVIS’s own command table: the model cannot invent or edit a tool. Today the model is a hosted one; a local model is being trained and has not qualified yet.
Why it exists. The model is the flexible part. Everything around it exists so that its flexibility cannot become authority.
In the recorded example
The model chose two steps: run the solver case, then open the engineering panel.
Stage 4 of 9
Proposal
Whatever the model suggests is collected into a ToolProposal. A proposal is data, not an instruction, and it grants no authority. Plans are capped at four steps and stop at the first step that cannot be verified.
Why it exists. Separating “what the model wants” from “what is allowed” is the line between a chatbot and a system you can trust with a computer.
In the recorded example
Proposal: engineering.solve(case = thermal_bench), then hud.widget(open engineering).
Stage 5 of 9 Can stop the request
Policy
The proposal enters the governance chain. The E-stop is checked first and again later. A tool outside the granted set is refused. The policy engine is fail-closed: any unexpected error becomes DENY. Twelve action classes, such as sending, deleting and printing, always need the owner’s approval, bound to the exact object and time-limited. Every decision is written to a hash-chained audit trail.
Why it exists. This is the single door every effect has to pass through, whatever its origin: conversation, mission, automation or gesture.
In the recorded example
engineering.solve was allowed under the owner’s standing authorisation. The route still asked the policy engine, because a check that is skipped when a yes is expected is a check that cannot fail.
Stage 6 of 9 Can stop the request
Action
Only now does anything happen. The executor normalises the command, works out the state it expects afterwards, reads the world before acting, then performs the effect.
Why it exists. Deciding in advance what success looks like is what makes the next step, checking, meaningful.
In the recorded example
The reference heat-engine bench solver ran the thermal_bench case as run-8a6b69c66acd4dbe.
Stage 7 of 9 Can stop the request
Observation
The effect’s own “done” is thrown away. JARVIS observes the world again and compares it with the expectation. The result is VERIFIED only if they match; REJECTED, UNVERIFIED, FAILED or REFUSED halts the plan.
Why it exists. An application saying “done” is not evidence that the job is done.
In the recorded example
Both steps came back VERIFIED: the solver’s values were published, and the engineering panel was open.
Stage 8 of 9
Evidence
A receipt records the outcome as true, false or unknown and goes into an append-only evidence store. Results carry their provenance: which run, which solver, which software revision, and what kind of number it is. The answer then says only what the record supports.
Why it exists. Every later claim, including the ones on this website, should trace back to a receipt rather than to a memory of one.
In the recorded example
Four values labelled calculated, not measured, with their uncertainty, the solver name and the software revision. The spoken answer: “Check. Done. The engineering widget is up.”
Stage 9 of 9
Memory update
Anything worth keeping is written through one door, the MemoryRouter, which records where it came from, how confident it is and when it is valid. Corrections supersede old facts instead of overwriting them, and forgetting is governed and visible to the owner.
Why it exists. A system that remembers badly repeats stale facts with confidence, and cannot really forget.
In the recorded example
In the same session: “Remember that the website launch footage was recorded tonight on monitor two”, recalled word for word, then forgotten on request. Asked again, JARVIS said: “I don’t know. You asked me to forget the earlier information, so I no longer retain it.”
What this adds up to
The model proposes; the runtime disposes. Nothing reaches the world without passing the policy gate, nothing counts as done until the world has been read back, and nothing is remembered without a record of where it came from. That is the difference between an assistant that talks and a system that can be trusted to act.
Not everything here is proven to the same standard: each stage shows its own status. What is still missing is on the limitations page.