JARVIS’s HUD has been rebuilt several times. The June prototype had 454 surfaces. A July rewrite replaced 1,060 scripts with four. On 5 September 2026 the project landed slice A of the ONE HUD: one page served at / on the loopback HUD port, with the intelligence core at the centre, identity above it and four permanent indicators. Workspaces became layout contexts inside that page, not separate windows. This entry is about the rule that page follows. The layout matters less.
The rule
The HUD specification (docs/hud/HUD_BIBLE.md) states it in one line: “Nothing renders without a source and an observed instant.”
In the page, every telemetry cell carries data-source and data-observed attributes. Every widget payload carries a source and an observed_utc. Several consequences follow, each written into the project’s truth map (docs/hud/Z11_TRUTH_MAP.md):
- Missing data is absent, not zero. A value nobody measured is shown as unavailable. It is never shown as
0, and never as LIVE. - Stale data is labelled stale. It may not be re-serialised with a new timestamp to look fresh.
- Completed-unverified is never green. If an effect returned but the observer could not read it back, the HUD shows COMPLETED-UNVERIFIED. A failed rollback shows ROLLBACK FAILED / OWNER ACTION, never success.
- Backpressure drops readings, never events. A superseded reading may be skipped under load. An event may not.
The constitution puts the reasoning plainly. A panel showing that a capability is not wired is more faithful than one showing an unmeasured 22.5 °C. A NO_SYNTHETIC_DATA test fails the build if any panel renders a hard-coded or placeholder value.
Colour encodes truth, and never alone
Colour follows the truth distinction. Computed or simulated values are cyan. Measured, physically verified values are amber with a check. Green means verified, healthy or complete. Red is reserved for critical, denied, unsafe or E-stop. Status is never conveyed by colour alone. Every state has a text label, so a colour-blind reader, a screen reader and a screenshot in greyscale all get the same information.
Who controls the surface
The HUD cannot introduce a state the server does not allow. The body is always in one of 21 named states, such as LISTENING, CONFIRMATION_REQUIRED, EXECUTING, DEGRADED, PRIVACY_LOCKED and ESTOPPED. Each of the 30 registered widgets has a presentation state (dormant, peek, expanded, focused or pinned) that the server’s PresentationController must permit.
Five protected surfaces can be dismissed or covered by no origin except the owner: approvals, E-stop, identity, provenance and recording. A model proposal cannot hide the approval queue. A heuristic cannot demote a widget the owner placed. Owner actions from the page post to the same command spine as everything else and read the E-stop first.
The page polls GET /one/state once a second and declares the link lost after three misses. Server-sent events were considered and rejected so the HUD would not tie up the core’s single worker.
What has been measured
Accessibility is part of the contract.
- axe-core, 12 September: 62 views, 0 WCAG A/AA violations. Automated rules, headless browser.
- Keyboard walk, 18 September: 58 views at 2560×1440 and 1920×1080, 0 findings, and all four deliberately planted controls detected. The planted controls matter because they show the instrument can find a problem. A zero from a scanner that has never caught anything proves nothing. The project’s method file says so: “Prove a scanner catches something before trusting its zero.”
- Readability, 12 September: 3,276 checks for small, clipped or low-contrast text, 0 findings.
- Reduced motion: one still frame per state.
Performance was measured in a diagnostic native shell (WebView2), not yet in the launcher’s own kiosk:
- input-to-visible latency p95 of 5 ms against a 50 ms budget (13 September);
- a sustained 229.67 fps on a 240 Hz display, with a worst second of 223 fps;
- a 30-minute soak with every attributed memory slope negative (RSS about -144 MB/h, heap -7.5 MB/h), 56 samples and 0 errors.
The soak record also states the limit of one of its own channels. Frame-time drift read UNSETTLED, because the page’s frame sampler delivered 600 frames in its first interval and none afterwards, which is what an occluded or backgrounded window looks like to Chromium. The probe now records page visibility and focus so the release soak can distinguish the two cases.
The number that is not good
The project scores its HUD on twelve fidelity categories, and the gate requires every category above 9.0. The most recent recorded mean is 2.43, with a minimum category of 1.42. The gate is not met.
This site publishes that number because the project does. Three qualifications apply. The scores come from independent read-only reviewers, so they are judgements, not instrument readings. The ledger records them against an earlier surface. And the ONE HUD’s own performance acceptance (docs/hud/ONE_HUD_ACCEPTANCE.md) still reads “NOT YET MEASURED”. Better accessibility and soak numbers do not offset the fidelity score. It measures something else: how close the surface is to the design the owner wants, and the answer today is not close.
Status
On 16 September the capability model drove widget open, close-all and close-except live on the owner’s machine and classified the HUD category PROVEN_LIVE. Recovery after a lost link was not driven live. The registry’s HUD rows are TESTED and have decayed to NOT_PROBED_THIS_PASS. The HUD instrument artifacts were stamped against sources that later moved, and the project re-measures them rather than re-stamping them. The critical path calls re-stamping “the fabrication the auditor exists to catch.”