From e8ebd5cdd24b7e97dcb0945c526a24c00b70b179 Mon Sep 17 00:00:00 2001 From: codex Date: Mon, 17 Aug 2026 18:09:13 +0200 Subject: [PATCH] Add ADAPTIVE-WP-0009: Tenancy Posture v0.1 alignment Responds to rapp-postgres review request on NetKingdom Tenancy Posture v0.1. Covers posture-vector publication, an assurance-claims extension to the canonical pricing schema, boundary validation, a tier-definition gate, and the Q5/Q2 answers. Records five findings against the framework for amendment while it is still proposed. Co-Authored-By: Claude Opus 5 --- ...PTIVE-WP-0009-tenancy-posture-alignment.md | 220 ++++++++++++++++++ 1 file changed, 220 insertions(+) create mode 100644 workplans/ADAPTIVE-WP-0009-tenancy-posture-alignment.md diff --git a/workplans/ADAPTIVE-WP-0009-tenancy-posture-alignment.md b/workplans/ADAPTIVE-WP-0009-tenancy-posture-alignment.md new file mode 100644 index 0000000..966e04c --- /dev/null +++ b/workplans/ADAPTIVE-WP-0009-tenancy-posture-alignment.md @@ -0,0 +1,220 @@ +--- +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.