A system that cannot describe its own condition will eventually report something false with confidence. JARVIS treats health as a truth problem first and a repair problem second. It must say accurately how healthy it is, repair only what is safe to repair, and hand everything else to the owner.
One headline from many signals
Different parts of the system report health in their own vocabularies. The health module folds 11 source vocabularies into five states:
| State | Plain-language reading |
|---|---|
| LOADING | Starting up |
| READY | Working |
| DEGRADED | Working with something missing, and saying what |
| UNAVAILABLE | Not working, or no trustworthy reading |
| RECOVERY_LOOP | Repeatedly failing to recover |
One rule governs the fold: “A reading without a measurement time is reported as UNAVAILABLE rather than assumed healthy.” A health value with no timestamp might be minutes or days old. Treating it as current would make a silent failure look healthy. Capability health and freshness also reach capability discovery and the HUD, so what JARVIS says it can do reflects what is working now.
Boot stages
Startup runs in stages. Required stages are config, governance, memory, audio, speech and listening. Optional stages are desktop, camera, providers and HUD. If a required stage fails, JARVIS does not pretend to be ready. If an optional stage fails, the system comes up DEGRADED and says which part is missing.
Governance is required and comes early. A JARVIS that could act but could not govern its actions is not a safe partial state. A JARVIS without a camera is.
The project also has a staged boot sequencer module. Whether the production runtime calls its run method is uncertain, so this page describes the stages as the designed order rather than a proven startup trace.
Supervision
A launcher starts the core, HUD and conversation processes inside a Windows Job Object set to kill on close. If the launcher goes away, its children go with it, and no orphaned process keeps acting on the machine.
Liveness is checked every 3 seconds. A failed child is restarted with exponential backoff capped at 30 seconds, for at most 5 restarts. After that, the system settles into DEGRADED, “not thrashing”. Endless restarts can hide a real fault and consume resources the owner is using. A clearly reported degraded state is more useful.
Resilience primitives
Beneath supervision sit smaller safeguards:
- Circuit breakers open after 5 failures within 30 seconds, so a failing dependency is not hammered.
- Retry budgets limit how much retrying any operation may do.
- An idempotency cache lets a repeated request return the original result instead of repeating the effect.
- A quality-of-service layer never defers interactive work, and defers background work when resources are contended. The owner’s request always goes first.
Self-healing, within limits
The healer performs only actions that are reversible and that measurably improve health: restarting, reconnecting, re-indexing, recovering and falling back. It escalates to the owner after 3 attempts in an hour, and every action is audited.
Why these limits?
- Reversibility means a wrong repair can be undone.
- Measured improvement means a “repair” that changed nothing is not counted as a fix. The project’s method notes put it this way: “A repair is a claim and needs its own test”. That lesson is listed as not yet enforced by a test.
- The escalation limit stops the healer from masking a persistent fault by repairing it over and over.
Other maintenance components follow the same discipline. SENTINEL raises falsifiable hypotheses about faults, keeps irreversible changes behind owner approval, and turns caught failures into regression-test candidates. PHOENIX “does not act on an unobserved fault”, so it will not repair something it has only inferred. LATENCY ALCHEMIST reports latency percentiles and marks a result INCONCLUSIVE when the difference is within noise, rather than claiming a speed-up.
The wiring of PHOENIX and HELIOS is uncertain. They appear to run only in probes and tests, so they are described here as implemented modules, not running services.
Recovery after a restart
After a restart, JARVIS produces a recovery report. Resumable missions are offered with their cursor and are never resumed automatically. Steps whose outcome cannot be determined stay UNRESOLVED. A corrupt memory store refuses to open rather than pretending to be empty. See memory.
Degraded, not silent
When a dependency disappears, the rule is a truthful degraded state, not silence. For example, the constitution’s scenario for losing the internet has JARVIS announce the degradation once, switch to local paths, and report nothing falsely as LIVE.
What is not proven yet
- Live readings are historical. The health, diagnostics and runtime-service readings date from 16 and 17 September 2026.
- Recovery under real faults has not been proven live. The chaos matrix that would inject failures into a running system is still owed.
- Surviving a machine reboot is not proven. A process kill is explicitly not accepted as a substitute.
- Self-healing is implemented, not live-proven. No live repair is cited here.
- PHOENIX, HELIOS and the boot sequencer’s run path have uncertain production wiring.