# Current delivery state — 2026-10-04 CCR-2026-0032 is applied. The exact self-token amendment was approved and applied through attended Warden login. Dedicated manual ArgoCD application informed-decision-requester owns SA/store/ExternalSecret at 4332c39. Store Valid and ExternalSecret SecretSynced; native bounded proofs pass against candidate 804d89fb. See docs/evidence/2026-10-04-requester-delivery.json and docs/evidence/infd-requester-proof*.json. Final receiving review-pod projection and service cutover acceptance remain under INFD-WP-0007. Issuer rotation is a separate approved operation; none was performed for this delivery. The original design record below describes preparation history. Current policy adds only self lookup/revoke; the updated helper accepts the exact legacy policy or final policy and refuses all other drift. Its receipts contain fixed phases and booleans, never CLI bytes. The earlier execution digest is superseded: CCR is now applied, so the metadata child deliberately refuses replay. # Informed-decision requester workload delivery Status: founder-approved design for owner integration; execution pending, CCR-2026-0032, RPF-WP-0051. Demand: INFD-WP-0005-T05, message cd811073-d6db-41cf-8a57-10df0b360eab. Source preparation is authorized by the founder's RPF-WP-0050 scope selection and continuation instruction. 2026-10-04: Bernd answered "I approve" to the prepared design boundary, including namespace-level ESO trust and credential persistence beyond the reader token's lifetime. This supplies the design judgment. Owner binding/runtime acceptance and the separately reviewed live deployment remain; no repeated design decision is needed unless the boundary materially changes. CCR status remains proposed and auth claims unconfirmed while the implementation gates are open. ## Exact proposed boundary The existing KV-v2 path `platform/workloads/informed-decision/sitting-requester` and field `CLIENT_SECRET` remain issuer custody. New policy `workload-kv-read-informed-decision-sitting-requester-eso` reads only its exact data path. The founder-approved amendment also grants auth/token/lookup-self read and auth/token/revoke-self update. It grants no KV write, metadata read/list, wildcard or sibling access. KV ACLs apply to the entire path, not individual fields; future fields at this path require review of the reader's risk. The prospective auth role `informed-decision-sitting-requester-eso` binds only ServiceAccount `informed-decision/informed-decision-eso` and audience `openbao`. Token TTL, maximum and explicit maximum are 900 seconds, with no default policy or periodic token. The review Deployment retains its own ServiceAccount `review`; the new ServiceAccount serves ESO authentication only. ESO's actual TokenRequest permission for this account must be verified through the owner before promotion. The proposed ClusterSecretStore `openbao-informed-decision-sitting-requester` admits only namespace `informed-decision`. The proposed ExternalSecret and target Secret are `informed-decision-sitting-requester`, key `client-secret`, refreshed every five minutes. Explicit target annotations contain source annotation copying. Any ExternalSecret in this namespace can use the store; it is a namespace boundary, not pod-level admission. Namespace writer access remains part of owner review. The mount proposal projects only that key at `/var/run/secrets/informed-decision/requester/client-secret`, read-only, mode 0440, without subPath or environment delivery. The existing review pod runs as UID/GID/fsGroup 10001. Kubernetes rotation changes the projected file; the owner callback must reopen it per exchange rather than caching the credential forever. Missing custody must fail closed and the required Secret projection is not optional. ## Runtime composition remains an owner gate The owner implements `IntakeApprovalClient` with an injected access-token callback; the deployed runtime does not yet compose the private intake listener or this file-backed client-credentials exchange. This packet deliberately introduces no invented environment setting or runtime JSON key. The owner must accept and compose the file callback, exact issuer/token endpoint, bounded transport with CA checks, RS256/JWKS signature verification, and claim/scope refusal before promotion. Existing verified requester contract: client `informed-decision-sitting-requester`, subject `informed-decision`, audience `approval-engine`, tenant `tenant:platform`, service principal, role `informed-decision-sitting-requester`, and scope exactly `approval:create`. The maximum existing JWT lifetime is fifteen minutes. Human answering uses the existing browser client; no approval/read/consume scope or workload acceptance route is introduced. No client registration, custody seed or rotation occurs in this work. Existing CCR-2026-0026/0027 remain applied. ## Concrete metadata child for review `scripts/informed_decision_requester_metadata.py` is a silent contained child, not yet approved to run live. It requires the actual CCR's SHA256, approved status and confirmed exact binding, and an attended platform-admin identity without root or ambient token environment overrides. It checks both current policy and role before any write, refuses differing objects, writes only missing metadata objects from stdin, and verifies both afterward. Only an API 404 means absence; denial and transport errors stop the operation. It neither reads/writes KV values nor applies Kubernetes objects, and retains no token or subprocess output in a file or receipt. After owner acceptance, exact CCR/binding approval and fresh founder go, review the exact helper and policy digests and run from that checkout in the founder's terminal: ```sh BAO_ADDR=http://127.0.0.1:18200 VAULT_ADDR=http://127.0.0.1:18200 \ warden access openbao-platform-admin-login --exec -- \ python3 scripts/informed_decision_requester_metadata.py \ --expected-ccr-sha256 ``` The argument binds the approved CCR, whose status/binding changes produce a new digest; the current proposed digest is not an execution authorization. Exit 0 means metadata readback passed; 2 means source/approval/envelope refusal; 3 means an existing object differs; 4 means command failure; 5 means malformed response or readback failure. The founder retains warden's actual completion/revocation line; its exit code alone does not establish handoff or session cleanup. Metadata success is not native reader or runtime acceptance. The review manifests live in `docs/provisioning-windows/2026-10-04-1000/informed-decision/`. No active Kustomization references them. ESO/runtime promotion needs its own owner path, cluster/node and headroom checks, diff/server dry-run and approved immutable image/config. Neither this command nor the packet activates that promotion. ## Owner receipt and abort contract Record only non-secret identities, timestamps, source digests, readiness and capability booleans in `receipt-contract.json` or its accepted successor. Native checks must prove exact role identity/effective policy and all TTL bounds; ESO SecretSynced; safe annotation metadata; exact-file projection; sibling data GET and parent metadata LIST denial; wrong namespace/ServiceAccount/audience denial; and create-only exchange with approve/read/consume refused. Never print a real Secret, annotation contents, token/accessor or raw child error. Use the maintained secret-annotation helper for actual Secret metadata checks. Rotation review must prove the callback observes a changed file and stops using the predecessor after coordinated issuer rotation. No issuer rotation is performed merely to prove metadata preparation. Reader token expiry/revocation and attended admin-session cleanup require native receipts. The founder is the proposed driver and abort owner for the attended metadata step; confirm attendance at the actual window. The receiving owner must name its runtime verification/abort owner before promotion. On a partial failure, stop and establish actual state; do not overwrite conflicts or automatically delete objects. Owner-reviewed rollback withdraws this new ESO/runtime projection and disables only this new reader role, revoking its outstanding tokens through admin custody. Already materialized target Secrets need separately approved removal; `deletionPolicy: Retain` does not erase them. Existing verifier and attended-reader roles and the KeyCape client remain intact. If value exposure occurred, use the separate issuer incident/rotation procedure.