railiance-platform/docs/task-execution-mediator-seam.md

# Strict task handoff to independent consumption confirmation

RPF-WP-0035-T12 source preparation, 2026-10-16. This seam calls only the existing
fixed disposable native adapter. It installs no production origin, identity,
permission, real grant, generic broker or backend default.

## Actual starting gaps and reused owner interfaces

At Platform source base d042d468 and Secrets c80a944 the native fixture used a
synthetic direct `consume-confirmed` journal transition. No actual strict Secrets
task handoff existed. Generic Secrets consume accepted a substituted approval ID,
coerced idempotent values and did not require the original exact decision. Those
are Secrets-owned defects; Platform did not copy its authorization policy or edit
that repository. The Secrets owner prepared a separate strict module under
SECRETS-WP-0013, referenced by exact hashes in this package's manifest.

Approval Engine already provides `ExecutionConfirmationClient.consume_exact` and
`confirm_consumption`. The latter performs an independently authenticated GET of
the durable original approval object and filters it to the original consumption
triplet/time. It is historical PIP evidence, not authorization. It neither validates
an Access decision nor makes a supplied receipt authoritative. Platform's adapter
previously assumed its first native call was journal ordinal zero, conflicting
with a preceding durable CAS/confirmation sequence.

`scripts/task_execution_mediator.py` now performs the narrow owner join:

1. Require the actual `secrets_engine.task_execution_handoff` dependency; absence
   refuses before provider credentials, journal reservation or native effects.
   The mediator itself calls `authorize_task_execution`. It accepts neither an
   inbound authorization object nor a caller-selected authorizer/transport callback.
2. Independently compile the exact local catalogue/descriptor/grant and compare the
   strict owner's detached handoff descriptor byte-for-byte. Only authorization_id
   may be added to approval reference metadata; purpose and source semantics cannot
   be substituted through an inbound catalogue object. Secrets owns signed Check,
   claim/native-act/full and approval-free digest joins, caller/subject correspondence
   and the strict prepared object. Platform does not render or duplicate that decision.
3. Bind the actual returned full canonical digest into the owner Plan. Reserve the
   approval/request/operation/Plan tuple and the precommitted cleanup obligations
   once while holding the same invocation lock through cleanup.
4. Commit a CAS call intent, invoke Secrets `consume_task_execution` once and require
   its actual typed result with exact original approval/request/decision/time and
   `idempotent is False`. A historical idempotent response cannot open native work.
5. Commit a separate read intent and invoke the actual Approval owner's default
   isolated transport, with independently installed read credential and exact same
   owner-admitted origin. Require `confirm_consumption` to match the native act,
   approval-free digest and original exact triplet/time. Raw approval entries and
   provider credentials never enter journal evidence or receipts.
6. Recheck original approval/decision/operation bounds using the existing Secrets
   time adapter, then persist `consume-confirmed`. Any CAS/read failure, timeout,
   denied read or mismatch records unknown and causes zero native execution. A
   subsequent invocation cannot retry the consumed approval or persisted admission.
7. Only then enter the fixed native grant/metadata adapter. Its next business-call
   ordinal comes from the same live journal, so CAS and GET occupy ordinals0/1 and
   native calls continue at2. Pending/unknown/cleanup-closed state cannot supply a
   next ordinal. Each native request retains its own durable intent and outcome.
8. Cleanup stays under the original distinct obligations even if business work
   fails. Wave 5 requires exact committed before/after snapshots before reporting
   native apply verified; six HTTP successes alone remain insufficient. This is
   sequential fixture acceptance, without atomic CAS, service-login provenance or
   native production owner acceptance.

The owner configuration selects provider route/read credential and the existing
Secrets configuration. These are independently installed runtime inputs, never
part of an HTTP body or authority derived from a caller string. Both providers use
real existing transports. Python import/file checks do not establish runtime
credential isolation; production custody/enforcement remains an external gate.

## Whole disposable source-server proof

Tests run the actual Access `serve` binary built from the owner source, with its
real Ed25519 signing implementation and enforce-mode TokenReview client. A local
synthetic reviewer independently admits only the explicitly fixed service token,
principal/audience and expiry. This is not actual Kubernetes identity proof.
Signing keys are generated in private temporary files; the public key and real
policy digest are independently installed in the Secrets trust file. The policy
digest comes from an owner-local actual source CLI before any network response.

The positive policy is a separately named local synthetic exact-descriptor Rego
fixture with a real deny fixture and Rego test. It never edits or enables the
actual task policy. The actual proposed service task package is exercised unchanged
and returns genuine signed DENY. There is no fabricated DecisionEnvelope or
model-only approval. Real Approval WSGI/SQLite plus distinct independently admitted
synthetic service/human identities create, approve, consume and serve the object.
The strict Secrets module uses its actual mandatory producer-type signature verifier,
retained request/claim/envelope and one-shot strict CAS, followed by the independent
Approval GET and real disposable OpenBao grant/token/metadata/cleanup requests.

Tests also prove actual independent read-scope denial after successful consume:
the durable approval is consumed, Platform remains unknown with pending read intent,
no target native objects exist and reinvocation cannot consume again. The native
journal is checked for known synthetic token leakage. A source purpose substitution
refuses before authorization/CAS, and a missing strict module refuses before any
credentials. Actual-policy denial leaves the approval approved and journal empty.
All identity, policy/registry admission, source-bundle/baseline digests and grant
approval in these tests are synthetic fixture inputs. These tests do not admit an
estate caller, real grant, production transport or actual protected custody.

## Remaining production work

Adopt/publish the exact strict Secrets dependency and this owner seam together;
admit the existing task-execution-grant source projection and actual identity,
policy package, provider origin/custody and complete source revisions. The current
actual policy remains hard-closed. Finish target CCR immutable semantics, total
native expected-state normalization/conflict control, CCR38 provenance, actual
per-call served-time/use enforcement, audit/outbox and protected uncertain/crash
recovery. Then obtain and execute the exact founder-scoped attended trial.
Approval replay prevention and uncertain native-effect reconciliation remain
separate guarantees. T12, Secrets WP13 and native adoption stay open.

Wave 5 adds owner-installed exact metadata snapshots committed through the
existing expected_before/expected_after descriptor fields, per-target baseline
and complete role/policy readback comparison, durable readback/verified evidence,
and a separate cleanup-confirmed transition. The sequence remains sequential,
without native CAS or independently recoverable cleanup handles. See
[fixture acceptance](task-execution-native-fixture.md#exact-disposable-metadata-acceptance-2026-10-16-wave-5).