JARVISLabs

A corrected fact survives a real restart, and a forgotten one stays forgotten

On 12 September JARVIS was given a standing instruction, restarted, asked to recall it, corrected, and asked again. It recalled the correction in all three drives. 'Forget' failed twice before a repair and then answered 'I don't know.'

LIVE-PROVEN What this run supports. Recorded 12 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

Remember how a project's fixture repository is tested, recall it after a restart, accept a correction, then forget it.

Result

What happened

Before a real stop and relaunch, the owner stated how a synthetic project's fixture repository is tested. After the restart JARVIS recalled it, citing the earlier instruction. A correction ('pytest -x not pytest -q') superseded it, and the next recall said 'pytest -x.' A request to forget revoked every standing instruction on that subject, and the following recall was 'I don't know.'

Pipeline

Architecture path

  1. Owner statement
  2. MemoryRouter write (origin-stamped)
  3. Real stop and relaunch
  4. Recall from store
  5. Correction supersedes
  6. Forget revokes by subject
  7. Recall answers 'I don't know'

What this proves

  • A standing instruction given before a real restart was recalled after it.
  • A correction superseded the earlier value, and the corrected value was recalled in 3 of 3 drives.
  • After the repair, forgetting revoked both the original and the correction, and absence produced uncertainty instead of a guess.

What it does not prove

  • Forget-on-request succeeded in 1 of 3 drives. The 1-of-3 figure is the raw result, not a post-repair rate.
  • Recorded on 2026-09-12; a recorded run is not a current reading.
  • Synthetic project names were used. This is not a measurement over the owner's real memory at scale.

Context

JARVIS has one path for writing memory, the memory router, and every write carries its origin. A correction does not overwrite an old value. It supersedes it, and the change propagates to derived rows and caches. Forgetting is governed: it has to reach everything that was derived from the forgotten item. Acceptance journey J4 tests the whole behaviour: “a correction supersedes an old memory; deletion propagates to ordinary retrieval and caches; absence yields uncertainty.”

The run

The drive used the normal launcher with the conversation loop, hosted cognition and the typed inlet, on a synthetic project. The sequence was:

  1. The owner gave a standing instruction about how the project’s fixture repository is tested.
  2. JARVIS was stopped and relaunched. This was a real restart, not a reload inside the process.
  3. The recall answered “…tested with pytest -q. Based on your earlier instruction.”
  4. The correction “pytest -x not pytest -q” superseded it, and the next recall said “pytest -x.”
  5. “Forget what I told you about how the … fixture repository is tested” revoked every standing instruction on that subject, and the recall after it was “I don’t know.”

Across three drives, the first recall and the post-correction recall were correct every time.

What failed first

Forgetting did not work at first. In the first two drives, the forget request revoked only the original instruction, and the correction kept answering. The repair made the forget forms reach the memory path, made revocation name its subject by content-word overlap, and revoked every instruction on one subject together. The third drive passed. The benchmark keeps the raw result, 1 of 3, rather than reporting a post-repair rate.

The evidence

Journey J4 in docs/orders/post-lm/ACCEPTANCE_JOURNEYS.json records the drive and the repairs. The commit 299c10c0 marked journeys 2, 3, 4 and 12 LIVE across a real restart. The drive’s evidence files are local and not published. No footage exists yet.

The limits

All journey readings predate the source of 17 September, so the project does not treat them as proofs of the current tree. The registry’s memory rows remain IMPLEMENTED, because its own probes found no production entry point when those states were set. This drive therefore sits alongside the registry as separate evidence. It does not replace it.