Reconciliation

Reconciliation checks authoritative state after an earlier attempt ended UNKNOWN. It uses the original operation binding and a verifier read, never another provider dispatch. It produces a new related result and leaves the original UNKNOWN unchanged.

Required live authority

The application needs the exact live handle, the original operation binding, and the registered verifier capability from the same Runtime instance.

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

// Bounded excerpt: both values must belong to this exact Runtime instance.
export function reconcile(runtime: ProtectedActionRuntime, runtimeHandle: LiveReconciliationHandle) {
  return runtime.reconcile(runtimeHandle);
}

Current process-local boundary

In this preview, the authority is private and process-local. Copied or serialized objects do not carry it, and a process restart ends the capability. Logs and provider request IDs may help an operator identify the case, but they cannot recreate live authority. The formal boundary is IN_PROCESS_ONLY.

After process loss, REHYDRATION_REQUIRED describes future work: a separately designed authority-reacquisition protocol would need approved durable records, identity and scope checks, verifier registration, and handling for stale or conflicting evidence. Rehydration is not cloning, deserialization, or redispatch. Durable rehydration is not implemented.

Possible results

The verifier compares the authoritative read with the original binding:

• PRESENT produces a new related COMMITTED result.
• ABSENT_FINAL produces a new related DISPROVED result.
• INDETERMINATE produces another related UNKNOWN result.

The original UNKNOWN remains immutable in every case. Reconciliation is not retry, compensation, replay, or a new proposal, and it performs zero provider redispatch.

Example: provisioning contractor access

An administrative application sends an authenticated backend an authorization-approved access request. An identity-provider adapter attempts the change, the provider response is lost, and the request may already have crossed the provider boundary. The application must not grant access again or tell the contractor that access is active.

While the exact live authority remains available, a separate directory verifier reads the authoritative identity directory. PRESENT, ABSENT_FINAL, or INDETERMINATE determines the new related result. If the process has restarted, this preview cannot reconcile by reconstructing a handle; the case remains unresolved for a separately approved workflow.

Application and Core responsibilities

Core validates exact live reconciliation authority, invokes the registered verifier through the protected lifecycle, binds the read to the original operation, produces a bounded related result, and enforces zero provider redispatch.

The application decides when reconciliation is requested, controls operator display, retains approved bounded correlation information, defines retention and escalation, and handles cases where live reconciliation is unavailable. Core does not schedule polling, operate a queue, or manufacture durable authority.

An application may retain bounded operation, effect, execution, and attempt identifiers for audit and support. Those records identify the case but do not confer live reconciliation authority.

Reconciliation versus a new action

Reconciliation asks what happened to the original attempt. A retry or compensation is a separate new proposed action, requiring fresh grounding and authorization. Core does not choose or automatically execute that new action.