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
@@ -231,12 +269,28 @@ availability** until finding 1 is resolved; say so rather than inventing a level
 `tenant-engine` owns which plan a tenant holds; this repo owns the terms — state
 that split when replying so the seam is recorded.
 
-**Q2 — placement co-signature.** Recommend **accepting, scoped**: co-signer means
-a veto on placement policy changes that would invalidate an existing tier's
-recorded minimum — not a seat in per-workload placement operations. §8.2's
-reasoning holds and the stated alternative is real (placement decided purely on
-operational grounds then constrains what can be sold), but unscoped co-signature
-on an ops decision puts a commercial repo in a ticket queue. Bernd's call.
+**Q2 — placement co-signature. Decided 2026-08-17 by Bernd: decline the
+signature, bind via artifact instead.**
+
+adaptive-pricing publishes tier minimums as typed constraints (T02/T03) and asks
+railiance-platform to validate placement against them. Ownership stays single;
+the check runs every time rather than when someone remembers to route it. §8.2's
+concern is right — placement decided purely on operational grounds does constrain
+what can be sold — but a signature is the wrong instrument for a constraint that
+is machine-checkable, and tier minimums are machine-checkable by construction.
+
+**No interim veto.** A scoped veto was considered and dropped: its only purpose
+would be protecting existing claim-bearing tiers, and there are none. Not being
+live is what makes the direct move safe.
+
+**Named revisit trigger** — if a tier carrying an isolation, availability or
+retention claim is drafted before the constraint artifact lands, reopen this
+decision rather than assume it. Declining must not be open-ended.
+
+Accept the P ladder, the triggers and §8.1's monitoring obligation
+unconditionally. Caveat to raise: §8.1 says triggers MUST be monitored and never
+says by whom; if that defaults to adaptive-pricing it is a standing obligation on
+a repo with no on-call. Propose it is railiance-platform's.
 
 Reply on the State Hub to message `6d5293ca-4f69-46a6-a78e-b469e626b83d`.