JARVISLabs

500 verified browser reads, then a replaced target refused

On 22 September, on the unmerged Advanced Systems operator branch, 500 read-only target reads in an isolated Chromium verified in 2.81 s across a restart. A same-label replacement was then refused as target_missing_or_replaced. The pages were fixtures.

INTEGRATED What this run supports. Recorded 22 September 2026.

Footage pending

This run is documented from its recorded evidence. Footage has not been published: capture waits for the machine to be free of local model measurements, and every clip is reviewed for private information first.

Asked

What was asked

Keep reading the same page element reliably, and refuse to act if that element has been swapped for a look-alike.

Result

What happened

An isolated Chromium loaded a fixture scenario. JARVIS's DOM scene reader resolved a target and performed 500 read-only reads of it, each verified, in 2.81 s, including across a restart. The fixture then replaced the element with one carrying the same label. The next target check returned STALE with reason target_missing_or_replaced and authority NONE.

Pipeline

Architecture path

  1. Isolated Chromium
  2. DOM scene reader (frames, shadow roots)
  3. Target resolution
  4. dom-target-check/1 per read
  5. Restart
  6. Same-label replacement
  7. STALE: target_missing_or_replaced

What this proves

  • On the operator branch, target continuity held for 500 verified reads and survived a restart.
  • An element replaced by a same-label look-alike is detected and refused, not clicked.
  • The check reports observation state only; it carries no click authority.

What it does not prove

  • This is branch work that is not merged into production.
  • Fixture pages in an isolated browser are not the owner's real browsing.
  • Read-only: typing and filling on this path are still pending validation.
  • Not a mixed-application mission and not release-qualified; the proof record says so itself.

Context

Browser automation often fails quietly when a page changes underneath it. The element the agent found a second ago has been re-rendered, replaced or covered, and a click lands on something else that happens to have the same label. Production JARVIS drives the owner’s Chrome semantically, by role and accessible name, but it has no awareness of iframes or shadow DOM. The Advanced Systems operator lane added a DOM scene reader that records relationships across frames and shadow roots. It also added a target check, dom-target-check/1, that compares the current observation with the one the target was resolved from.

Two rules from that work shape the result: “CSS viewport rectangles are observation data, never native screen leases” and “CURRENT/STALE is an observation comparison, never click authority.”

The run

The proof ran on the operator branch at head 75135f029, in a real isolated Chromium with a fixture scenario:

  • 500 read-only target reads were verified in 2.81 s.
  • A restart was performed, and continuity was verified afterwards.
  • The fixture then replaced the target with a same-label element. Read 501 returned status: STALE, reason: target_missing_or_replaced, authority: NONE, with the previous and observed scene digests recorded.
  • The fixture store was removed after the proof.

The evidence

The proof record binds the exact source files by SHA-256 and states its scope in its own fields: full_jarvis_live: false, mixed_application_mission: false, release_qualified: false, training_eligible: false. Seven planned variations of a failing scenario (paraphrase, changed state, a competing target and others) are listed as pending and were not executed. No footage exists yet.

The limits

This is branch work. It is not reachable from production until canonical integration, so this site marks it INTEGRATED, not LIVE-PROVEN. The pages were fixtures, the reads were read-only, and the proof does not show JARVIS typing into or submitting anything. It shows one specific refusal working: a look-alike element was not treated as the original.