# REPORT — the census, the receipts, and a promise we should stop making (2026-08-10)

Documentation and one read-only census. **No code that runs on a customer's machine, no deploy, no
bake.** Both demo boxes are online and were not changed. **The tester's machine was not contacted** —
only its hub-side record was read, and it has none.

---

## 1. Part 2's answer, first

> **No. A machine that is not ours cannot be in the state that cost demo-felhom its history — not
> today, and not for anything enrolled from now on.**

The hub holds escrow for **three** hosts. Both demo boxes lost their pre-fix key in the same four-hour
window on 2026-08-04; that is the entire affected population and it is entirely ours. `peti-felhom`
has **no host row and no escrow at all**, and neither does `david`. Anything enrolled from here escrows
under the fixed code, which has been in force since 2026-08-04.

## 2. The census, and the control that came first

**Control (run before the census, and it had to pass or the census was worthless):**

```
demo-felhom-8363b5  host_escrow             -> present (572 bytes)   want present   OK
demo-felhom-8363b5  host_escrow_superseded  -> absent (NULL)         want absent    OK
control PASSED: the query distinguishes both states on known cases.
```

| host | current | superseded | material | superseded_at | verdict |
|---|---|---|---|---|---|
| `demo-felhom-8363b5` | 572 B | id=4 | **ABSENT** | 2026-08-04 07:20:08 | old backups lost (before the fix) |
| `demo-hp-bb76ea` | 572 B | id=3 | **ABSENT** | 2026-08-04 07:15:36 | old backups lost (before the fix) |
| `drill-r50-0a4f9a` | none | 0 | – | – | no supersession has happened |
| `peti-felhom` | — | — | — | — | **no host record, no escrow** |
| `david` | — | — | — | — | **no host record, no escrow** |

An orphan check found no escrow row pointing at a host the hub does not know.

**One correction I made to my own instrument.** The first run labelled both losses *"superseded AFTER
the fix — unexpected"*, because a date-only comparison puts `2026-08-04 07:20:08` after `2026-08-04`.
The in-force moment is pinned instead from the hub's own first post-fix escrow row — **11:11:37Z** —
which independently agrees with the register's *"four hours before v0.93.0 fixed the retention"*. Both
losses are then correctly *before* the fix: explained, not anomalous.

**What this does NOT claim:** that a *retained* blob has ever been unwrapped on a superseded row.
Retention is proven; recovery **from** a superseded row remains unexercised.

## 3. Part 1 — the deleter is ESTABLISHED, and it was on file all along

The locator was correct: the record is **inside the R-267 row** — *"Pruned to the newest 10 per package
on the operator's rule, with the live-vouched golden/agent/floor asserted into the KEEP set before a
single DELETE was issued; 33 deletions, all HTTP 204."*

Every corroboration checked and every one holds:

- **The arithmetic:** 23 agent + 7 golden = 30, plus three older agent versions (0.81.0/0.80.0/0.79.0)
  that *"only became visible after the first 30 deletions moved them onto page one"* = **33**.
- **The live PAGINATED listing** — 14 pages, 653 package-versions — `felhom-agent` generic at **exactly
  10**, `felhom-golden` generic at **exactly 10**. That is what a newest-10 prune leaves.

The midnight-cleanup candidate is retired, and **R-291's blocking condition is released**: the operator
was being asked to establish something already written down.

**My counter-argument yesterday was wrong, in precisely the way R-267 warns about.** I argued against
the prune because *"container packages hold 19 each"*. That came from an **unpaginated** query the API
caps at 50/page. Paginated, they hold **270** and **169** — they were never in the prune. R-267 records
the identical trap one paragraph above the sentence I could not find: *"An unpaginated listing is not
evidence of a total — this repo's own rule, walked into while measuring."*

## 4. Part 3 — the twelve

**Three restored. Nine honest greys.** The map already read PROVEN-LIVE for the three, so the dataset
was *behind* it — restoring follows the map rather than raising a status in the view.

