coulomb/railiance-platform
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Finish RPF-WP-0018; RPF-WP-0019 repository-complete
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
RPF-WP-0018 closed: all seven tasks done. The provider-declaration finding
was adopted upstream and its canonical form is the provider: block in
tenancy.yaml; adaptive-pricing declined the standing co-signature and
supplied typed tier minima instead, recorded in ADR-0002. Three corrections
against our own output are recorded in the documents rather than edited
away.

RPF-WP-0019 T03 done (ceiling of three, memory binding, apps-pg-2 named as
overflow, enforced by make apps-pg-verify-capacity). T01/T02 are
repository-complete: backup target, retention, per-consumer connection
limits, role timeouts and Burstable resources are declared in source and
published in s3-consumer-interfaces 1.1.0 before rollout. They stay in
progress because no live application, backup success or restore proof
exists, and declared configuration is not a section 13 artifact. T04 waits
on that window.

apps-pg R reason corrected to say the target is declared-not-applied rather
than absent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-08-18 13:35:04 +02:00
parent e52ae26001
commit dc4245361d
20 changed files with 650 additions and 73 deletions
Download patch file Download diff file Expand all files Collapse all files

43
docs/tenancy-posture.md
View file

@ -2,9 +2,13 @@
Work record: `RPF-WP-0018` T01
Declared: 2026-08-17
Framework: `net-kingdom/canon/standards/tenancy-posture_v0.1.md` (draft-5, proposed)
Framework: `net-kingdom/canon/standards/tenancy-posture_v0.1.md` (draft-8, proposed)
Contract version of this document: `1.0.0`
Machine-readable source: `tenancy.yaml`. This document preserves the review
reasoning; where a snippet and the root declaration differ, `tenancy.yaml` is
authoritative.
This is `railiance-platform`'s response to the Tenancy Posture ratification
test (§20.2): *"Each publishes its own posture vector as part of review. The
framework is validated by whether it can describe them accurately."*
@ -55,8 +59,8 @@ surface to the `rapp-*` repos while custody and policy stayed here.
tenancy:
service: apps-pg
role: storage-provider
current: { I: 0, A: 0, E: 0, P: null, R: 0 }
target: { I: 0, A: 0, E: 0, P: null, R: 2 }
current: { I: 0, A: 0, E: 0, P: "n/a", R: 0, V: 0 }
target: { I: 0, A: 0, E: 0, P: "n/a", R: 2, V: 1 }
service_class: interactive
reviewed: "2026-08-17"
gap:
@ -70,7 +74,7 @@ tenancy:
concept, carries no tenant claim, and applies no tenant predicate. The
tenant boundary for data on this cluster sits entirely in the consuming
S5 application. See the provider note below."
- "P is null rather than a number. See §P-axis note."
- "P is n/a rather than a number. See §P-axis note."
```
### `forgejo-db` — dedicated cluster for the forge
@ -79,8 +83,8 @@ tenancy:
tenancy:
service: forgejo-db
role: storage-provider
current: { I: 0, A: 0, E: 0, P: null, R: 0 }
target: { I: 0, A: 0, E: 0, P: null, R: 2 }
current: { I: 0, A: 0, E: 0, P: "n/a", R: 0, V: 0 }
target: { I: 0, A: 0, E: 0, P: "n/a", R: 2, V: 1 }
service_class: interactive
reviewed: "2026-08-17"
gap:
@ -97,8 +101,8 @@ tenancy:
tenancy:
service: openbao
role: credential-provider
current: { I: 0, A: 0, E: 0, P: 0, R: 0 }
target: { I: 0, A: 0, E: 0, P: 0, R: 1 }
current: { I: 0, A: 0, E: 0, P: 0, R: 0, V: 0 }
target: { I: 0, A: 0, E: 0, P: 0, R: 1, V: 1 }
permanent: [I, A, E]
service_class: latency-critical
reviewed: "2026-08-17"
@ -145,7 +149,7 @@ great deal, it is central, and it is mechanically evidenced —
it *can* sign with `ssh/sign/agt-role`, and asserts it *cannot* read policy
metadata, then revokes by accessor. That is exactly the shape §13 asks for at
`A2`: choke point identified, unbound request refused. It is pointed at the
**consumer** boundary, and none of the five axes has anywhere to put it.
**consumer** boundary, and none of the tenancy axes has anywhere to put it.
That evidence is therefore cited under the provider statement rather than
against a consumer axis. Consumer separation in OpenBao is structural — a
@ -164,7 +168,7 @@ owner per consumer, and the triggers. The numbers — `instances: 1`,
`max_connections: 100`, `1Gi`, `retentionPolicy: 30d` — are `rapp-postgres`'s
cluster CR and its declaration to make.
## The P-axis note — why two entries are `null`
## The P-axis note — why two entries are `n/a`
The P ladder describes **which substrate holds a tenant's data**, from the
point of view of the workload whose data it is. `apps-pg` and `forgejo-db` are
@ -173,14 +177,18 @@ well-formed answer: `apps-pg` *provides* P1 to each of its consumers, and
`forgejo-db` *provides* P2 to forgejo, but neither *is* at a level.
Declaring `P: 1` for `apps-pg` would read as though the cluster had a
placement, and a later reader would use it to argue about isolation. `null`
plus the provider statement is the accurate form. This is routed as a finding.
placement, and a later reader would use it to argue about isolation. `n/a`
plus the provider statement is the accurate canonical form.
## Finding routed to `net-kingdom`
## Finding adopted by `net-kingdom`
**The five ladders describe a consumer of storage. They do not describe a
**The six ladders describe a consumer of storage. They do not describe a
provider of it.**
**Resolved in draft-7 and formalised in draft-8.** Decision 5.5 adopted the
provider declaration; the draft-8 schema standardises `available`, `maximum`,
conditions and evidence per axis. The canonical form is now in `tenancy.yaml`.
**Narrowed on re-reading, 2026-08-17.** An earlier version of this finding
claimed the framework had no way to say "this zero is structural, not weak".
That was wrong: §6 says exactly that, and §13.1a supplies the mechanism —
@ -208,15 +216,16 @@ rather than a tenant one. A reader scanning a table of E values would rank
OpenBao below a service doing per-query filtering in application code, which
inverts the actual security position.
**Proposed amendment, offered as the first correction from review rather than
**Proposed amendment at draft-5, offered as the first correction from review rather than
from research (§Status observes that every correction so far came from research
or relocation):** add a **provider declaration** beside the posture vector — a
platform service states, per axis, the maximum level it makes reachable and
what the consumer must do to reach it. For `apps-pg` that is: E4 unreachable
(shared credential per consumer, no per-tenant credential), E3 reachable once
the GUC contract exists, R2 blocked on a backup target. That is the sentence a
consumer actually needs, and no arrangement of the five consumer ladders
produces it.
consumer actually needs, and no arrangement of the consumer ladders produces
it. Draft-8 adopted and standardised that amendment; the root declaration is
now authoritative.
This is offered as an addition, not a replacement. The consumer vector is
right for consumers, and this repo is not asking for the ladders to be