# Approval exact-consume source provenance

Prepared by the approval-engine worker, with its AGENTS.md and INTENT.md loaded,
in `/tmp/netkingdom-approval-reference-20261016`. Canonical owner source remained
unchanged and clean at `9491d1d3a7b6554fa04f8dc06f65d50e3d6ee4e1`.
This is source preparation and owner technical judgement, not a formal delegated
review, native approval or independently accepted deployment. The new owner work
record must be integrated before a formal review is recorded.

The existing authoritative consume CAS, durable transactional outbox,
ExecutionConfirmationClient and hardened fixed-origin transport already supply
the factual consumer boundary. A signed portable consume receipt is absent,
but adding another signer/service is unnecessary for the independently
authenticated mediator. The reachable source gap was discarded consume caller
identity and insufficient standalone act/PDP correspondence in the use event.

The patch passes HTTP-verified Identity to consume and atomically retains bounded
consumer metadata, native binding, PDP digest/path alongside existing full
request/decision and threshold evidence. Top-level actor remains the approved
initiator. Caller JSON cannot replace verified consumer provenance. Internal
calls retain null, retries preserve the first event, and historical rows remain
unchanged. Existing response/claim fields and schema version are unchanged.
INTENT basis: authenticated consumable object, exact binding and local atomic
evidence. It supplies facts and creates no new permission decision.

`implementation.patch`, `manifest.json`, `validation.json` and `patch-check.json`
pin the exact deliverable. Patch SHA256:
`a6bf77fa8b6916f423db7832f475e38747b828dd632a88f9631131e28e3230ee`.
44 focused tests passed. Full suite: 277 passed and one failed deployment-evidence
image pin check; the identical failure was reproduced on an untouched baseline.
Historical release/native evidence was preserved. No real token, approval,
OpenBao, native side effect, deployment or migration was used.

The scoped demand from CUST-WP-0080 is reconciled into WP0002 without promoting
all residuals. New WP0004 tracks the bounded source delivery and pending canonical
review/integration. The coordinator handles canonical sync after independent
review. Hub progress logging has its request/receipt here; no new workplan was
registered from the temporary checkout.

Native acceptance requires the existing owner interfaces:

- Approval T01: exact KeyCape issuer/audience/scope/tenant provenance receipt and
  human-authorized release/migration with native verified entry/readback. Current
  source identity tests do not prove issuer admission or deployment.
- Approval T04 / Audit: admit the refined source payload, drain actual lifecycle
  rows and independently read receiver event ID/content; reconcile counts,
  duplicate/lag/boundary handling, silence and scoped bearer revocation. Existing
  local atomicity cannot prove omission resistance under source compromise.
- Approval T05 / Platform / Secrets: name actual served PEP revision/route and
  actual independently authenticated read/consume client; establish trusted server
  transport/custody/ingress. Validate fresh exact claim and signed Access decision,
  approved native act, approval-free/full request bindings and immutable operation
  plan before CAS. Preserve live one-shot journal admission, deadlines, unknown
  outcomes, independently confirmed cleanup and approved recovery.
- Secrets and Access retain strict downstream consumption correspondence,
  published policy/action/initiating-principal representation admission and
  producer-compatible signed-decision trust. The outbox row does not validate
  that a supplied decision ID exists or authorize a protected operation.

The native proof must bind exact source/image/config, identity, operation/body,
CAS evidence, actual protected effect, event/source/receiver correspondence and
cleanup. Wrong actor/tenant/body/decision, expiry, replay, unavailability and
consume-before-effect failure are required refusals. Fixture success is never
reported as native acceptance. The existing deployment pin/evidence discrepancy
must be reconciled by its owner from real release evidence before rollout.