# Outbound completion and record-owner lifecycle

Runtime owns its immutable outbound intents and completion receipts. Integration
owns provider execution and the command queue. A Runtime `PENDING` or `ACCEPTED`
intent holds the record owner until Runtime commits an exact terminal result;
Core does not infer completion from Integration's private command states.

Integration checkpoints a definitive no-effect refusal in the existing command's
`ResultFormatVersion`, `ResultDigest`, and `CanonicalResult` columns. The command
then enters `writeback`, and every retry submits the same typed result through
`CommitOutboundResult`. Runtime acknowledgement moves this command to `rejected`
without creating a RemoteLink or performing another provider call. Provider
success, partial success, ambiguous HTTP failures, timeouts, and dispatch lease
expiry cannot be converted to no-effect merely because retrying stopped.

A Runtime completion can immediately permit transfer or deletion of the original
record. Integration's finalizer therefore uses the exact validated Runtime
acknowledgement to finish its own bookkeeping even if the source RemoteLink was
retired, quarantined, or removed in the meantime. It never restores or modifies a
changed snapshot. A worker restart reacquires the acknowledgement through
Runtime's idempotent result API. Without that acknowledgement, the released
`FinalizeWriteback` entrypoint retains strict current-link validation.

## Rollout and existing commands

This change requires the matching contract and Runtime result implementation,
and the existing typed-result column extension on
`_System_IntegrationOutboundCommand`. Install the schema and compatible Runtime
before allowing new Integration workers to publish typed no-effect results.
An older Runtime rejects the new result format; Integration retains the durable
writeback and retries without provider I/O. If the column extension is absent,
new workers retry safe refusals and do not mark them terminal without a receipt.

Before relying on owner deletion or transfer availability, retire older worker
binaries through the deployment's normal worker drain mechanism and reconcile
outstanding Runtime intents against their owning Integration commands. A
historical `rejected` state is not sufficient evidence for a no-effect receipt:
review the actual attempt history and any provider success or uncertainty.
Never bulk-clear Runtime intents based on a command state or an expired lease.
Legacy successful commands with a committed Runtime receipt remain complete;
commands still in writeback resume through the idempotent result API. Commands
with unresolved external effects remain fenced until explicitly reconciled.

Deployments with older workers remain conservative: unresolved Runtime intents
continue to block owner changes, although a safe refusal made by an older worker
may require reconciliation because it has no terminal Runtime receipt. No
service restart or environment rollout is part of the source-code change.