--- id: ADAPTIVE-WP-0009 type: workplan title: "Tenancy Posture alignment — tier assurance claims" domain: financials repo: adaptive-pricing status: proposed owner: codex topic_slug: helix-forge created: "2026-08-17" updated: "2026-08-17" --- # Tenancy Posture alignment — tier assurance claims Align `adaptive-pricing` with **NetKingdom Tenancy Posture v0.1** (`net-kingdom/canon/standards/tenancy-posture_v0.1.md`, proposed / draft-5), raised by `rapp-postgres` on 2026-08-17. The framework names this repo in three places: publish a posture vector (§20.2), map plan tiers to minimum levels jointly with `tenant-engine` (§19 Q5), and co-sign placement policy ownership with `railiance-platform` (§8.2 / Q2). ## Position **Nothing is blocked today.** All three models in `projects/coulomb-pricing/data/pricing-models.json` (`flat-899-eur-monthly`, `membership-plus-credits`, `membership-plus-overage`) are silent on isolation, availability and retention. §11 constrains only tiers that make such a claim, so the estate has no live over-claim to correct. This workplan is therefore **preparatory guard-rail work**: build the ability to express and validate an assurance claim *before* a tier is written that needs one. It is deliberately additive — no existing catalog entry, schema consumer or test changes meaning. **The gap is structural, not editorial.** `PricingModel` today carries `commitments` (untyped `kind`/`value`) and `eligibility` (free strings). Neither can express "this tier requires `E3 P2 R2`", and `validate_pricing_model` has no 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. ## Findings against the framework Raised for amendment, not as blockers. Detail belongs in T06. 1. **Availability has no ladder.** §11.3 and Q5 both require an availability claim to map to "a minimum level the delivering service actually holds", but the five axes are I, A, E, P, R — none is availability. §17 concedes it: "an availability floor belongs in §11's minimum-level vocabulary alongside isolation." The requirement exists; the vocabulary does not. The availability half of Q5 is **not answerable as written**. 2. **§11.4 prohibits without sanctioning an alternative.** An "another tenant cannot reach your data" claim requires E4, and E4 requires P3 (§3.2) — a dedicated cluster per tenant. Correct, but it makes the strongest claim the most expensive one, which is exactly the commercial pressure that produces the over-claim §11 guards against. A prohibition with no compliant wording beside it gets routed around. 3. **A retention claim needs a P floor, not just an R level.** Under §4.5 a consumer's erasure horizon is the maximum across co-residents, so a tier's retention promise can be broken by onboarding an unrelated customer, with no change to the tier or its holder. §18 routes this to the consumer review checklist; it also needs to bind the tier side, as the E4/P3 coupling does. 4. **Authority direction between tier and service is unstated.** Q5 puts the mapping in the tier definition; §5 puts `placement_exceptions` in the service's posture vector — and its own example says "see adaptive-pricing tier definition". Two records, no stated primacy, silent drift in both directions. 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. ## Publish The Repo Posture Vector ```task id: ADAPTIVE-WP-0009-T01 status: todo priority: high ``` Publish `adaptive-pricing`'s posture vector per §5 / §20.2, declared in-repo (Decision 5.1). The honest answer is that the five ladders do not fit: this repo is a design-time analysis and definition surface with **no runtime multi-tenant datastore**. §3.3 scopes the P and R ladders to "a service's primary datastore"; adaptive-pricing has none. It does hold customer-attributable commercial data (member ledgers, payment records, LTV scenarios) as repo JSON under the Coulomb proving ground — which is a data-handling fact worth stating, and not a tenancy posture. Declare `not-applicable` per axis with reasoning rather than forcing a row of zeros. §20.2 invites exactly this: "if a repo cannot express itself in these five ladders, the ladders are wrong and this document changes, not the repo." Report the finding as the framework asked to have it reported, and propose a `no-runtime-datastore` declaration form so other design-time repos are not pushed into a misleading `P0 R0`. ## Extend The Canonical Schema With Assurance Claims ```task id: ADAPTIVE-WP-0009-T02 status: todo priority: high ``` Add an **optional** `assurance_claims` block to the canonical pricing schema (`adaptive_pricing_core/pricing_models.py`, `docs/PricingModelSchema.md`). Shape: claim kind (`isolation` | `availability` | `retention` | `performance`), customer-facing wording, the minimum levels it requires (`{I,A,E,P,R}` — plus availability once §11.3's vocabulary exists), the delivering service, and an evidence reference. Constraints: - Optional and defaulted. Absent block = silent tier = unaffected, per §11. - Typed, not free-text — the point is that a validator can read it. - Records the *internal* minimum only. §11.2 leaves marketing language free; the customer-facing wording field exists so the two can be checked against each other, not so the ladder leaks into a price page. - Do not extend `commitments` for this. A commitment is something the customer owes; an assurance claim is something we owe them. ## Add Boundary-Engine Validation For Claims ```task id: ADAPTIVE-WP-0009-T03 status: todo priority: high ``` Extend `adaptive_pricing_core/boundary_engine.py` with explainable rules, in keeping with the existing explainable-validation design: - A claim present ⇒ minimum levels recorded and a delivering service named. - "Cannot reach" isolation wording ⇒ `E4`, and `E4` ⇒ `P3` (§3.2, §11.4). - Retention claim ⇒ an R level **and** a P floor sufficient for the promised erasure horizon (finding 3). On shared substrate the horizon is not ours to promise. - "Deleted data is gone" ⇒ `R4`, or a disclosed erasure horizon (§11.4). Where R4 is key-destroyed, the wording must not imply regulatory endorsement (§4.5). - Performance-differentiated tier ⇒ `P2` or above (§8.3.1, finding 5). Each failure must explain which axis and which framework section it answers to. A validator that says "non-conformant" without naming the axis reproduces the conflation §3 exists to end. ## Gate Claims At Tier Definition ```task id: ADAPTIVE-WP-0009-T04 status: todo priority: medium ``` Wire the claim check into `adaptive_pricing_core/governance.py` as an approval requirement, so §11.3's "recorded once when the tier is defined" is a gate rather than a convention. A tier acquiring or changing an assurance claim requires human approval with the evidence reference attached — consistent with SCOPE's rule that customer-visible pricing changes are never autonomous. Explicitly **not** per-campaign review. §11.3 says the review happens at tier definition; a gate that fires more often than that will be worked around. ## Answer Q5 And Q2 ```task id: ADAPTIVE-WP-0009-T05 status: wait priority: high ``` Blocked on T02/T03 for Q5, and on Bernd's decision for Q2. **Q5 — tier → minimum level mapping,** jointly with `tenant-engine`. Answerable for isolation and retention once T02/T03 land. **Not answerable for 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. Reply on the State Hub to message `6d5293ca-4f69-46a6-a78e-b469e626b83d`. ## Contribute Framework Amendments Back ```task id: ADAPTIVE-WP-0009-T06 status: todo priority: medium ``` Submit the §"Findings" items to `net-kingdom` while v0.1 is still `proposed`. Proposed amendments: - **An availability axis.** Prefer adding one over striking availability from §11.3/Q5, because §17's "no P1 tenant has HA" is a hard sellability fact that needs somewhere to live. Sketch: `V0` no position, `V1` restart recovery on a single instance (what `platform-pg` is today), `V2` replicated failover, `V3` multi-zone with declared RTO/RPO. Note the letter collision — `A` is Authorization — which is itself a small argument the framework should settle rather than inherit. - **A sanctioned fallback phrasing in §11**, naming what P2/E3 honestly delivers (noisy-neighbour behaviour, capacity predictability, an independent restore path) so a tier author has a compliant thing to say and not only a prohibition. This is the amendment most likely to prevent a real over-claim. - **A Decision in §4.5** binding a retention claim to a P floor, as §3.2 binds E4 to P3. - **A primacy statement** for finding 4: the tier definition is authoritative for the minimum; a service's `placement_exceptions` is derived and must reconcile against it. - **A `no-runtime-datastore` declaration form** for design-time repos (T01). Route via `policy-nexus` if it owns canon publication; otherwise direct to `rapp-postgres` as the raising agent and `net-kingdom` as canon owner.