Accept root grant ADR and approved OpenBao delivery design
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 3s

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1029d-2c93-7500-a0e0-e3e089668b29
This commit is contained in:
tegwick 2026-10-03 19:01:13 +02:00
parent 0122db64fd
commit de4c4f84f5
5 changed files with 93 additions and 45 deletions

View file

@ -1,31 +1,33 @@
# Root-grant read contract v0.1
Owner: net-kingdom. Status: proposed implementation contract, 2026-10-03.
Tracks NK-WP-0045 and proposed [ADR-0017](../adr/ADR-0017-root-grant-custody-and-account-authority.md).
Owner: net-kingdom. Status: approved delivery design, 2026-10-03.
Tracks NK-WP-0045 and accepted [ADR-0017](../adr/ADR-0017-root-grant-custody-and-account-authority.md).
Schema: [custody-record v0.1](../../canon/schemas/custody-record_v0.1.schema.json).
Reference implementation and fixtures: [validator](../../tools/custody-record/README.md).
This contract prepares delivery; it does not accept the ADR, choose a live
endpoint, assign a custodian, or establish a real root grant. Fixtures are
The founder accepted ADR-0017 and selected the OpenBao design below. Delivery
and identity admission are pending; design acceptance does not assign a
custodian or establish a real root grant. Fixtures are
synthetic and must never seed the authoritative record.
## Read-surface decision (T04)
The founder's open decision `cef97ccd-4ee7-40fe-859e-1df9c9360ecb`
must accept/amend ADR-0017 and select one delivery surface and accountable repo.
user-engine has already confirmed the exact subject and envelope mapping
(message `60acf176`, recorded in USER-WP-0037-T02).
The founder explicitly accepted ADR-0017 and approved the proposed OpenBao
design. Scoped receipt: `c2cff929-91b9-4018-bfd6-fa04f7da8280`.
T01/T04 are done; bundled D10 `cef97ccd-4ee7-40fe-859e-1df9c9360ecb`
stays open for its separate MFA journey.
| Option | Delivering repo | Requirements and tradeoff |
| --- | --- | --- |
| OpenBao-held non-secret document | railiance-platform | Governed exact-path workload read, separate custody write lane, atomic revision updates; uses existing custody infrastructure but needs consumer identity admission. Recommended for review, subject to owner confirmation. |
| Private platform service | Named platform runtime owner | Authenticated bounded read, atomic document, custody write/audit lane, availability and recovery; adds a runtime to operate. NetKingdom supplies canon, not a new runtime by default. |
| Repository artifact delivered to workloads | Named artifact/distribution owner | Authenticated provenance, atomic publication, revision rollback protection and a refresh route for sensitive writes; an indefinitely cached checkout is insufficient. |
Selected delivery owner: **railiance-platform**, RPF-WP-0049. OpenBao KV v2
mount `platform`, API path `/v1/platform/data/custody/net-kingdom/platform-root`,
record ID `nk-custody:platform-root`, owner `net-kingdom-custody`. The complete
schema document is at response `data.data.document`; KV metadata version is
transport concurrency state, not the custody revision.
Decision receipt must name the surface, delivering repo, trusted record ID,
consumer identity mechanism, writer/custody approval lane and bootstrap
provenance. No endpoint, OpenBao path or access grant is invented here. If the
ADR changes, schema, validator and this contract must be reconciled before use.
user-engine reads through an authenticated exact-path read-only identity;
separate attended human custody writes publish whole-document CAS updates.
The actual user-engine runtime identity/auth binding, writer custody binding,
bootstrap provenance and live acceptance are still owner delivery requirements.
The producer packet is `railiance-platform/openbao/root-grant/README.md`.
## Producer requirements (T05)