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 <noreply@anthropic.com>
This commit is contained in:
codex
parent
44ca743b9a
commit
e8ebd5cdd2
1 changed files with 220 additions and 0 deletions
220
workplans/ADAPTIVE-WP-0009-tenancy-posture-alignment.md
Normal file
220
workplans/ADAPTIVE-WP-0009-tenancy-posture-alignment.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue