coulomb/railiance-platform
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record verified root reader admission and empty custody publication
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1029d-2c93-7500-a0e0-e3e089668b29
This commit is contained in:
codex 2026-10-03 20:24:57 +02:00
parent 35d326f0cf
commit dff2d6e9f7
3 changed files with 106 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

68
docs/evidence/2026-10-03-platform-root-custody-delivery.md Normal file
View file

@ -0,0 +1,68 @@
# Platform-root custody delivery evidence — 2026-10-03
Owner: railiance-platform. Tracks RPF-WP-0049 / NK-WP-0045-T05.
Bounded operator execution is verified; full delivery/recovery acceptance is
still pending. This is a non-secret evidence summary, not a real custody grant.
## Verified attended admission and publication
The founder executed the reviewed attended commands under continued approval.
Fresh success receipts were independently read and checked locally:
- /tmp/platform-root-admission-20261003T181954Z-333977.json
- /tmp/platform-root-publish-20261003T181954Z-333977.json
Admission confirms namespace/SA user-engine/user-engine, role
user-engine-root-custody-reader on auth/kubernetes, audience openbao, active
OpenBao audit and per-key required CAS. Publication confirms whole-document
write and owner readback. Initial fact: nk-custody:platform-root, revision 1,
KV version 1, entries empty. It grants nobody root authority.
Content SHA256:
33a2ae086385028db1b654aa5646b7a98bcde1c5878c804e19315dadc3f87248.
Publisher receipt time: 2026-10-03T18:21:14.370633+00:00.
Publisher baseline mode: 0600. Immutable history receipt equals the baseline,
and both equal the publication receipt digest and current initial candidate.
The old oidc-role-platform-admin.20260828T112740.json is role configuration,
not a success receipt for these October 3 acts.
## Independent retained history and recovery requirement
Operator-owned publisher state is on the workstation:
/home/worsch/.local/state/net-kingdom-root-custody/baseline.json and history/.
It is already off-host and independent of OpenBao on railiance01 and OpenBao
snapshots. No additional runtime/service is required merely to duplicate it.
The human operator owns retaining and backing up this receipt holder. Preserve
baseline.json, history/ and any pending publication journal together; never
reset state to an older OpenBao snapshot or discard an ambiguous journal.
Retain publication history until an explicitly reviewed custody record
retirement; root custody entries are never removed to simulate revocation.
Remaining evidence, not a fresh generic approval:
1. Record the workstation receipt-holder backup destination/procedure and
verify a copy/restore/readback of this non-secret state, retaining the exact
latest revision and digest. A local process fsync proves durability, not
workstation disaster recovery.
2. Run the attended restore-check against the current owner source with the
retained baseline and fresh receipt. This proves today's independent state
agrees with current owner readback; it is not proof of a snapshot exercise.
3. In the platform/OpenBao owner's isolated recovery procedure, restore a
snapshot and compare with the independently retained latest history. Prove
that an older/missing/mutated record is refused and source authority is not
reopened until retained latest content is restored and readback matches.
Do not roll back live OpenBao merely to manufacture a test receipt.
4. Complete reader identity success and wrong-identity/anonymous/list/sibling/
write denial, outage/fail-closed and audit correlation receipts. The publisher
success receipt and configured reader policy do not alone prove workload
admission or workload denial behavior. Consumer rollout follows its owner.
No genuine root ceremony is known. A future real grant requires signed human
ceremony evidence and exact issuer/subject; IAM projections and a planned
custody roster cannot ground it. Algorithm grant/revoke/supersession testing
uses synthetic fixtures; no real grant is created or revoked for acceptance.
Security orientation reloaded: Emergent 0.2.4 root, verified-files,
orientation-only; digest
025aab4f38246219c924bc94954e70ea0e6e7f72bcaf8d4344cd599602d345c3.
No secret values, privileged role dump or token material are copied here.