Refine AUDIT-WP-0008 open tasks against draft-8.

The framework moved from draft-5 to draft-8 while this workplan ran. No finding
was reversed, but three things changed underneath it: R moved to 2 once
rapp-postgres declared the window, a sixth axis V (availability) appeared, and
the implemented-versus-evidenced distinction became a schema field.

T03 reduces: the confirmation-oracle finding landed as Decision 4.5.3 and
question 11 is marked framework-resolved, so no amendment remains -- only our
own position document. The legal question routes to risk-nexus rather than
the-custodian, per §19.11 and policy-nexus INTENT.

T06 reduces to confirmation: all five findings were adopted and the two stale
status lines it was going to flag are already fixed.

T07 is new. V1 needs critical dependencies enumerated, restart recovery
exercised and recovery time measured. The 2026-08-16 reboot walk observed ~40s
of unreadiness but is not an exercise and does not enumerate the dependency set.

T08 is new and covers two defects in our own declaration. provider.R.available
quotes a 30-day horizon we do not solely control -- at P1 the horizon is the
instance maximum across co-residents. And under Decision 6.1, user-engine was
never told what we declared, which makes the declaration drift rather than a
completed change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/AUDIT-WP-0008-tenancy-posture-alignment.md

@@ -22,8 +22,18 @@ Answer the `rapp-postgres` review request against NetKingdom Tenancy Posture
 v0.1, declare an accurate posture vector, and close the one gap the assessment
 exposed in running code.
 
-Canonical framework: `net-kingdom/canon/standards/tenancy-posture_v0.1.md`
-(rendered copy in `policy-nexus/build/tenancy-posture.html`).
+Canonical framework: `net-kingdom/canon/standards/tenancy-posture_v0.1.md`,
+published by `policy-nexus` at `policy.coulomb.social`.
+
+> **Framework moved twice under this workplan.** The assessment below was made
+> against **draft-5**; the framework is now at **draft-8**. The assessment still
+> holds — no finding was reversed — but three things changed underneath it:
+> `R` moved 1 → 2 once `rapp-postgres` declared the window, a sixth axis **V
+> (availability)** appeared that we had no position on, and the
+> implemented-versus-evidenced distinction we used informally for `E` became a
+> schema field. `tenancy.yaml` tracks draft-8 and validates clean against
+> `net-kingdom/tools/tenancy-posture/validate.py`. T07 and T08 exist because of
+> draft-8, not because of the original review.
 
 ## Assessment — what the ladders say about us
 
@@ -331,20 +341,24 @@ status: todo
 priority: high
 state_hub_task_id: "0003954e-5033-457f-b9aa-97efdefe9beb"
 ```
-Answer question 11 in `docs/erasure-and-audit.md`: the fact/payload split, the
-encrypt-then-hash constraint, the confirmation-oracle finding, and the R2-not-R4
-target. Record as an audit-core position; send the §4.5 condition to NetKingdom
-as a framework amendment.
+Answer question 11 in `docs/erasure-and-audit.md`.
 
-**Name the legal dependency explicitly and route it.** The document must state
-that declining to build erasure rests on audit evidence being exempt under legal
-obligation or legitimate interest, that this is a legal conclusion, and that no
-one in the estate is recorded as having reached it. Route that question to
-`the-custodian` for an owner rather than closing it here — audit-core is not
-competent to answer it and should not appear to have. The position is publishable
-with the dependency open; it is not publishable with the dependency hidden.
+**Reduced by draft-8.** The framework half is already resolved upstream: the
+confirmation-oracle finding landed as **Decision 4.5.3**, and §19.11 is now
+marked *framework resolved*, recording that audit-core targets R2 and is
+explicitly not a fleet R4 target. There is no amendment left to send. What
+remains is audit-core's own position document — the fact/payload split, the
+encrypt-then-hash constraint, why the retained cleartext hash defeats key
+destruction, and the R2 ceiling — so the reasoning lives in this repo rather
+than only in someone else's canon.
+
+**Route the legal question to `risk-nexus`, not `the-custodian`.** §19.11 ends
+"the legal basis for retaining audit facts remains a risk/legal question outside
+this framework", and `policy-nexus` INTENT records that judging what an external
+rule demands of the estate moved to `risk-nexus` on 2026-08-17. That is the
+owner. The position is publishable with the dependency open; it is not
+publishable with the dependency hidden.
 
-```task
 id: AUDIT-WP-0008-T04
 status: done
 priority: high
