diff --git a/documentation/tests/finalwalk-r201-2026-08-07/journal.md b/documentation/tests/finalwalk-r201-2026-08-07/journal.md
index 51e0ed0..ddcbf4b 100644
--- a/documentation/tests/finalwalk-r201-2026-08-07/journal.md
+++ b/documentation/tests/finalwalk-r201-2026-08-07/journal.md
@@ -242,3 +242,56 @@ the guest's island address**, which is what a browser would do. Some **instrumen
 and are counted as such. They are not steps of the journey: none of them changed state, and none was
 needed to progress it. The distinction matters because conflating the two is how a walk claims a
 property it does not have.
+
+### §7's observation — the rebuilt, still-UNCLAIMED box
+
+Three questions, all answered from the hub's own log rather than inferred:
+
+**1. Does it report while unclaimed? YES.**
+`host-report from finalwalk-ed05d6 (1 guests, 4 storage targets, 1 backups, 0 restore-tests,
+1 pbs-snapshots, 12907 bytes)` at 05:12:04 local, and `Received report from finalwalk` at 05:13:03.
+
+**2. Does it declare the credential need? YES**, and the hub's other mechanism correctly declines to
+act on it — logged once a minute, from 02:59Z onward:
+
+> `offsite-delivery: finalwalk: self-heal REFUSED — the box DECLARES offsite.state=needs_credential;
+> internal/offsiteheal owns this remediation (it re-stages the stored credential before minting).
+> A second mechanism minting here would double-issue.`
+
+**3. Did the hub stage one unaided? YES, at 05:14:57 local (03:15Z):**
+
+> `offsiteheal: re-staged the stored one-time offsite secret for customer finalwalk (declared
+> needs_credential across 2 reports) — the box re-consumes on its next cycle; no provider credential
+> was minted`
+
+That is **~32 minutes after the rebuild**, consistent with the documented 2 × 15-minute report
+debounce, and **nobody touched anything**.
+
+**This is a stronger case than yesterday's.** On 2026-08-06 I pressed Re-issue 102 seconds after the
+self-heal had already fired and mistook my own button for the cause — the error that produced R-236
+and forced its withdrawal. Here the box was **pristine, rebuilt and not even claimed**, no operator
+action of any kind was taken, and the chain ran end to end on its own. R-236's withdrawal is now
+confirmed on the exact shape it was filed against.
+
+**4. And then the box COLLECTED it, on its own tick — the full loop, unaided:**
+
+```
+[offsite-apply] settle-gate: GO — at/above floor 0.156.0 (we are 0.203.0), no managed update running
+[offsite-apply] offsite configured for u629488-sub4@…:/home/felhom-repo (pending key escrow)
+[offsite-apply] credential retry: the staged credential was collected and the tier applied
+```
+
+The box's own settings went from **no `offbox` object at all** to `enabled: true`, host, user and
+`repo_path` populated, `escrow_state: pending`.
+
+**This is the first time that success line has ever been observed live.** It shipped in controller
+v0.203.0; the 2026-08-06 walk only ever produced its sibling — *"no unconsumed offsite password …
+(the box still declares a need; retrying)"* — before an operator intervened. Here the whole chain ran
+with **zero human action, on a box that has not even been claimed yet**:
+
+> declare → `offsite-delivery` declines and names the owner → `offsiteheal` re-stages after two
+> reports → the box's 5-minute retry collects it → the tier is applied.
+
+**That is R-218's consume half, R-236's withdrawal, and the previous walk's dead end 1, all settled by
+one unattended observation.** By the time the operator claims this machine in the morning, its
+off-site tier is already up — which is exactly the property the recovery journey needed and never had.