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

id	type	title	domain	repo	status	owner	topic_slug	created	updated
ADAPTIVE-WP-0009	workplan	Tenancy Posture alignment — tier assurance claims	financials	adaptive-pricing	proposed	codex	helix-forge	2026-08-17	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

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

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

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

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

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

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.