Home / Trace / How it works / The whole canvas
MyRISK Trace · the decision workflow
How a decision moves through Trace
Six phases, from agreeing which decisions matter through to replaying one years later. Follow the worked example and it plays itself, or open any step to see the screen the person at that step actually uses.
Trace decision workflow
Explore how a consequential decision is defined, approved, monitored and reviewed.
One of the three worked examples — the temporary patching exemption — is an available demonstration. The third-party privileged access and AI service deployment examples are illustrative, and the retention and disposition step is an illustrative extension: they show how a decision of that shape would be handled, not a capability in service today.
1 · Design
Agree what defensible decisions require.
2 · Capture
Record the case, its scope and context.
3 · Evidence & authority
Build the basis for accountable judgement.
4 · Validate
Apply repeatable tests and resolve gaps.
5 · Bind
Issue the precise, time-bound decision.
6 · Monitor
Keep testing whether it remains valid.
Follow the decision
Drag to move the workflow, and use the zoom controls to fit it. Steps marked Configured with customer are agreed during design rather than fixed by the software.
What the workflow guarantees
Three properties the record has to hold, and where they come from
What was known at the time
Evidence is captured as references, hashes and metadata, and the state relied on is collated at the moment of approval. A later reader sees what existed then, not what exists now.
Who could authorise it
The approver, the role they acted under, the exact outcome and the conditions attached are recorded together with the decision, not alongside it in another system.
Whether it still holds
Conditions of approval are tested against new operational events and on a schedule. A decision whose conditions fail is suspended, expired or revoked, with the reason kept.
For integrators
The integration documentation
Every step above is reachable over a REST API. The route, the headers, a full request body, the expected response, the error codes, and the idempotency and retry behaviour are documented step by step.
That documentation is issued individually rather than published. It is the working detail an engineer needs to build against Trace, and we would rather know who is reading it and be able to answer their questions.
If you have a key, enter it and the API view appears on every step of the workflow above. It lasts for this visit only and is not stored in your browser.
Asking for a key
Tell us what you are integrating and who will be building it. Keys are issued to a named person, and we will answer the questions that come with the first read.
Already working with us on a pilot? Your engineer has one already — ask whoever ran the Diagnostic.
Which decision would be hardest to defend next month?
Bring that one. The Diagnostic compares your current reconstruction with a Trace-style replay.