railiance-platform/docs/credential-lane-designs/informed-decision-requester-workload.md

# 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 <SHA256-OF-THE-APPROVED-CCR>
```

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.