Pending Override

What happens when execution_state is pending_override

When does pending override occur?

An execution enters pending_override state when the policy rule that matches the signals has requires_override: true. This means the governance system has made a decision, but that decision requires explicit human authorization before the action may proceed.

Example policy rule that triggers override:

{
  "id": "large-claim-review",
  "condition": { "signal": "claimAmount", "greater_than_or_equal": 5000 },
  "outcome": {
    "action": "manual_review",
    "requires_override": true,
    "reason": "Claim requires senior adjuster review: amount exceeds auto-approval threshold."
  }
}

When this rule matches, POST /execute returns:

{
  "status": "pending_override",
  "requires_override": true,
  "attestation": {
    "executionId": "claim-CLM-2024-00443",
    "execution_state": "pending_override",
    "decision": {
      "action": "manual_review",
      "requires_override": true,
      "reason": "Claim requires senior adjuster review."
    },
    "signature": "...",
    "execution_fingerprint": "...",
    "policyId": "claims-approval",
    "policyVersion": "1.0.0"
  }
}

---

The lifecycle

---

What is stored during pending_override

When execution enters pending_override:

1. The attestation is recorded in audit_decisions with execution_state: "pending_override"
2. A pending override record is created in audit_overrides with resolution_status: "pending"
3. The pending execution context (token, fingerprint, provenance) is stored so it can be re-executed if approved
4. The replay state in Redis remains in EXECUTING (not yet confirmed)

The execution context is stored in the database. When a human approves the override, the context is retrieved and the execution completes.

---

Detecting pending override

const response = await client.execute({
  executionId: "claim-CLM-2024-00443",
  policyId: "claims-approval",
  policyVersion: "1.0.0",
  signals: { claimAmount: 12000, customerTier: "standard", priorFraudSignals: false },
});

if (response.execution_state === "pending_override") {
  // The action is blocked. Do not proceed.
  console.log(`Execution ${response.executionId} is pending override`);
  console.log(`Reason: ${response.decision.reason}`);

  // Route to your review queue
  await reviewQueue.add({
    executionId: response.executionId,
    reason: response.decision.reason,
    submittedAt: new Date(),
  });
}

---

What to do next

1. Do not execute the action — the execution is blocked. The governance system has determined that human authority is required.
2. Store the executionId — you will need it to resolve the override.
3. Route to your review process — email, Slack, JIRA, your internal ticketing system.
4. Wait for reviewer action — the reviewer calls POST /override to approve or reject.

---

Checking override status

Use the audit decision endpoint to check the current state:

const record = await client.audit.decision("claim-CLM-2024-00443");

console.log(record.execution_state);   // "pending_override" | "completed"
console.log(record.decision);          // "manual_review"

There is no polling endpoint for override status. Design your review workflow to be event-driven rather than polling-based.

---

Troubleshooting

Execution returned pending_override but audit_db is false — Without Postgres, pending override state cannot be tracked. The override record will not be stored, and POST /override will return 404. Postgres is required for the override workflow.

Application acted on a pending_override decision — Always check execution_state before authorizing an action. pending_override means the action is blocked, regardless of decision.action.

Override state is pending for longer than expected — The override must be explicitly resolved via POST /override. It will not auto-resolve. See Approval and Rejection.