The census answers no, three receipts found, and the prune was on file all along

CENSUS (read-only, hub store, tester's machine not contacted): no machine that is
not ours can be in the state that cost demo-felhom its history. The hub holds
escrow for three hosts; both demo boxes lost their pre-fix key in the same four
hours on 2026-08-04; peti-felhom and david have no host row and no escrow at all.
A control ran FIRST and had to pass -- the query returned "present (572 bytes)"
for a host known to have material and "absent (NULL)" for one known not to.
Corrected my own instrument on the way: a date-only comparison mislabelled both
losses as after the fix, so the in-force moment is now pinned from the hub's first
post-fix escrow row (11:11:37Z), which independently agrees with the register.

PART 1 ESTABLISHED. The prune is recorded inside R-267 -- the row about the
Configuration page being slow -- because pruning artifacts is what made that page
fast. Arithmetic checks (23+7=30, plus three versions that only surfaced after the
first thirty moved them onto page one = 33) and the PAGINATED listing shows both
generics at exactly ten. R-291's blocking condition is released: the operator was
being asked to establish something already written down. And my counter-argument
yesterday was wrong in exactly the way R-267 warns about -- "containers hold 19"
came from an unpaginated query; paginated they hold 270 and 169.

RECEIPTS: three restored (drives.enrol, backup.tier1, fail.lost-recovery-code),
each citing the document that walked it; the map already read PROVEN-LIVE for all
three, so this follows the map rather than raising a status in the view. NINE
HONEST GREYS. fault.selfheal's best hit argues against it -- an incident recording
self-heal's absence through a 1h15m outage.

THE DECAY RULE FIRED FOR THE FIRST TIME. backup.restore-proof has a receipt from
28 July and is superseded anyway: demo-hp's restore-test failed 5 August and the
box has since been rebuilt. A claim about a continuing behaviour cannot rest on an
old observation. The capability map still reads PROVEN-LIVE and is now the thing
out of step -- recorded, not silently rewritten.

PART 4 specified, not implemented. The orphan card promises restorability the box
rendering it cannot evaluate: the discriminator is on the hub and no wire field
carries it. A conditional promise the system cannot evaluate is the same defect as
an unconditional false one, so the copy stops promising, says what happens, and
names a route. Ships with the next controller change so one bake covers both.

documentation/architecture/where-felhom-stands.yaml

@@ -240,17 +240,20 @@ claims:
     band: journey
     stage: 4
     title: "A new drive is found, offered, formatted, mounted and enrolled — including on awkward older boot layouts"
-    status: built
+    status: walked
     note: "Applies to a NEW drive. Re-attaching an existing one after a reinstall is R-280 and fails."
     sources:
       - capability-map: "Drive wizard: scan/format/mount/enroll, incl. legacy-boot LVM-root hosts"
       - register: "R-220"
+      - evidence: "audits/SPIKE-raw-drive-enroll-2026-06-15.md"
     changed:
-      from: walked
-      reason: "the 2026-08-09 walk exercised RE-attach (which failed, R-280); first-enrolment of a NEW drive has no walk on file"
+      from: built
+      also_moved: 2026-08-09 walked -> built
+      reason_superseded: "the 2026-08-09 walk exercised RE-attach (which failed, R-280); first-enrolment of a NEW drive has no walk on file"
+      reason: "receipt found 2026-08-10: a live throwaway drive on felhom-pve walked scan -> format -> mount -> PVE dir storage -> one-click Regisztralas, with the resulting storage.cfg entry and systemd mount unit recorded. The map already read PROVEN-LIVE; the dataset was behind it. Scope unchanged: this is a NEW drive. Re-attaching an existing one after a reinstall is R-280 and still fails."
     verified:
       date: 2026-08-09
-      verdict: downgraded
+      verdict: upgraded
       depth: source-read
   - id: drives.migrate
     band: journey
@@ -297,16 +300,19 @@ claims:
     band: journey
     stage: 5
     title: "App data on the machine, nightly database dumps, a copy on a second drive"
-    status: built
+    status: walked
     sources:
       - capability-map: "Tier-2 secondary-drive copy: class-driven legs"
+      - evidence: "audits/CAMPAIGN-8-backup-restore-2026-07-27.md"
     changed:
-      from: walked
-      reason: "no walk document cited"
+      from: built
+      also_moved: 2026-08-09 walked -> built
+      reason_superseded: "no walk document cited"
+      reason: "receipt found 2026-08-10: an adversarial, destructive, unattended overnight campaign across both boxes and ep0, with A2 (one quiesce, two tiers) proven end to end. Map already read PROVEN-LIVE."
     verified:
       date: 2026-08-09
-      verdict: downgraded
-      depth: register+map
+      verdict: upgraded
+      depth: source-read
   - id: backup.whole-machine
     band: journey
     stage: 5
@@ -348,6 +354,7 @@ claims:
     changed:
       from: walked
       reason: "no walk document cited, and the last recorded restore-test on demo-hp FAILED (2026-08-05)"
+      decay: "PROOF-DECAY RULE FIRED (first time it has). A receipt EXISTS - architecture/_recovery-inventory-2026-07-28.md carries live journal lines for scheduled restore-tests on both boxes and both tiers - but it is superseded by later observation: demo-hp logged restore_test_failed on 2026-08-05, and the box has since been wiped and reinstalled (2026-08-09). The claim is about a CONTINUING scheduled behaviour, so a 2026-07-28 observation cannot carry it. Stays grey until a scheduled restore-test is seen passing on the rebuilt box. THE CAPABILITY MAP STILL READS PROVEN-LIVE (2026-08-03) AND IS NOW THE THING OUT OF STEP."
     verified:
       date: 2026-08-09
       verdict: downgraded
@@ -621,17 +628,20 @@ claims:
   - id: fail.lost-recovery-code
     band: failures
     title: "The customer loses their recovery code — by design, the data is unrecoverable"
-    status: built
+    status: walked
     note: "The recovery screen states it in Hungarian."
     sources:
       - capability-map: "Escrow ceremony: customer-facing wizard, one-shot R claim, operator zero-knowledge"
       - register: "R-198"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
     changed:
-      from: walked
-      reason: "a by-design refusal; no walk document cited"
+      from: built
+      also_moved: 2026-08-09 walked -> built
+      reason_superseded: "a by-design refusal; no walk document cited"
+      reason: "receipt found 2026-08-10, and then proven the hard way: the recovery screen states in Hungarian that nobody can replace a lost code, and on 2026-08-10 demo-felhom's pre-fix key was confirmed unrecoverable by construction (identity_blob NULL; the restic password lives only in that bundle). The by-design refusal is real."
     verified:
       date: 2026-08-09
-      verdict: downgraded
+      verdict: upgraded
       depth: source-read
   - id: fail.moves-house
     band: failures