Appearance
Decision History
Every governed decision in OrviQ leaves a record. The record is what makes the decision defensible.
What is recorded
For every workflow transition:
| Element | Purpose |
|---|---|
| The object | What was decided on, by business reference |
| The stage | Which stage the decision was made at |
| The transition | Forward, approve, return, reject or escalate |
| The actor | Who acted |
| The timestamp | When |
| The rationale | Why, where a reason was recorded |
| The resulting state | What the object became |
Alongside the workflow record, domain modules maintain their own audit trail of business state changes, and the platform maintains a global audit log.
Rationale
Most transitions accept a rationale, and several require one:
| Decision | Rationale requirement |
|---|---|
| Marking a requirement Not Applicable | Required — meaningful justification enforced |
| Approving an exception | Approval rationale recorded |
| Rejecting an exception | Rejection rationale recorded |
| Risk acceptance | Business justification required |
| Self-review break-glass | Required — documented reason |
| Return or reject at any stage | Strongly recommended |
Write the rationale for the person who was not in the room
The reader of a rationale is almost never the person who wrote it. It is a successor, an auditor or a supervisor, eighteen months later, with none of today's context.
"Approved" tells them nothing. "Approved: compensating controls reduce residual likelihood to Low; expiry set at 90 days to align with vendor release 8.2" tells them everything they need.
Historical template versions
A workflow run completes on the template it started with.
This matters when chains change. If your exception chain moved from four-eye to six-eye in June, an exception approved in March was approved under a four-eye chain — and its decision history reflects the chain that actually applied, not the current one.
Configuration changes never rewrite past decisions
An audit finding of the form "your exception chain requires executive approval but this exception has only two approvals" is answered by the history: at the time, it required two.
Where history is surfaced
| Location | Shows |
|---|---|
| The record's own timeline | Every state change, comment, attachment and decision on that object |
| Workflow run events | The stage-by-stage transition record |
| The global audit log | Platform-wide activity, for administrative and audit review |
| Immutable snapshots | Frozen states at audit finalisation, inspection submission, incident closure, BIA and plan approval, exercise sign-off |
Immutable snapshots versus history
These are different and complementary.
| Decision history | Immutable snapshot | |
|---|---|---|
| Records | Each transition as it happened | The complete state at a governance moment |
| Granularity | Event by event | A full frozen picture |
| Answers | "What happened, in order?" | "What exactly was approved or submitted?" |
| Where | Every governed object | Audit finalisation, inspection submission, incident closure, BIA, plan and exercise approval |
Answering the common questions
| Question | Where the answer is |
|---|---|
| Who approved this and when? | The record's timeline and workflow run events |
| Why was this approved? | The approval rationale |
| Who could have approved it? | The template's stage role binding at the time |
| Was segregation of duties observed? | The actors on each stage — they will differ |
| Was this returned before approval? | The transition history |
| What did we submit to the regulator? | The immutable submission snapshot |
| What did the audit report actually say? | The frozen report snapshot |
| What was the applicability decision in March? | The applicability history, as of that date |
Permissions
| Action | Permission |
|---|---|
| View a record's timeline | Read access to the record |
| Read the global audit log | audit.read |
| Administrative workflow override | workflow.override — separately audited |
Example
Exception EXC-2026-0031, complete decision history.
| Date | Stage | Transition | Actor | Rationale |
|---|---|---|---|---|
| 22 Mar | Draft and submit | Forward | IT Security Ops Manager | "Vendor protocol does not support MFA; release 8.2 committed for Q4" |
| 24 Mar | Review and approval | Return | Chief Risk Officer | "Compensating controls are described but the session review cadence is not stated. Please specify frequency and reviewer." |
| 26 Mar | Draft and submit | Forward | IT Security Ops Manager | "Compensating controls updated: sessions recorded and reviewed weekly by the SOC lead" |
| 29 Mar | Review and approval | Approve | Chief Risk Officer | "Approved. Compensating controls reduce residual likelihood to Low. Validity 90 days to align with vendor release 8.2. Reassessment at day 75." |
What this record establishes:
- Segregation of duties was observed — the requester and approver are different people.
- The chain was exercised, not rubber-stamped — the first submission was returned.
- The approval has a stated basis that survives challenge.
- The expiry is tied to a specific external event, so its renewal decision has a testable criterion.
Nine months later, when an auditor asks why a control deviation on a critical system was permitted, all four rows are available with their actors and timestamps. The answer is not a recollection.
Troubleshooting
"A past decision does not match our current approval policy." It followed the policy in force at the time. Runs complete on the template they started with.
"An approval has no rationale." The transition did not require one and none was given. Rationale is required on specific decisions and recommended everywhere.
"I cannot see the global audit log." Requires audit.read.
"An immutable snapshot differs from the live record." That is the purpose of the snapshot. The live record has moved on; the snapshot holds what was approved or submitted.