Accept root grant ADR and approved OpenBao delivery design

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1029d-2c93-7500-a0e0-e3e089668b29

docs/adr/ADR-0017-root-grant-custody-and-account-authority.md

@@ -2,19 +2,19 @@
 id: NK-ADR-0017
 type: architecture-decision-record
 title: "The Root Grant Is Derived From the Custody Record, Scoped to tenant:platform, and Observed as Non-Secret Evidence"
-status: proposed
+status: accepted
 owner: net-kingdom
-revision: "1"
-decided: "2026-09-29"
-last_reviewed: "2026-09-29"
+revision: "2"
+decided: "2026-10-03"
+last_reviewed: "2026-10-03"
 review_interval: 12m
 ---
 
 # ADR-0017 - Root-Grant Custody and Account Authority
 
-**Status:** Proposed (drafted on the defaults agreed with the operator; accept after user-engine review)
-**Date:** 2026-09-29
-**Deciders:** Bernd Worsch, Claude
+**Status:** Accepted by Bernd Worsch on 2026-10-03; user-engine mapping confirmed.
+**Date:** 2026-10-03 (drafted 2026-09-29)
+**Decider:** Bernd Worsch
 
 ## Context
 
@@ -78,14 +78,31 @@ contains tokens, keys, unseal shares, recovery codes, or reset links.
 - user-engine can represent `AccountAuthority.root-grant` deterministically from
   the custody record id and revision, and unblocks USER-WP-0037-T02.
 - The custody record needs a machine-readable, non-secret form that a workload
-  can read. Its shape and location are an open follow-up (below); until it
-  exists, user-engine returns "no root grant" rather than inferring one.
+  can read. Its schema and OpenBao delivery design are approved; until the owner
+  delivers the live read path, user-engine returns "no root grant" rather than inferring one.
 - The 15-minute bound and the projection-versus-record rule are decisions of
   this ADR and may be tightened at review.
 
-## Open follow-ups
+## Delivery design and approval receipt
 
-- Define the machine-readable custody-record schema and read surface (owner:
-  net-kingdom; delivery of the read path may involve railiance-platform).
-- Confirm with user-engine that the membership-envelope mapping above is
-  sufficient for `AccountAuthority`.
+Bernd explicitly approved: “Accept ADR-0017 and approve the proposed OpenBao
+delivery design.” Scoped State Hub decision: `c2cff929-91b9-4018-bfd6-fa04f7da8280`.
+The separate MFA journey in bundled D10 remains pending.
+
+- Delivery owner: railiance-platform, RPF-WP-0049.
+- OpenBao KV v2 mount `platform`; API path
+  `/v1/platform/data/custody/net-kingdom/platform-root`.
+- Record `nk-custody:platform-root`, owner `net-kingdom-custody`;
+  complete document at response `data.data.document`. KV metadata version is
+  concurrency state, distinct from custody revision.
+- user-engine is the authenticated exact-path read-only consumer. Custody
+  writes use a separate attended human lane. The actual workload identity and
+  writer binding must be established through their owner routing procedures.
+- [Read contract](../contracts/root-grant-read-contract_v0.1.md) and
+  `canon/schemas/custody-record_v0.1.schema.json` define the document and checks.
+  user-engine confirmed the membership-envelope mapping (message `60acf176`).
+
+Design approval does not establish live admission or a real custody entry.
+Remaining delivery work: real reader identity, reviewed attended executor,
+recovery/audit configuration, bounded live provisioning approval and genuine
+ceremony provenance, followed by producer and consumer acceptance receipts.