Appearance
Closure Governance
Closing an incident is a governance decision. OrviQ enforces that structurally.
The state machine
| From | Allowed transitions |
|---|---|
draft | triage, cancelled |
triage | investigating, cancelled |
investigating | remediation, in_review, cancelled |
remediation | in_review, investigating, cancelled |
in_review | investigating, remediation, cancelled |
closed | none — terminal |
cancelled | none — terminal |
Enforcement is on the backend across every entry point, not in the interface.
What is rejected
| Attempt | Result |
|---|---|
draft to closed | Rejected |
draft to remediation | Rejected |
triage to closed | Rejected |
investigating to closed | Rejected |
Any transition from closed | Rejected — terminal |
Any transition from cancelled | Rejected — terminal |
Direct transition to closed is prohibited from every state
Closure requires formal review approval through the governed review action. There is no path that sets an incident to closed directly.
The reason: an incident closed without review is an incident whose root cause, loss position, reportability assessment and remediation nobody independently confirmed.
Governed review and closure
Closure consumes the organisational workflow layer:
Investigation and remediation, then independent incident review and closure sign-off, optionally escalating to executive or risk committee sign-off, then formally closed or closure rejected.
Four-eye, six-eye and eight-eye stages are available through tenant workflow policy and risk tiers rather than hardcoded module logic. See Multi-Eye Approvals.
Segregation of duties: the maker who submitted the review cannot approve it.
Requires incident.review.
Workbench routing
When an incident enters in_review, an active task is projected into the resolved reviewer's Workbench my_reviews bucket, with the exact deep link /incidents?id=INC-YYYY-NNNN.
Segregation of duties guarantees the task is never routed to the maker. On terminal sign-off, the task automatically completes.
Notifications are dispatched to the resolved reviewer pool.
The immutable closure snapshot
On approved closure, a frozen snapshot is written containing:
- The financial loss ledger — actual, estimated, recovery, net and currency
- Impact ratings and details
- Regulatory reportability status, rationale and submission references
- Investigation narrative, root cause category and contributing factors
- Governance sign-off metadata — who signed off, when, at which stage, reviewer notes and closure rationale
Later changes to the live record never alter the snapshot. See the worked example in Loss Events for why this matters when claims settle after closure.
What closure does not close
Incident closure is independent of finding and action closure
Closing an incident does not close its linked findings or action plans.
Closing those findings and actions does not close the incident.
This is deliberate and reflects how the work actually runs. An incident can be operationally resolved, investigated, reviewed and closed within six weeks, while a remediation commitment arising from it — replacing a batch processing component, say — runs for nine months.
Holding the incident open for nine months would misrepresent the operational position. Closing the findings when the incident closes would abandon the remediation.
Cancellation
cancelled is for incidents that turn out not to be incidents — a false alarm, a duplicate report, a misclassified event.
It is terminal, and it is not a substitute for closure. Cancelling a genuine incident to avoid the review requirement would be visible: cancellations and closures are distinguishable in the register and in reporting.
Permissions
| Action | Permission |
|---|---|
| View incidents and status | incident.read |
| Report, triage and transition through the lifecycle | incident.manage |
| Record investigations | incident.investigate |
| Governed review, sign-off and closure | incident.review |
Requires the incident_management entitlement.
Example
Incident INC-2026-0014 — Payment file duplication.
| Day | State | Event |
|---|---|---|
| 0 | draft | Reported by the on-call operator |
| 0 | triage | Severity High, category operational, owner assigned |
| 1 | investigating | Timeline established, root cause identified |
| 4 | remediation | Three findings raised, three action plans created |
| 12 | in_review | Submitted for governed review; task appears in the Head of Operational Risk's Workbench |
| 15 | in_review | Returned — the reviewer required the reportability assessment rationale to be documented, not merely asserted |
| 18 | in_review | Resubmitted with the Legal-reviewed rationale |
| 21 | closed | Approved by the Head of Operational Risk; snapshot frozen |
State at closure:
| Element | Value |
|---|---|
| Net loss | 0.00 USD |
| Reportability | not_reportable, with documented rationale |
| Findings | 3 — one closed, two open |
| Action plans | 3 — one complete, two in progress |
Six months later: all three findings closed, all three actions complete and verified. The incident has been closed since day 21 and is unchanged.
The return on day 15 is the point of the review. The reportability decision was correct, but the reasoning existed only in a conversation. A supervisor asking about it two years later would have found an assertion and no basis. The review turned it into a record.
Troubleshooting
"I cannot close an incident." Direct closure is prohibited. Move to in_review and use the governed review approval.
"I cannot reopen a closed incident."closed is terminal. A new incident referencing the original is the correct response to a recurrence or a new development.
"I cannot approve a review I submitted." Segregation of duties.
"Closing the incident left findings open." Correct and intended. They have their own governed closure.
"A transition was rejected." Check the allowed transitions table. The state machine rejects bypasses.