railiance-platform/openbao/root-grant

Approved platform-root producer design

Prepared for NK-WP-0045-T05 / RPF-WP-0049, 2026-10-03. Founder approved: "Accept ADR-0017 and approve the proposed OpenBao delivery design." Scoped made decision receipt: c2cff929-91b9-4018-bfd6-fa04f7da8280. This selects railiance-platform and the exact source below. Identity admission, attended live provisioning, custody provenance and live readiness remain pending. NetKingdom canon remains authoritative; reviewed baseline is net-kingdom commit de4c4f84f5043b97a205f1a72a26e77f8750d628. Deployments must pin the validator and its schema together, and reconcile amendments before publication.

Approved source and transport

• KV v2 mount: platform (existing owner convention; live suitability unverified).
• Exact API path: /v1/platform/data/custody/net-kingdom/platform-root.
• record_id: nk-custody:platform-root; owner_system: net-kingdom-custody.
• API response unwrap: data.data.document is the complete canon document. data.metadata.version is KV concurrency state, distinct from canon revision.
• Reader: user-engine only. Its repository currently has no deployed workload namespace/ServiceAccount, so no Kubernetes identity binding is claimed. User-engine must name its real runtime identity and an existing supported auth route. Platform admits it only after review. Reader policy is exact-path read; no list, sibling read or write. Never distribute an attended writer token.
• Writer: separate human custody lane, bounded attended MFA operator login, reviewed exact-path policy. This packet does not grant a credential or role.
• Reader timeout 5 seconds, maximum document 256 KiB. A successful authenticated owner read, not document time or a cache read, sets observed_at. Failure means no grant. No raw server response/error logging.

Offline implementation

scripts/root_grant_publish.py creates a single KV v2 CAS payload from a candidate, previous document, exact previous KV version and the pinned NetKingdom validator module. No network or publication is implemented here. It validates both documents, exact source identity and successor semantics; refuses missing existing baselines, same-revision changes and rollback. CAS=0 is bootstrap-only, CAS=current-version updates; a CAS conflict requires a fresh owner read and revalidation, never blind retry. It never prints documents.

The attended executor still needs implementation after actual reader/writer identity confirmation: suppress output, read document and KV version together, verify retained high-water mark, call preparation helper, write one complete payload, read back and compare, and emit non-secret revision/digest receipts. An unvalidated direct writer bypass is not an accepted delivery path. Policies alone cannot enforce the human ceremony, validator or global revision monotonicity.

Exact later live approval packet

After real consumer identity confirmation and final source preparation, request one explicit attended approval naming the reviewed platform and NetKingdom commits, exact mount/path/record ID, real reader auth binding, separate writer binding, audit owner, abort operator, window and provenance reference. Its bounded actions are: inspect existing mount and identity without values; configure exact-path admission and KV per-key CAS requirement; publish a human-reviewed initial document only from real ceremony evidence (or an explicitly approved empty baseline); verify authenticated reader success, anonymous/wrong-identity/parent-list/sibling/write denial and failed-read behavior; return only source ID, revision, content digest, actor/time/provenance references and pass/fail checks. No synthetic fixture can seed the authoritative record.

Acceptance also needs revocation/supersession exercise and rollback/restore receipts. Exercise real grant changes only under their own custody ceremony approval. Use isolated synthetic paths for non-live algorithm exercises.

History, recovery and audit

OpenBao audit is owned by railiance-platform; the custody fact and ceremony are owned by net-kingdom-custody. Confirm mount backup owner and restoration before calling this source live. Retain KV history and independent publication digest / revision high-water receipts. Readers persist their own trusted baseline across restart. A restored snapshot must not reactivate an older grant: suspend reads, compare restored record with independently retained latest baseline, reconcile all later custody actions, and re-enable only after owner receipts. Do not reset baselines, destroy versions or recreate an old record under the same ID. KV CAS prevents races, but is not proof against snapshot rollback. Retention settings and independent backup location remain an owner implementation gate.

No control was relaxed and no live action was taken. Emergent knowledge 0.2.3 start was withheld/orientation-only (digest 60f8811c6b94b30d357a0d9e5022f2a8ea52e69b47138d3a536755f3295310b5); source review read the-custodian agent-environment-orientation section 0 and informed-decision README, plus the source NetKingdom contract/schema/validator.

Producer delivery receipts complete RPF-WP-0049-T05 / NK-WP-0045-T05. Consumer integration and runtime acceptance follow in USER-WP-0037-T02 / NK-WP-0045-T06; they do not block initial producer delivery.