Product
Modes
FOCUS, NORMAL and JARVIS are projections of one mission state. Switching never restarts a mission.
EN This publication is published in English only. Site navigation is available in 18 languages.
FOCUS, NORMAL and JARVIS are three projections of one mission state. They are not three products, not three permission levels and not three event streams [D] (mission-control, S4).
| Mode | Renders | For |
|---|---|---|
| FOCUS | The current node, its gate state, and anything awaiting a human decision. Nothing else | The operator who needs to act, not to watch |
| NORMAL | Task graph, node states, cost and budget against the envelope, evidence sufficiency, the last events | The default supervisory view |
| JARVIS | Everything NORMAL renders, plus per-invocation records, capability bindings with their cost model reference, verifier verdicts, escalation reasons and refusal records | The engineer, the auditor and the incident |
Five rules, and each one is testable
- A mode is a filter over one projection. One event stream, one projection, one mission. A mode selects which elements render; it never selects a different source.
- Switching mode never restarts, re-plans, re-fetches or mutates a mission. Acceptance test: switch modes twenty times mid-mission; the event count is unchanged and the projection digest is identical.
- The event-backing rule holds in every mode. FOCUS renders fewer elements, never less-well-backed ones.
- A mode may not become an authority. Acceptance test: a principal without permission to read evidence sees the same redactions in JARVIS as in FOCUS. A view is not a grant.
- No mode exposes chain-of-thought. JARVIS is the densest operational view, not a reasoning view: it renders decisions and their recorded reasons, never generations.
Rule 5 is a boundary rather than a preference [A]. Reasoning tokens are excluded from the mission record by architectural decision, so there is nothing for a mode to expose: the record holds what was decided and the reason that was recorded, not the text the model produced on the way there.
Rule 4 is the one most often lost in implementation. A denser view looks like a more privileged view, and building it that way turns a UX control into an access-control mechanism sitting outside the Policy and Authority planes [A].