@@ -375,9 +389,65 @@ status: todo
 priority: medium
 state_hub_task_id: "ed58ca37-755b-4284-b1ac-2a02baaceb21"
 ```
-Send the five framework review findings to `net-kingdom` (owner of the canon
-path) and `policy-nexus` (owner of the rendered copy), as a §20.2 review
-response rather than as objections.
+Close the review loop with `net-kingdom`.
+
+**Mostly overtaken.** All five findings were adopted across draft-7 and draft-8,
+and the two stale status lines this task was going to flag are already fixed.
+Nothing is outstanding as a *finding*.
+
+What remains is confirmation rather than argument: acknowledge the adoptions,
+confirm the §5 worked example `I1 A2 E1 P1 R2 V0` is accurate as written, and
+state that `tenancy.yaml` validates clean against
+`tools/tenancy-posture/validate.py`. Flag one thing forward — the E line becomes
+wrong the day T05 lands, and under Decision 6.1 an *upgrade* has no notification
+duty, so the correction is ours to send unprompted or it will simply sit stale.
+
+```task
+id: AUDIT-WP-0008-T07
+status: todo
+priority: high
+```
+Reach **V1** on the availability axis, new in draft-8.
+
+We declared `V0` because nothing exercises restart recovery for the complete
+audit path. §13's V1 row asks for three things and they are all mechanical:
+critical dependencies enumerated, restart/recreate recovery exercised, and the
+interruption plus measured recovery time recorded. Decision 4.6.1 makes V
+end-to-end, so the enumeration must include `platform-pg` and the credential
+path — a receiver that restarts in 5s over a database that takes 90s is not V1
+at 5s.
+
+The 2026-08-16 reboot walk in the operator runbook is close but is not this: it
+observed ~40s of unreadiness after a node reboot, without enumerating the
+dependency set or recording a measured recovery time as an exercise. Decision
+4.6.1 is explicit that a replica count or a status page is not evidence.
+
+Write the exercise procedure and the dependency enumeration here; the exercise
+itself runs against railiance01 and needs a live window.
+
+```task
+id: AUDIT-WP-0008-T08
+status: todo
+priority: high
+```
+Disclose the shared-substrate retention coupling in our **provider** block, and
+notify `user-engine` under Decision 6.1.
+
+Two defects in our own declaration, both found by reading draft-8 back against
+`tenancy.yaml`:
+
+- **`provider.R.available: 2` is misleading as written.** It tells a sender it
+  gets a 30-day horizon. At P1 the horizon is the *instance maximum* across
+  co-residents (§4.5), so a co-resident declaring longer silently extends what
+  we hand our senders. Decision 4.5.4 makes exactly this the reason a bare `R2`
+  minimum is insufficient. We are not a tier, but we are a provider quoting a
+  number we do not solely control, and the provider block must say so.
+- **Our consumers were never told.** Decision 6.1: updating `tenancy.yaml`
+  without notifying dependants is declaration drift, not a completed change.
+  `user-engine` is the only sender and has not been told that `E4` and `R4` are
+  unreachable here, nor that current `E` is 1. This is not a downgrade — it is a
+  first accurate declaration replacing someone else's generous guess — but the
+  notification duty is the same and the guess was public.
 
 ## Done when
 
@@ -390,4 +460,9 @@ response rather than as objections.
 - The §5 worked example for `audit-core` is corrected upstream.
 - Two dates are recorded and monitored per §8.1 rather than merely written:
   `data.archive` review 2026-12-31, E3 target 2027-03-31.
-- The erasure legal question has an owner outside audit-core.
+- The erasure legal question has an owner outside audit-core (`risk-nexus`).
+- `tenancy.yaml` validates clean against the normative validator, and keeps
+  doing so as the framework revises.
+- V1 is evidenced by an exercise, not asserted from a restart policy (T07).
+- The provider block discloses what it does not solely control, and every
+  consumer of `operations.audit` has been told what it declares (T08).