Exceptions
What a breach produces, and what it can still prove months later
Get started with exceptions
When a policy breaches, an exception opens: the case a team works. It carries the rule’s label, its limit, the observed figure, the party and a reference to the event that produced it. The console lists them under Exceptions.
Every exception carries an outcome, Soft breach or Hard breach. For threshold, velocity, ratio and measure rules it is decided by which limit the value reached; a list match, a binary rule and a verification walk carry a fixed severity, and an analyst can change the outcome later. The outcome picks the SLA hours: the policy’s own override when it has one, else the program’s hard or soft breach hours.
Frozen at raise
The rule, the limit and the actual value are written onto the exception as it opens. Editing the policy afterwards does not rewrite what already fired, so an exception states the limit in force when it raised. (GET /v1/exceptions answers the policy’s current name as the title.)
Occurrences
While a case is open or investigating, the same policy firing again on the same party joins it as another occurrence, and each occurrence keeps its own snapshot; the console shows them under Recurrence. A firing routed to a person’s review gets a case of its own, and a verification walk’s case is keyed on its session. A new case points back at the most recent earlier case on the same subject, open or closed.
Working a case
Statuses: Open, Investigating, Resolved, Dismissed, Accepted. Actions: Assign; Acknowledge and begin investigation, which moves the case to Investigating; Comment; Resolve exception; Dismiss exception; Accept risk; Reopen. Every move is recorded against the exception. A sweep every 5 minutes sends “SLA due soon” and “SLA breached” notifications. Closing a verification walk’s case records a customer risk rating, low, medium or high; the session answers it as riskRating once the case is resolved.
Back to the event
In the console, a case’s Source panel traces it to the row behind it: the source app that sent the event, its idempotency key, who authorised it, and the chain transfer it matched. This trace is a console view; the API has no door for it.
Over the API
A key with the Transaction monitoring scope reads the latest cases raised by the programs subscribed to its source app, and the decisions recorded on its streams. The SDK has no method for exceptions:
curl "$HIRA_ENDPOINT/v1/exceptions" -H "Authorization: Bearer $HIRA_API_KEY" { "total": 3, "totalCapped": false, "hard": 1, "items": [{ "id", "outcomeType": "HardBreach", "title", "triggerReason", "sourceType", "sourceEventReference", "triggeredAt" }] }
Decisions are read through the SDK; each names the case it hangs off as exceptionId:
const page = await hira.approvals.list({ status: "pending" }); page.items[0]?.exceptionId; // the case behind the first waiting decision page.pending; // null when not counted; release on pending === 0 only
A page holds at most 50 items; a full page sets totalCapped: true. The API reference lists every field.