Skip to main content

​
The resolution execution

When an override is approved, the governance runtime does not simply mark it as approved and return. It re-executes the decision under override authority — producing a new signed execution record that proves:
  • The exact execution that was overridden (via execution_fingerprint)
  • The identity of the approver (approved_by, approver_role)
  • The reason for the override (reason)
  • The signature of the override authorization
This is the resolution object returned by POST /override: 
{
  "status": "approved",
  "overrideId": "655b670c...",
  "resolution": {
    "status": "executed",
    "execution_fingerprint": "a3f8d2c1e4b5f6a7...",
    "signature": "ed25519sig..."
  }
}

​
What resolveOverrideFromContext does

The server calls resolveOverrideFromContext() from @parmanasystems/execution-runtime: 
const resolution = await resolveOverrideFromContext(
  pendingContext,    // the stored execution context from the original pending_override
  replayStore,       // to transition state to OVERRIDDEN
  signer,            // to sign the override execution
  verifier           // to verify the override execution
);
Internally:
  1. Loads the pending execution context (token, fingerprint, provenance, runtime manifest)
  2. Calls executeDecision() with the stored context under override authority
  3. Transitions replay state from EXECUTING → OVERRIDDEN
  4. Returns a signed execution result

​
Using the resolution

After the override is resolved, your application can proceed with the authorized action: 
const resolution = await client._request<{
  status: "approved";
  overrideId: string;
  resolution: {
    status: "executed";
    execution_fingerprint: string;
    signature: string;
  };
}>("/override", {
  method: "POST",
  body: JSON.stringify({
    executionId: claimId,
    approved: true,
    approvedBy: "adjuster-sarah-chen",
    approverRole: "senior_adjuster",
    reason: "Verified. Approved.",
  }),
});

if (resolution.status === "approved") {
  // Store the override record ID in your business system
  await db.claims.update({
    where: { id: claimId },
    data: {
      overrideId: resolution.overrideId,
      overrideExecutionFingerprint: resolution.resolution.execution_fingerprint,
      overrideSignature: resolution.resolution.signature,
      status: "approved_by_override",
    },
  });

  // Now execute the action
  await processClaimPayment(claimId);
}

​
After rejection

When an override is rejected, the execution stays blocked: 
if (resolution.status === "rejected") {
  await db.claims.update({
    where: { id: claimId },
    data: { status: "rejected_at_override" },
  });

  // Notify the customer
  await sendRejectionNotification(claimId);
}

​
Replay state after resolution

After successful override approval:
  • Redis state for the execution_fingerprint transitions to OVERRIDDEN
  • A second attempt to approve the same executionId returns 409
  • The OVERRIDDEN state is terminal — the execution cannot be re-run
After rejection:
  • The execution is marked rejected in the audit database
  • No second override approval is possible (409)

​
Troubleshooting

Resolution returned but action was already taken — Ensure your application checks the resolution status before taking the action. A rejection must not proceed to execution. Override approved but resolution.status !== "executed" — This indicates an internal error during override execution. Check server logs for [SYS-022], [SYS-023], [SYS-024], or [SYS-025] error codes. Want to redo an override decision — Once an override is resolved (approved or rejected), it cannot be changed. If the business decision needs to change, create a new execution with a new executionId and go through the governance flow again.