Skip to main content
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

FieldTypeDescription
overrideIdstringUnique identifier for the override.
businessTransactionIdstringThe transaction being corrected.
authorityIdstringThe Authority who approved the override, per both SDKs’ models.
reasonstringWhy the override was made.
approvedAtDateWhen the override was approved.
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 for the exact comparison.
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 for how to use OverrideService directly today.

​
Relationships

Overrides are recorded on the Execution Trust Record alongside executions, verifications, and receipts — never in place of them.