Policy Exception Approval Automation: A Controlled Path Outside the Rule

# Policy exception approval SOP

Version: 1.0

Owner: Support policy owner

Review cadence: Quarterly and after a material policy change

Purpose: Decide one bounded departure from a known support policy without changing the policy or granting reusable authority.

## Scope

Use only when the customer, applicable policy version, normal outcome, proposed exception and requested deadline are known. Do not use for routine policy application, emergency/security incidents, or decisions that require finance, legal, employment, safety or regulatory review outside this procedure.

## Trigger and inputs

Trigger: a support agent records that the normal policy outcome is insufficient and requests one exception.

Required inputs:

- ticket and customer identifiers;
- policy name, version, effective date and clause;
- deterministic normal outcome and its inputs;
- requested exception, scope, reason, impact and expiry;
- source-linked evidence and conflicting facts;
- authority category and threshold;
- execution destination and business idempotency key.

## Procedure

1. Confirm identity, entitlement and the governing policy version.
2. Calculate and retain the ordinary policy outcome.
3. Validate evidence links, required fields and sensitive-data handling.
4. Prepare a decision packet. Summaries must cite source records and preserve unknowns.
5. Match the exception type and magnitude to the explicit authority table.
6. Reject self-approval, expired delegation, conflicts of interest and out-of-range authority.
7. Notify the named approver and start the decision clock.
8. Record approve, reject, request-evidence or redirect with reason, scope and expiry.
9. Before execution, revalidate case, proposal version, policy version, authority and expiry.
10. Execute once using the business key; reconcile the destination state.
11. Append the verified effect to the decision record and notify the case owner.

## Exceptions and escalation

- Missing or conflicting evidence: return to the requestor with a field-level list.
- Policy changed while pending: invalidate and rebuild the packet.
- No response by expiry: fail closed; escalate or return to the queue owner.
- Ambiguous execution: stop retries and reconcile the destination.
- Repeated reason: tag for policy review; do not alter the live policy automatically.

## Output and success condition

The decision record contains the proposal and policy versions, evidence manifest, authority snapshot, approver, outcome, reason, timestamps, expiry and verified effect. Success means one valid decision led to zero or one matching effect.

## Measures

Packet return rate, complete-packet decision time, expiry rate, redirect rate, effect-reconciliation status, overturn rate and repeated reasons by policy clause.

## Revision log

- 2026-08-03: Initial public template.

# Policy exception approval workflow blueprint

Version: 1.0
Canonical job: `/solutions/customer-support/policy-exception-approval`

## States

`requested -> preparing -> awaiting_approval -> approved|rejected|needs_evidence|redirected|expired -> executing -> reconciled|execution_exception`

Terminal states: `rejected`, `redirected`, `expired`, `reconciled`. `needs_evidence` returns to `preparing` with a new proposal version.

## Data contract

```yaml
case_id: string
proposal_version: integer
customer_id: string
policy: {id: string, version: string, clause: string, normal_outcome: string}
request: {exception_type: string, scope: object, reason: string, expires_at: datetime}
evidence: [{source_id: string, url: string, observed_at: datetime, hash: string}]
authority: {approver_id: string, rule_id: string, limit: object, checked_at: datetime}
decision: {outcome: enum, reason: string, decided_by: string, decided_at: datetime} | null
effect: {idempotency_key: string, destination_ref: string, status: enum} | null
```

## Steps and actors

1. **Trigger:** receive exception request; key `exception:{case_id}:v{proposal_version}`.
2. **Code:** resolve policy and calculate normal outcome.
3. **Code:** validate evidence, identity and schema.
4. **AI (bounded):** produce source-cited summary; no recommendation or authority selection.
5. **Code:** evaluate authority rules and conflicts.
6. **Human:** approve, reject, request evidence or redirect with reason and expiry.
7. **Code:** revalidate decision scope and current preconditions.
8. **Code:** execute with idempotency key and reconcile destination.
9. **Human:** own any ambiguous, harmful or consequential execution exception.

## Retry, permissions, and rollback

- Retry read-only retrieval within a capped exponential-backoff budget.
- Never retry an ambiguous side effect before destination reconciliation.
- The summarizer has read-only access to the evidence manifest.
- The approval service can write decisions but cannot execute effects.
- The executor receives only the approved, unexpired scope.
- Where rollback is not complete, define a named compensating action and human owner.

## Acceptance tests

1. Missing policy clause cannot enter `awaiting_approval`.
2. Out-of-range authority routes to `redirected`.
3. Expired approval cannot execute.
4. A changed proposal requires a new decision.
5. Two delivery attempts create one destination effect.
6. Timeout after success reconciles rather than repeats.
7. Model summary contains no fact without an evidence reference.
8. Every terminal state has an owner, timestamp and reason.