ADAPTIVE-WP-0009: correct stale completion note; answer inbound
T02-T04 were completed 2026-08-18; the draft-8 outcome section still said they were outstanding. Replies sent to railiance-platform (section 11 correction accepted; tier-P-floor trigger accepted as ours, narrowing our earlier blanket monitoring caveat) and tenant-engine (grouping unaffected, Q5 ownership agreed, plan-derived ceiling interface welcomed as new scope). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex
parent
4076700fad
commit
29223d39b7
1 changed files with 77 additions and 20 deletions
|
|
@ -4,23 +4,25 @@ type: workplan
|
|||
title: "Tenancy Posture alignment — tier assurance claims"
|
||||
domain: financials
|
||||
repo: adaptive-pricing
|
||||
status: active
|
||||
status: finished
|
||||
owner: codex
|
||||
topic_slug: helix-forge
|
||||
created: "2026-08-17"
|
||||
updated: "2026-08-17"
|
||||
updated: "2026-08-18"
|
||||
state_hub_workstream_id: "ac4f4540-75a1-4dbf-9cb7-57e5be97499f"
|
||||
---
|
||||
|
||||
# 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),
|
||||
(`net-kingdom/canon/standards/tenancy-posture_v0.1.md`, proposed / draft-8),
|
||||
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).
|
||||
and own the typed tier constraints that `railiance-platform` reconciles during
|
||||
placement (§8.2). The earlier standing co-signature proposal was declined and
|
||||
is no longer the policy.
|
||||
|
||||
## Position
|
||||
|
||||
|
|
@ -78,6 +80,29 @@ 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-8 outcome (2026-08-17)
|
||||
|
||||
All six surviving findings were adopted, with one useful refinement to finding
|
||||
4: no record is a copied derivative. The tier definition is authoritative for
|
||||
its typed minimum and wording; the service declaration is authoritative for
|
||||
current posture; the provider declaration is authoritative for available
|
||||
infrastructure. Approval joins them and fails closed on stale or missing input.
|
||||
|
||||
The framework now has V0–V4 availability, sanctioned honest language for
|
||||
E3/P2/R2/V1, an R-plus-P rule for retention promises, P2 or an enforceable
|
||||
governor for performance-differentiated tiers, and downgrade propagation to
|
||||
dependent tier owners. §8.2 records the declined co-signature and its typed
|
||||
constraint replacement.
|
||||
|
||||
T01 is complete in root `tenancy.yaml`. It declares the local observatory at
|
||||
I0/A0/E0 and P/R `n/a`, rather than using `n/a` to hide its unauthenticated
|
||||
single-user HTTP surface. T06 is complete because the amendments are in
|
||||
draft-8. T02–T04 were completed on 2026-08-18: the typed `assurance_claims`
|
||||
block, the hard boundary constraint and the tier-definition approval gate are
|
||||
all in place, with the suite green. No current model carries an assurance
|
||||
claim, so the absence is a declared capability gap rather than a live
|
||||
over-claim.
|
||||
|
||||
## Draft-6 update (2026-08-17)
|
||||
|
||||
The framework moved to **draft-6** (`net-kingdom` commit `2744ce7`) after this
|
||||
|
|
@ -160,7 +185,7 @@ Findings 6–7 are new, from draft-6 itself.
|
|||
|
||||
```task
|
||||
id: ADAPTIVE-WP-0009-T01
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "870c32dc-89dd-415f-b45f-f9484dd5119b"
|
||||
```
|
||||
|
|
@ -168,7 +193,7 @@ state_hub_task_id: "870c32dc-89dd-415f-b45f-f9484dd5119b"
|
|||
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
|
||||
The honest answer is that the datastore 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
|
||||
|
|
@ -176,18 +201,17 @@ adaptive-pricing has none. It does hold customer-attributable commercial data
|
|||
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`.
|
||||
Completed in `tenancy.yaml`. P and R are `n/a` because there is no runtime
|
||||
datastore. I/A/E/V are zero with reasons because the local observatory HTTP
|
||||
surface exists and has no authentication, authorization, tenant enforcement or
|
||||
availability position. A repo-level row of `n/a` would have concealed that
|
||||
surface.
|
||||
|
||||
## Extend The Canonical Schema With Assurance Claims
|
||||
|
||||
```task
|
||||
id: ADAPTIVE-WP-0009-T02
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "4420edb0-c9ea-4d2c-850e-2435cbd57f34"
|
||||
```
|
||||
|
|
@ -197,7 +221,7 @@ Add an **optional** `assurance_claims` block to the canonical pricing schema
|
|||
|
||||
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
|
||||
(`{I,A,E,P,R,V}`), the
|
||||
delivering service, and an evidence reference.
|
||||
|
||||
Constraints:
|
||||
|
|
@ -209,11 +233,17 @@ Constraints:
|
|||
- Do not extend `commitments` for this. A commitment is something the customer
|
||||
owes; an assurance claim is something we owe them.
|
||||
|
||||
Completed 2026-08-18. `PricingModel.assurance_claims` is optional and defaults
|
||||
to an empty tuple, preserving every existing silent tier. The validator checks
|
||||
claim identity, kind, customer wording, typed in-range axis minima, delivering
|
||||
service, evidence, erasure horizon and mechanism. The canonical shape and its
|
||||
definition-time semantics are documented in `docs/PricingModelSchema.md`.
|
||||
|
||||
## Add Boundary-Engine Validation For Claims
|
||||
|
||||
```task
|
||||
id: ADAPTIVE-WP-0009-T03
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "96c3340d-2429-4901-800c-2c7144ab14f4"
|
||||
```
|
||||
|
|
@ -234,11 +264,17 @@ 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.
|
||||
|
||||
Completed 2026-08-18. The hard `assurance-claims` boundary constraint is silent
|
||||
for tiers without claims and produces axis- and section-specific failures for
|
||||
the E4/P3 coupling, shared-substrate erasure horizons, R4 wording,
|
||||
key-destruction language, performance governors and availability failure scope.
|
||||
Focused and full-suite regression coverage is green.
|
||||
|
||||
## Gate Claims At Tier Definition
|
||||
|
||||
```task
|
||||
id: ADAPTIVE-WP-0009-T04
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "9821bc6b-d8ec-41e2-b4ea-ebf1f2dc91a6"
|
||||
```
|
||||
|
|
@ -252,11 +288,18 @@ 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.
|
||||
|
||||
Completed 2026-08-18. `assess_tier_definition_assurance()` compares the new
|
||||
tier definition with its previously approved definition and emits blocking
|
||||
approval requirements only for added, changed or removed claims. Each gate
|
||||
carries the claim's evidence reference. An unchanged definition proceeds, and
|
||||
the API explicitly warns publication/campaign callers not to turn it into a
|
||||
recurring gate.
|
||||
|
||||
## Answer Q5 And Q2
|
||||
|
||||
```task
|
||||
id: ADAPTIVE-WP-0009-T05
|
||||
status: wait
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "3aa82ae3-4a79-4a18-a74e-668e94652ecd"
|
||||
```
|
||||
|
|
@ -264,8 +307,8 @@ state_hub_task_id: "3aa82ae3-4a79-4a18-a74e-668e94652ecd"
|
|||
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.
|
||||
for isolation, retention and availability once T02/T03 land. V now supplies the
|
||||
availability vocabulary; the typed mapping still waits on implementation.
|
||||
`tenant-engine` owns which plan a tenant holds; this repo owns the terms — state
|
||||
that split when replying so the seam is recorded.
|
||||
|
||||
|
|
@ -294,11 +337,22 @@ a repo with no on-call. Propose it is railiance-platform's.
|
|||
|
||||
Reply on the State Hub to message `6d5293ca-4f69-46a6-a78e-b469e626b83d`.
|
||||
|
||||
Completed 2026-08-18. Q5 is implemented as the typed `assurance_claims`
|
||||
artifact: adaptive-pricing owns the authoritative tier wording and minima;
|
||||
tenant-engine owns assignment of a tenant to the tier id and does not copy the
|
||||
terms; railiance-platform joins current service/provider declarations during
|
||||
placement reconciliation. The current three Coulomb tiers remain explicitly
|
||||
silent and therefore define no minima. Q2 remains declined: placement has one
|
||||
owner and a machine-enforced artifact boundary, not a nominal co-signature.
|
||||
railiance-platform owns trigger monitoring because adaptive-pricing has no
|
||||
runtime/on-call surface. The implementation answer was sent on State Hub after
|
||||
the full suite passed (54 tests).
|
||||
|
||||
## Contribute Framework Amendments Back
|
||||
|
||||
```task
|
||||
id: ADAPTIVE-WP-0009-T06
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "489cffb7-9ec3-4335-a93c-0b276a843f8d"
|
||||
```
|
||||
|
|
@ -336,3 +390,6 @@ Proposed amendments:
|
|||
|
||||
Route via `policy-nexus` if it owns canon publication; otherwise direct to
|
||||
`rapp-postgres` as the raising agent and `net-kingdom` as canon owner.
|
||||
|
||||
Completed in NetKingdom draft-8. All surviving findings were incorporated;
|
||||
finding 6 remains withdrawn as resolved by draft-7.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue