JARVIS runs on one owner-built desktop: a 12-core AMD Ryzen 9 9900X, an NVIDIA RTX 5070 with 12 GB of VRAM, and 32 GB of RAM on Windows 11. Speech recognition, the voice, the HUD and every local model experiment share that one GPU. That limit shapes the architecture as much as any design principle. This page describes the main parts, how they run, and how the project decides what is true about itself.
Brain and body
The architecture draws a hard line between cognition, which proposes, and the body, which acts under governance.
The brain is the cognition pipeline. It classifies each utterance into a lane, resolves references, builds a budgeted prompt and asks a language model what to do. Today that model is hosted and reached through one ProviderGateway, which is also the only route for outbound calls and enforces an egress allowlist. Whatever the model returns becomes a ToolProposal, which is data with no authority.
The body is everything that changes the world: windows and applications, the browser, files, engineering tools, missions and the printer door. Every body command lives in one canonical command table. The capability registry derives one entry per command (“derived, never authored”). Each entry has a grant state and a manifest declaring its risk level, cost class, concurrency and cancellation behaviour. The model can choose among these commands but cannot add one.
Why draw the line so hard? The model is the least predictable part of the system, and on current plans it is also the part most likely to be replaced. If authority lived in the model, every model change would be a safety change. Instead, the policy engine, approval registry, E-stop and memory router stay outside any model. The local model runtime is designed to slot in behind the same provider path without changing any of them. The design also keeps memory and changing personal facts outside model weights, where they are retrieved at runtime. The HUD is driven by a runtime state contract and never by HTML a model generated.
Runtime processes
A launcher starts three child processes: the core (command spine, governance, stores and API), the HUD and the conversation process (the voice loop). All three run inside a Windows Job Object set to kill on close. If the launcher dies, no orphaned process is left acting on the machine.
A supervisor checks liveness every 3 seconds. It restarts failed children with exponential backoff capped at 30 seconds, for at most 5 restarts. After that, the system reports DEGRADED instead of thrashing. Boot proceeds in stages. Config, governance, memory, audio, speech and listening are required. Desktop, camera, providers and HUD are optional, and a failed optional stage leaves the system DEGRADED and labelled as such. Every service binds to the loopback address only. See health and recovery.
The HUD is one page served on a loopback port. It runs in a browser kiosk or in a small Python shell on the system WebView2. Electron and Tauri were rejected because of their GPU cost on a card that also has to hold speech and language models.
The truth pipeline
The project’s central discipline is that a claim about a capability must be backed by dated evidence. The pipeline runs in this order:
- Probe. A bounded probe runs the real code path against a real booted JARVIS process on an isolated loopback diagnostic port.
- Evidence. The probe writes an evidence artifact to disk.
- Registry. The capability registry records the state. A LIVE state older than 24 hours decays automatically to NOT_PROBED_THIS_PASS.
- Certification. A wiring map and a generated certification matrix summarise the registry.
- HUD. Every value shown carries its source and the instant it was observed.
Several safeguards keep this honest. Every adapter carries a flag saying whether it is a test double, and a probe that touched one can yield IMPLEMENTED at most. The final gate re-probes a random 25% of LIVE capabilities from scratch, and a single mismatch restarts certification. The constitution lists what does not count as live proof: code existing, imports succeeding, a unit test passing, a mock returning success, a route being registered, “it worked last week”, or a subagent saying it was done.
The registry was last set on 17 September 2026, so every LIVE reading on this site is historical. The project also keeps other status records: a capability model driven on the owner’s machine on 16 September 2026, sixteen acceptance journeys, and a body evidence matrix. This site maps all of them onto one truth ladder and names the source on every status line. The registry itself has a small inconsistency: it holds 342 entries, but its totals say 341 because one entry has no declared group.
Production and the Advanced Systems branch
Two bodies of code are described on this site, and they are kept apart:
| Production | Advanced Systems | |
|---|---|---|
| What it is | The branch JARVIS runs from | Six parallel development lanes integrated onto one branch |
| Last reference point | Commit 893913a9c, 21 September 2026 |
Commit f0738a5b9, 22 September 2026 |
| Merged? | n/a | No |
| Examples only here | n/a | Capability discovery, browser frames and shadow roots, Obsidian projection, Failure Atlas, FreeCAD STEP operations, the 3D scene store, specialist contracts |
Advanced work is labelled “not merged into production” on every page. Its own lanes use stacked status labels that apply only within each lane, and its “live” proofs ran on synthetic fixtures such as boxes, cylinders and disposable windows. Of 857 rows in its requirements matrix, exactly one is COMPLETE. Most of its commits after 19:50 UTC on 22 September are marked pending and untested, because a language-model measurement hold began on the shared GPU at that time.
Why the diagrams here are simplified
The flow diagrams on this site compress real code paths, and it is worth knowing where they compress. The governance chain in code checks the E-stop at several points, not once. Approvals are consumed inside the policy decision rather than after it. “The validator” is really several separate mechanisms. Modules whose runtime wiring is uncertain are drawn as modules, not as running services. These include the hybrid retriever, the staged boot sequencer’s run method, the PHOENIX and HELIOS health components, and the design council and red team. When a diagram and a status line disagree, the status line is the claim.
What is not proven yet
- Live readings have expired. Every registry LIVE state dates from 17 September 2026 and has decayed under the project’s own 24-hour rule.
- No release qualification. The release row is still active, the final gate has not passed, and the certification matrix reads “JARVIS-READY-V1: NO”.
- Recovery under fault is implemented, but the live chaos matrix has not been run. Survival across a real machine reboot is not proven. A process kill is explicitly not accepted as a substitute.
- The local brain has no qualified candidate. Production cognition is hosted. See training.
- Advanced Systems work is unmerged, largely unfinished against its own matrix, and partly untested after the measurement hold began.
- Some wiring is uncertain. It is unclear whether several implemented modules are constructed by the production runtime at all.