| claim | outcome |
|---|---|
| `drives.enrol` | **RESTORED** — `audits/SPIKE-raw-drive-enroll-2026-06-15.md`: a live drive walked scan → format → mount → PVE storage → one-click enrol, with the resulting `storage.cfg` entry and mount unit recorded |
| `backup.tier1` | **RESTORED** — `audits/CAMPAIGN-8-backup-restore-2026-07-27.md`: adversarial, destructive, unattended, both boxes + ep0; A2 proven end to end |
| `fail.lost-recovery-code` | **RESTORED** — `audits/REHEARSAL-byo-reinstall-2026-08-09.md`, and proven the hard way on 2026-08-10 |
| `backup.restore-proof` | **grey — THE DECAY RULE FIRED** (below) |
| `install.installer-by-tag` | grey — hits are ISO spikes; nothing walks a tag rollback |
| `use.lifecycle` | grey — two passing mentions, no walk |
| `drives.migrate` | grey — one or two mentions only |
| `backup.whole-machine` | grey — diagnostics and phase findings, no walk of the claim |
| `fault.selfheal` | grey — **the best hit argues the other way**: `INCIDENT-guest-dhclient-killed-2026-07-20.md` documents self-heal's *absence* through a 1 h 15 m outage |
| `fault.operator-email` | grey — source-verified, delivery never observed |
| `fail.drive-filling` | grey — weak hits only |
| `fail.hub-down` | grey — Campaign 11's hub-unreachable work produced a *finding* (R-224), not a pass |

## 5. Did the "code moved under the proof" rule fire? **Yes — for the first time.**

`backup.restore-proof` **has** a receipt: `architecture/_recovery-inventory-2026-07-28.md` carries live
journal lines for scheduled restore-tests on both boxes and both tiers. It is superseded anyway —
demo-hp logged `restore_test_failed` on 2026-08-05, and the box has since been wiped and reinstalled.
The claim is about a **continuing** scheduled behaviour, so a 2026-07-28 observation cannot carry it.

**So the rule can fire, and now has.** Two nights ago it fired zero times out of twelve because every
downgrade came from *missing* evidence, not decayed evidence — there was nothing for it to bite on.
**A consequence to note: the capability map still reads `PROVEN-LIVE (2026-08-03)` for that row, so the
map is now the thing out of step**, and it is the source. Recorded rather than silently rewritten.

## 6. Part 4 — the promise, and why the wording is what it is

**Surfaces:**

| file:line | |
|---|---|
| `controller/internal/web/templates/backups_remote.html:101` | **the false promise** |
| `controller/internal/web/templates/backups_remote.html:98` | the orphan explanation — accurate, keep |
| `controller/internal/web/templates/layout.html:143` | the 14-day abandon countdown — accurate, keep |
| `controller/internal/settings/settings.go:337-338` | `OrphanedRenamedTo` schema comment — accurate, keep |

*(The capability map was searched and makes no such claim — nothing to correct there.)*

**The three cases:** set aside **before** the fix → not recoverable by construction (the restic
password lives only in the identity bundle, `escrow/identity.go:39` read by `escrow/recover.go:91`, and
those rows are NULL); set aside **after** → recoverable in principle, never demonstrated; **today's
population is entirely the first case**.

**The deciding fact: neither the box nor the customer can tell which case they are in.** The hub holds
the discriminator (`host_escrow_superseded.identity_blob`); the box caches only
`HubEscrowIdentityPresent`, which is about the *current* escrow; and **no field on the report or ACK
wire carries superseded-blob retention**. The box renders the card. **A conditional promise the
renderer cannot evaluate is the same defect as an unconditional false one** — so the specified copy
stops promising, says plainly what happens, explains why it cannot promise, and names a route
(write to us).

**Specification:** `documentation/design/SPEC-orphan-card-copy-2026-08-10.md` — copy, surfaces, and the
render tests that should pin it, including a regression guard that the string `visszaállítható lehet`
never returns. **Not implemented, on purpose:** it lands in the controller, and a controller release is
undelivered until a golden carries it (R-242). It should ship with the next controller change so one
bake and one approval cover both, and the spec says so.

## 7. Register

**Ceiling R-292 → R-294.** Opened **R-293** (the census) and **R-294** (the promise + spec). **R-287
turned to ESTABLISHED** with my unpaginated-count error withdrawn. **R-291's blocking condition
released.** **R-288 gained a second measured cost**, and it is a different failure mode from the first:
prose rows make claims ambiguous; rows-about-other-things make facts unfindable.

## 8. Observations — noticed, not acted on

- **The capability map is now out of step in two directions** — behind the dataset for three claims it
  already called PROVEN-LIVE, and ahead of it for `backup.restore-proof`. Both point at R-288.
- **`fault.selfheal`'s only real document argues against it.** Worth someone deciding whether the
  capability is real and unwalked, or overstated.
- **Retention is proven; recovery from a superseded row is not.** The census proves blobs are now kept;
  nobody has ever unwrapped one. That is the next thing worth a drill, and it needs no customer.
- The page now shows the three restored claims as **"moved twice"** rather than once, so an unsettled
  status reads as unsettled.