Commit Graph
2 Commits
Author SHA1 Message Date
Scott KarpandClaude Fable 5.1 ec8cdc840b L1Integrity: the ten-minute re-reading runs beside the witness, not in it
On the production node a reading of the scroll takes about three
seconds (3310 ms at first start; 0.9 s on the build host). The periodic
re-reading ran inside the GenServer, so once every ten minutes every
cycle and every readiness probe that asked "is L1 intact?" would have
waited those seconds behind it.

The periodic reading is now done by a task that reports back; the
process goes on answering from its last reading meanwhile. The first
reading is still made in the process itself — nobody is answered before
the scroll has been read once — and an explicit recheck/0 is still
synchronous. The next reading is scheduled when one begins, not when it
reports, so a reading that dies silently is not the last.

Two tests: it re-reads on its own in both directions (altered → fail,
restored → tov), and a status call during a periodic reading returns at
once. 484 tests, 0 failures on seeds 0 7 42 99.

Built image, run with a live-mounted scroll: l1_hash pass, /peah/ask
200; then אחד in Devarim 6:4 was changed to אחר while the vessel ran
and the witness asked to read again — L1_INTEGRITY_FAILED, l1_hash
fail, /peah/ask 503.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-04 19:42:37 +00:00
Scott KarpandClaude Fable 5.1 bbe2c4b7ba L1: the integrity check reads the scroll (tablet 38)
L1Reader.verify_integrity/0 read the hash stored in integrity.sha256
and compared that string with the hash compiled into the module. It
never opened a verse. On that comparison of a constant with its own
copy rested `l1_hash: pass`, the Cloud's "L1 corrupted — the cloud is
not visible", and Construction §1.2. A changed verse would have passed
every one of them. Every existing test passed too, because every test
asked about an untouched L1.

- L1Reader.compute_tree_hash/1: SHA-256 over every file under torah/ —
  relative path, then bytes — in the order scripts/build_l1.py hashed
  them (directories by path, files by name, plain string order). On the
  real L1 it yields the pinned 156b1d27…; for a tampered copy it yields
  the same hash the Python implementation does.
- VavPipeline.L1Integrity (new, supervised): reads and hashes the scroll
  when the pipeline starts (~0.9 s in the image) and again every ten
  minutes; logs and signals the assembly when the answer changes.
- verify_integrity/0 now requires BOTH: the recorded hash is the pinned
  one, AND the scroll on disk hashes to it (answered from the witness's
  last reading; computed on the spot where the witness is not running).
  Callers are unchanged — the Shema context, the health check and the
  status endpoint all inherit the real check.
- scripts/verify_l1.py: the same reading by hand. KOHEN.md and
  KOHEN_PROMPT.md used the hollow comparison as their L1 gate; they now
  run this.
- test/tablet38_l1_integrity_test.exs — 9 tests: the hash and its
  order; one byte / one added file / one rename each change it; the
  witness; and the whole path — with an altered scroll and an untouched
  integrity.sha256, verify_integrity fails, health says l1_hash: fail,
  and /peah/ask does not answer.

Specs: architecture §2.2 (which had been made to confess the hollow
check in d7520cd) and Construction §1.2 now describe the real one — and
its limit: a change is noticed within ten minutes, not at the instant.
deploy/ARCHITECTURE.md likewise. Doorpost @expected_hash 7e5286b9… →
3f6d47a0…, in this commit, with the witnessed files that moved it
(architecture, vayakhel).

Read before committing: Elixir 483/0 on seeds 0 7 42 99 191243. The
built image, run twice: on the engraved scroll — "read and matches
(928ms)", l1_hash pass, /peah/ask 200; on a copy with ONE LETTER changed
in Bereishit 1:1 and integrity.sha256 untouched — L1_INTEGRITY_FAILED,
l1_hash fail, cloud not readable, /peah/ask 503.

Not done: the Haskell side. Luchot.Firmware.l1ExpectedHash is compared
with nothing; the engine reads L1 without hashing it (that would need a
SHA-256 dependency). The engine is reached only through the pipeline,
which now gates every cycle on the real check.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-04 19:37:40 +00:00