Lost response and UNKNOWN

UNKNOWN means dispatch may have crossed the boundary while the effect remains unproven. More precisely, the provider boundary may have been crossed, but available evidence cannot determine whether the intended external effect exists. This is unresolved world state, not merely a software exception.

Why the dispatch location matters

Treating UNKNOWN as failure and repeating the action may duplicate an effect. Treating it as success may mislead the user. The location of a transport failure helps explain which conclusion is safe:

• A timeout before dispatch may be a pre-dispatch outcome.
• A lost response after dispatch leaves the external effect uncertain.
• An unavailable verifier after dispatch also leaves effect truth unresolved.

The dispatch boundary records what Core can know about the lifecycle; it does not itself establish the state of the external system.

Safe application response

Do not blind-redispatch. Preserve the original immutable result and its proposal, grounded referent, authorization context, identities, and observations. The application can show a bounded pending or unable-to-confirm state while it retains approved correlation references. UNKNOWN is not permission to poll forever, and Core does not automatically poll, schedule checks, run a queue, operate monitoring, or choose a support workflow.

Core records and preserves UNKNOWN, protects the exact reconciliation authority, enforces a verifier-only follow-up, prevents provider redispatch through reconciliation, and returns bounded classification. The application or integrator chooses the wording, retention, access, escalation, support workflow, later checking, and the point at which the case leaves a pending state.

Exact live reconciliation authority

Reconciliation requires the exact live handle from the same Runtime instance. It is private, process-local, and non-serializable. Copied, cloned, reconstructed, stale, foreign, or post-restart handles are powerless. Reconciliation is verifier-only and performs zero provider redispatch; durable authority after restart is not implemented.

import type { LiveReconciliationHandle, ProtectedActionRuntime } from '@answerup/actions';

// Bounded excerpt: the host supplies the exact handle from this runtime instance.
export function reconcileExactHandle(runtime: ProtectedActionRuntime, liveHandle: LiveReconciliationHandle) {
  return runtime.reconcile(liveHandle);
}

A later reconciliation creates a related new result. It does not overwrite what was known at the time of the original UNKNOWN. A matching PRESENT observation can produce COMMITTED; supported ABSENT_FINAL can produce DISPROVED; unavailable, stale, contradictory, or non-final evidence remains UNKNOWN.

Example: submitting a supplier payment

An accounts-payable application sends an authenticated backend an approved payment instruction. A payment-provider adapter dispatches it, the boundary is crossed, and the response is lost. The initial result is UNKNOWN. Resubmitting may create a duplicate payment, so the application does not send the instruction again or tell the supplier that payment is complete.

If the exact live authority remains available, verifier-only reconciliation reads the authoritative payment ledger. A matching ledger entry supports COMMITTED; supported final absence can support DISPROVED; unavailable, stale, contradictory, or non-final ledger evidence remains UNKNOWN. After restart, this preview cannot reconstruct reconciliation authority from the payment request, a log, or a provider request ID.

What later evidence can establish

Later authoritative evidence may support a new narrow statement tied to the original operation. It does not retroactively change the original immutable result, prove that duplication was impossible, or authorize a different action. A later retry or compensation is a new proposal requiring fresh grounding and authorization.

The integrator defines bounded retention, access, escalation, and user-facing transitions. Core does not operate the monitoring or support process. A future durable design would require a separately designed authority-reacquisition protocol; it is not supplied by copying or serializing a live handle.