the-custodian/docs/changes/netkingdom-target-2026-10-16/approval-reference

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.