ADAPTIVE-WP-0009: draft-7 review — finding 6 resolved, rest stand

Decision 5.3 makes n/a an admissible level, which is what T01 needed; withdraw
finding 6 and adopt tenancy.yaml rather than proposing a format. Findings
1-5 and 7 survive because section 11 is byte-identical across drafts 5-7 —
four repos reviewed and none touched the commercial section, which is ours.

Records the sellability read: with flex-auth at A0, apps-pg at R0 and
tenant-engine on SQLite, no tier can support an isolation, availability or
retention claim today. Notes that section 5.5 provider declarations mean
T02 must reference two levels, not one.

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

workplans/ADAPTIVE-WP-0009-tenancy-posture-alignment.md

@@ -42,6 +42,42 @@ rule that would catch a tier claiming isolation it cannot evidence. §11.3
 requires the mapping be "recorded once when the tier is defined" — this repo owns
 tier definition, so this repo owns the recording surface.
 
+## Draft-7 update (2026-08-17)
+
+Draft-7 (`net-kingdom` commit `357109b`) applies three more reviews —
+`audit-core`, `railiance-platform`, `flex-auth` — for eleven changes.
+
+**Finding 6 is resolved. Withdraw it.** Decision 5.3 makes `n/a` an admissible,
+conformant level, declared with a stated reason: "`P0` presupposes a database and
+`R0` presupposes retained data". This is exactly what T01 needed and it arrived
+from another repo's review. `tenancy.yaml` is also now the adopted convention for
+the declaration (from `flex-auth`), carrying `current`, `target`, `reviewed`,
+`gap`, `placement_exceptions`, `service_class`, per-path detail and — for a
+provider — the §5.5 provider declaration. **T01 no longer proposes a format; it
+fills in the one that exists.**
+
+**Findings 1, 2, 3, 4, 5 and 7 all still stand, and there is a reason.** §11 is
+byte-identical across drafts 5, 6 and 7. Four repos have now reviewed and none
+touched it, because §11 is the commercial section and this repo owns it. Nobody
+else was going to find these. That raises the priority of T06 rather than
+lowering it.
+
+**Every guessed posture has been too generous, on every repo that self-reported.**
+`flex-auth` is `I1 A0 E2 P n/a R n/a` — `/v1/check` authenticates no caller, so
+any workload with network reach can assert any subject and receive an
+authoritative allow. `apps-pg` is `I0 A0 E0 P n/a R0`, where `R0` means no
+backup configured at all. Combined with `tenant-engine` on SQLite, the
+commercial read is blunt: **no tier can support an isolation, availability or
+retention claim against the estate as it stands today.** Nothing is blocked
+because nothing claims — but nothing is sellable either, and that is the fact a
+tier author needs before drafting, not after.
+
+**Providers declare separately now (§5.5).** A provider states what it *makes
+reachable*; `apps-pg` provides `P1` while its own `P` is `n/a`. A tier's
+guarantee therefore depends on two declarations, not one — the provider's
+reachability and the consuming service's own level. T02's constraint artifact
+must reference both or it will validate against half the picture.
+
 ## Draft-6 update (2026-08-17)
 
 The framework moved to **draft-6** (`net-kingdom` commit `2744ce7`) after this
@@ -102,7 +138,9 @@ Findings 6–7 are new, from draft-6 itself.
 5. **§8.3.1 constrains pricing design directly.** Co-residents are equal and no
    resource governor exists, so a performance-differentiated tier is unsellable
    below P2. This is a pricing-model validation rule, not only an ops fact.
-6. **Off-ladder notation appears in a worked example.** Draft-6 records
+6. **~~Off-ladder notation appears in a worked example.~~ RESOLVED in draft-7**
+   by Decision 5.3 (`n/a` is a level, and it is conformant). Kept for the record.
+   Draft-6 records
    `tenant-engine` as `P—` (still on SQLite, below P0's meaning) and `R0/R1` (a
    dual value). Neither is on any ladder. This is the same wall T01 hit from the
    other side: the ladders have no way to say *not on this axis at all*, so the