> ## Documentation Index
> Fetch the complete documentation index at: https://docs.manthan.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# Override

> A post-hoc, immutable correction appended to an Execution Trust Record

**Override answers: was this record corrected after the fact, and by whom?**

Because every artifact in an Execution Trust Record is immutable, there is no operation that edits a past Decision or Execution. When a human authority needs to record a correction — for example, approving a transaction that policy initially rejected — that correction is captured as an `Override`: a new, additional, immutable artifact appended to the record's `overrides` array. The original Decision and Execution remain exactly as they were.

## Fields

| Field                   | Type     | Description                                                     |
| ----------------------- | -------- | --------------------------------------------------------------- |
| `overrideId`            | `string` | Unique identifier for the override.                             |
| `businessTransactionId` | `string` | The transaction being corrected.                                |
| `authorityId`           | `string` | The Authority who approved the override, per both SDKs' models. |
| `reason`                | `string` | Why the override was made.                                      |
| `approvedAt`            | `Date`   | When the override was approved.                                 |

<Warning>
  The canonical domain type (`packages/shared/src/domain/override.ts`) — what `OverrideService.create()` (`packages/runtime/src/services/override-service.ts`) actually builds — uses `approvedBy` rather than `authorityId`, and adds an optional `justification` field that neither SDK models. See [TypeScript SDK → Models](/docs/typescript-sdk/models#override-has-drifted-from-the-canonical-domain-model) for the exact comparison.
</Warning>

<Note>
  Parmana's runtime authorization model is allow-or-block with no human-in-the-loop escalation *during* evaluation — a Decision is not paused mid-flight to wait for a human. Override is a distinct, after-the-fact correction mechanism, not a runtime approval step.

  `OverrideService` is a real, working service, but it is not exported from `packages/runtime/src/index.ts`, not wired into `ExecutionTrustApplication`, and not exposed by any route under `packages/api/src/routes/` — there is currently no REST endpoint or SDK method that creates or reads an Override. `examples/07-human-approval`'s `run.ts` is an unimplemented stub (`console.log("Parmana Example 07 - Human Approval")` and nothing else) — it does not yet demonstrate this pattern in code. See [Guides → Human Override](/docs/guides/human-override) for how to use `OverrideService` directly today.
</Note>

## Relationships

Overrides are recorded on the [Execution Trust Record](/docs/concepts/execution-trust-record) alongside executions, verifications, and receipts — never in place of them.
