net-kingdom/docs/evidence/2026-10-03-root-grant-delivery-progress.md

Root-grant delivery progress — 2026-10-03

Work: NK-WP-0045. Scope: approved OpenBao custody-record delivery. This receipt records source preparation, safe preflight and verified attended admission/ publication receipts. It is not custody-grant or recovery-readiness evidence.

Human disposition and initial empty record

Bernd accepted ADR-0017 and the proposed OpenBao design (scoped made decision c2cff929-91b9-4018-bfd6-fa04f7da8280), then approved going forward. Asked which existing signed ceremony grounds the first grant, he replied: “i dont think there is one”. No current ceremony reference or exact custodian issuer/subject was supplied. Historical local bootstrap metadata and the planned signed escrow roster cannot substitute for a real grant.

Prepared initial empty record for review and attended publication: stable record ID nk-custody:platform-root, revision 1, owner net-kingdom-custody, 900-second maximum and entries: []. This is an intentionally empty authoritative candidate, not a synthetic grant fixture. It represents no certified root grants. Schema and semantic validation passed. It was subsequently published through the attended lane, as recorded below. Initial publication must use CAS=0 and fail if an existing document or unresolved retained history is discovered; do not replace an existing record on the assumption that no ceremony was supplied.

A future real grant requires a human-controlled ceremony naming exact issuer, subject, actor, action time/reason and evidence reference, introduced in a strictly newer revision. No identity is inferred from JWT roles or LLDAP groups.

Source preparation and checks

• NetKingdom validator now emits expires_at so consumers can honor cache bounds tighter than 900 seconds. All 18 focused tests pass, including zero/60-second bounds. Canon source pin db319335b27b61b855382ee5af5d690f06eeb010.
• railiance-platform implemented exact reader admission, whole-document CAS, independent receipt history, interrupted-publication recovery, replay and stale-receipt refusal, and restore checks; 14 tests passed. Source baseline fa958cc, attended empty-publication packet 35d326f, exact-commit primary synchronization applied.
• rapp-user-engine prepared dedicated openbao-audience JWT projection, scoped egress and explicit-image release rendering; 7 packaging tests passed. Source baseline 576f5e7, pushed with clean working tree; empty-source rollout is explicitly supported. PostgreSQL baseline uses the existing DB; no new persistent volume is needed.
• user-engine implements pinned canon, authenticated bounded reads, atomic PostgreSQL baseline, controlled receipt-bound bootstrap and optional AccountAuthority mapping. Isolated PostgreSQL checks verified competing CAS updates, cross-connection persistence and reconnect persistence. Final source 0d0751d: suite ran 296 tests with eight skips; layer checks, wheel build and embedded-resource integrity passed. Published image verified by registry manifest and disposable container: sha256:030fe90232e20bb02b372e3d16b8ff659a5407d54f6405eb85754262b9ad7dc6 (source 0d0751d). Embedded reader, baseline, bootstrap, canon and AccountAuthority field were checked; owner sync f85c968.

Safe live preflight

OpenBao workstation tunnel http://127.0.0.1:18200: initialized true, sealed false, standby false. Anonymous read of the exact custody data path returned 403; response bodies were discarded. This proves only anonymous denial, not reader admission, document existence or positive live custody delivery.

Remaining execution and acceptance

The founder completed OpenBao provisioning and publication in the attended OIDC/MFA lane; fresh success receipts are recorded below. Existing approval was sufficient for the reviewed delivery work. The concrete producer packet is in railiance-platform/openbao/root-grant/README.md. Keep independently retained latest publication history through restore. Its location and backup receipt must be recorded before recovery readiness closes.

The custody-capable application image is published/pinned and its deployment passed preflight. Deploy through rapp-user-engine and initialize the baseline using the authenticated document plus publisher digest. Empty source acceptance proves no-grant delivery; it cannot prove a real positive grant or revocation. Positive grant/revocation exercises use isolated synthetic test sources unless a real human ceremony explicitly introduces a live grant.

