tegwick
608cbff477
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a1029d-2c93-7500-a0e0-e3e089668b29
64 lines
3.5 KiB
Markdown
64 lines
3.5 KiB
Markdown
# Live empty custody consumer acceptance
|
|
|
|
USER-WP-0037-T02 is complete for the approved empty/no-grant delivery. The
|
|
authenticated reader and persisted baseline work in the deployed consumer,
|
|
including an actual pod restart. This creates no root grant and does not close
|
|
USER-WP-0037-T03's independent private Hub caller admission.
|
|
|
|
Machine receipt: [consumer acceptance](2026-10-03-root-custody-consumer-live.json).
|
|
Source `0d0751d`; image
|
|
`sha256:030fe90232e20bb02b372e3d16b8ff659a5407d54f6405eb85754262b9ad7dc6`;
|
|
embedded NetKingdom canon `db319335b27b61b855382ee5af5d690f06eeb010`.
|
|
|
|
## Accepted source and initialization
|
|
|
|
Founder reported no known ceremony record. The reviewed initial entries[] document
|
|
contains no certified grants; record id nk-custody:platform-root, revision1, KV1.
|
|
Owner admission/publication receipts
|
|
platform-root-admission-20261003T181954Z-333977 and
|
|
platform-root-publish-20261003T181954Z-333977 both returned ok=true.
|
|
Document digest:
|
|
`33a2ae086385028db1b654aa5646b7a98bcde1c5878c804e19315dadc3f87248`.
|
|
|
|
The consumer's previously absent baseline was initialized once through the actual
|
|
dedicated projected OpenBao audience JWT, admitted Kubernetes role and bounded
|
|
read. The read matched the owner digest and exact configured source/record.
|
|
After the packaging owner's controlled pod restart the same database baseline
|
|
existed, matched the digest and was not reinitialized or reset. A separate
|
|
connection also verified persisted contents.
|
|
|
|
## Live boundaries
|
|
|
|
The fresh exact-path read matched the approved empty document. The adapter returns
|
|
no grant for platform and other tenants. A real login with the existing flex-auth
|
|
audience JWT was denied. With the real root-custody reader token, LIST on metadata,
|
|
GET of a sibling path and POST to the custody path each returned403. The POST used
|
|
an empty body with no required data, so even an unexpected write allowance could
|
|
not publish a valid KV document. No custody document was written by these probes.
|
|
|
|
The internal in-memory fixture service/serialization harness used the actual live
|
|
authenticated custody adapter and emitted optional AccountAuthority.root_grant
|
|
as null. Fixture authorization is not an admitted real Hub principal; this result
|
|
does not claim private HTTP route acceptance or real-user account verification.
|
|
|
|
Consumer-injected source failure and same-revision mutation produced no grant
|
|
and preserved the trusted baseline. These are consumer failure checks, not an
|
|
actual OpenBao outage or a changed producer document. Positive grants, revocation,
|
|
supersession and rollback were tested with synthetic offline canon fixtures; no
|
|
real grant exists to exercise those transitions live.
|
|
|
|
## Audit correlation and remaining ownership
|
|
|
|
Allowed read request_id: `91cd7235-9cfe-06c3-57a6-64a013d1cfcb`.
|
|
Reader login request_id: `29a2fac4-8108-7ca5-d0a6-682c4a31f48d`.
|
|
Read correlation time: `2026-10-03T18:30:58.194568+00:00`.
|
|
These references enable owner audit lookup; no raw token, document, rejected
|
|
response or private profile was printed. Audit-log retrieval was not performed.
|
|
Actual producer restore/recovery/read-audit receipts remain railiance-platform's
|
|
RPF-WP-0049/NK-WP-0045-T05 responsibility and do not reopen this consumer gate.
|
|
|
|
The owner observed one transient original database connection refusal at startup
|
|
on rollout and restart; Kubernetes retry recovered Ready1/1 and health/readiness
|
|
200. This occurred in the original runtime database connection before custody
|
|
assembly. It is recorded as a startup-reliability follow-up, not repaired or
|
|
expanded into unrelated work here.
|