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](../../examples/custody-record/initial-empty-record.json)
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](2026-10-03-platform-root-admission-receipt.json) and
[publication receipt](2026-10-03-platform-root-publish-receipt.json), 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](2026-10-03-user-custody-live-acceptance.json)
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](2026-10-03-user-custody-live-final-acceptance.json)
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](2026-10-03-platform-root-isolated-raft.json)
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.