No live admission, publication, workload rollout or actual root grant occurred in this receipt. Source/fixture passes are distinct from live acceptance.

Exact deployment preflight

rapp-user-engine rendered the published image into /tmp/user-engine-custody-release.yaml, manifest SHA256 5e21548fc2d23926d167f17795f098f8db5fffafe9bcd3bee43875f7bb51a50e (rapp-user-engine release packet commit 13a9c0b, committed and synced). Live node 92.205.62.239 Ready; requested CPU 3445m/4000m (86%), memory 9384Mi (58%). Staged Deployment retains single-replica Recreate and requests 50m/64Mi. Server dry-run passed eight objects. Client diff returned expected changes (exit 1) to Deployment and runtime NetworkPolicy; raw diff output suppressed. Existing live factor-recovery URL, mounts, volumes and egress semantics are preserved. This final artifact supersedes the earlier preflight hash after preserving that live setting. No apply or workload mutation.

Image publication and attended reader/source admission/publication are resolved. Reviewed runtime rollout, controlled baseline initialization and live no-grant/denial/outage/restart acceptance remain. Off-host publication history retention/recovery needs its real receipts before recovery readiness closes.

Attended execution receipts

Founder executed the reviewed commands and reported success. Both fresh receipts were independently read and their non-secret fields retained in admission receipt and publication receipt, with source file SHA256 checksums. Both report ok: true; admission confirms exact role, namespace/ServiceAccount, audience, CAS and audit. Publication confirms revision 1, KV version 1 and the reviewed empty-document digest. The independently persisted publisher baseline matches these fields. This supersedes the earlier pending-admission/publication state, without claiming runtime or recovery acceptance. The operator's older OIDC role configuration is not an execution receipt. Owner rollout and authenticated baseline/read acceptance resumed.

Live runtime and consumer acceptance

rapp-user-engine applied only the reviewed Deployment and runtime NetworkPolicy. Bounded apply artifact SHA256 804400134a705651d12ada05a068543d2f1665a14eec5c3b65898c7560a63a8f. Rollout succeeded; Ready/available 1, health/readiness HTTP 200. One initial restart was safely traced to a transient original runtime PostgreSQL connection refusal; subsequent restart count remained stable. This is distinct from the post-baseline restart acceptance exercise.

The consumer's live acceptance receipt reports ok: true: baseline initially absent, controlled initialization from a fresh authenticated owner read matched the publisher digest, empty-source mapping returns no root grant, wrong tenant returns no grant, and a real wrong-audience JWT login is denied. Database reconnect preserves baseline. Injected read failure and same-revision mutation preserve the trusted baseline; these are injection checks, not claims of an actual OpenBao backend outage. Post-initialization pod restart, exact-reader negative capabilities/audit and independent backup/recovery evidence are still being collected. No actual grant was introduced.

The final consumer receipt subsequently verified baseline persistence after an actual controlled pod restart, a fresh matching owner read and HTTP 403 for the actual reader's metadata LIST, sibling GET and exact-path POST. The internal fixture service serialized root_grant: null against the actual live empty source; it does not claim acceptance of the separate external Hub authenticated route. Safe read and login request IDs were retained for owner audit correlation. USER-WP-0037-T02 is accepted for this delivered no-grant integration; the separate Hub route task is outside this acceptance. The restarted workload is Ready; its initial DB connection refusal also occurred on the controlled restart, recovered, and remained stable. No ongoing CrashLoop or zero-restart claim is made.

The isolated Raft recovery receipt reports actual disposable OpenBao v2.5.5 snapshot/restore checks: an older snapshot missing the custody source was refused against the independent baseline, and the latest snapshot restored the matching revision/digest. Scratch copy/restore of baseline and immutable history verified content and permissions. Temporary daemon/storage were removed. No production snapshot or rollback was used. This proves the isolated recovery guard, not current provider backup coverage or the attended live-source restore check.