Home / Trace / How it works

Trace · how it works

Eight flows, one decision, followed end to end.

Some decisions get questioned long after they are made. This is what happens to one inside Trace, from agreeing it needs a defensible record to replaying it a year later. Select any step to see what it records and the view the person doing it uses.

01 Design 02 Capture 03 Evidence & authority 04 Validate 05 Bind 06 Monitor 07 Continuous audit 08 Review, replay & reporting

Book the Diagnostic → All 31 steps on one canvas

Flow 01 of 08

Patent Pending · AU 2026203358

Design

Agree what defensible decisions require.

Before any decision is captured, the decision type is designed: which real judgements are consequential enough to govern, what each one must always carry, and which of those requirements a machine can test rather than a person assert.

Select any step to see what it records and the view itself.

Customer discoveryIdentify consequential decisionsSelect decision types where evidence, authority and continuing validity must be defensible. Joint designDefine requirementsAgree evidence, authority, assertions, expiry and monitored conditions. MyRISK configurationCodify deterministic testsTranslate agreed assertions into versioned, repeatable tests.

Identify consequential decisions

Discovery decides which real-world judgement becomes a governed decision type at all. It is deliberately a configuration step: nothing is captured until the organisation has agreed that this class of decision is consequential enough to govern.

What it records. The decision type being proposed, who owns it, the policy behind it, and why it needs a defensible record at all.

What happens next. The decision type is agreed once the policy and process owners are named.

Customer identifies decisions where inconsistent handling creates material risk.
MyRISK maps the current process, policy obligations and audit expectations.

Identify consequential decisions — shown with an AI service deployment case

Configuration

Connected

Decision discovery workshop

Agree where controlled, defensible decisions matter most.

Business process

Policy obligation

Decision type

Use case

Customer service AI deployment

High impact

Workshop output

Evidence, authority, tests, expiry and monitored conditions.

Agreed model

Define requirements

This step turns an agreed decision type into explicit inputs and controls. Every later completeness check, evaluation and monitoring action traces back to the requirements set here.

What it records. What every decision of this type must carry: the classes of evidence, who has to approve it at each risk tier, what a person must attest to, what can be tested automatically, how long it may last and what would revoke it.

What happens next. A requirement is complete when it has an owner, a test or a judgement method, and a defined failure outcome.

Evidence requirements define what must support the decision.
Authority requirements define which role may approve at each risk level.
Assertions define what must be true; monitored conditions define what must remain true.

Define requirements — shown with an AI service deployment case

Configuration

Connected

Customer service AI deployment

Configured decision requirements

Requirement	Agreed treatment
Evidence	Vendor notice, test result, compensating controls
Authority	CISO
Expiry	30 days maximum
Trigger	Material model or data-use change

Codify deterministic tests

Codification is the executable form of those requirements. It fixes which facts can be tested deterministically -- each assertion carrying a fact key, an operator and an expected value -- and where a named person must attest instead.

What it records. The tests themselves, as a versioned set — each one a fact to look at, a comparison to make, the value expected, who must judge it where a machine cannot, and what happens when it fails.

What happens next. A test-set version is published only once it reproduces the agreed policy interpretation.

Each agreed assertion becomes a versioned deterministic test.
Human judgement remains explicit as an attestation requirement.
The applied test-set version is retained with each evaluation.

Codify deterministic tests — shown with an AI service deployment case

Configuration

Connected

Decision test set

Version 1 · Repeatable and explainable

Test	Method	Failure result
Complete request	Deterministic	More information
Required authority	Deterministic	Higher authority required
Evidence suitability	Reviewer attestation	Review required
Valid expiry	Deterministic	Deny

Flow 02 of 08

Patent Pending · AU 2026203358

Capture

Record the case, its scope and context.

One concrete decision begins. It gets a stable identity, a single authoritative place it can be edited from, and a scope of assets, services and controls that the rest of its life is matched against.

Select any step to see what it records and the view itself.

Core or gatewayChoose the operating channelUse MyRISK directly or nominate a customer gateway as the decision authority. API, or the screen for manual casesCreate or receive decisionCapture reason, impact, scope, parameters, expiry and affected controls. Internal correlation, shownLink services, assets and controlsConnect the decision to the subjects and obligations it affects.

Choose the operating channel

This is about edit authority, not data replication. One interface is permitted to change decisions, so Core and the gateway cannot both claim to hold the authoritative version.

What it records. Which interface currently holds edit authority, who changed that and when, and exactly how many cases moved across.

What happens next. Gateway mode becomes active only after an empty gateway imports every exact Core packet and Core accepts the completion manifest.

Only one location can change decisions at a time.
A customer may operate directly in MyRISK or through a nominated gateway.
Non-authoritative interfaces remain available for review but not conflicting edits.

Choose the operating channel — shown with an AI service deployment case

Configuration

Connected

Decision authority

Choose one authoritative location for decision changes.

MyRISK active

Controlled transfer

Gateway active

MyRISK

Read-only during gateway authority

Customer gateway

Active authority

Create or receive decision

Here one concrete decision begins. Decisions normally arrive through the API, raised by the system that is already doing the work; the screen exists for the manual cases. Either way the case gets a stable identity and the facts the requirements and assertions will later be tested against.

What it records. What is being decided and by whom — the type, the requester and their department, the risk tier and impact, the business reason, and the parameters the tests will later read.

What happens next. The case can move to evidence and review when its required scope and business facts are complete enough to identify what is actually being decided.

Structured fields capture the business context required for later validation.
Scope limits exactly what the decision covers.
Expiry and decision facts become testable inputs.

Create or receive decision — shown with an AI service deployment case

Dashboard

Connected

New decision

Create a structured decision record.

Decision

Decision type

AI deployment approval

Risk tier

High

Title

Customer service AI deployment

Business reason

Business-critical requirement with documented temporary conditions.

Scope and timing

Subject

AI-CS-ASSIST

Requested until

30 days

Create decision

Link services, assets and controls

Correlation happens inside Trace, against the payload that arrived with the decision: the services, assets and controls it touches are resolved and attached to the case. Nobody drives it — the view below is how you see what a decision was correlated to. That resolved scope is what operational events are matched against later, which is why it is fixed before approval rather than after it.

What it records. Which services, assets and controls the decision touches, how each is affected, and whether compensating controls are in place and adequate.

What happens next. The scope is settled when it shows exactly what is included, what is excluded, and which obligations the decision changes.

Services and assets identify what is covered.
Control links show which obligation is affected.
Compensating controls form part of the decision basis.

Link services, assets and controls — shown with an AI service deployment case

Dashboard

Connected

Decision scope

Type	Reference
Asset / service	AI-CS-ASSIST
Business owner	Customer Operations

Affected control

Required control and agreed compensating treatment.

Explicit scope

Flow 03 of 08

Patent Pending · AU 2026203358

Evidence & authority

Build the basis for accountable judgement.

This is how one decision case is processed inside Trace. Operating through the API, none of it asks anything of a person at a screen: evidence references, attestations and approvals arrive as payloads from the systems already doing the work. The screens exist for a decision entered by hand, or for facts that cannot be sent through the API. Two human acts stay separate either way — a judgement that a piece of evidence is adequate, and an approval of the decision itself under a named role.

Select any step to see what it records and the view itself.

EvidenceConnect supporting evidenceRecord references, hashes, metadata or declarations without requiring every file to be copied. AttestationReview evidence suitabilityRecord a reviewer’s judgement about evidence quality, relevance or sufficiency. AuthorityApprove or rejectRecord the approver, the role they act under, their outcome and comments.

Connect supporting evidence

Evidence is attached as a controlled reference and hash rather than by copying the material. Privileged contents can stay where they are and still be provably the evidence that was relied on.

What it records. For each item: the requirement it satisfies, where it came from, when it was produced and by whom, whether it is sufficient, and whether it may be replayed or exported.

What happens next. The item is not treated as suitable merely because it exists; required reviewers still attest to its relevance, freshness and sufficiency.

Evidence may be referenced without copying the source document.
Hashes and metadata identify what was relied upon.
Privilege and export restrictions travel with the evidence record.

Connect supporting evidence — shown with an AI service deployment case

Dashboard

Connected

Add evidence

Record an evidence reference for the selected decision.

Evidence requirement

Technical or policy support

Handling

Reference only

Source

Controlled document store

Reference

DOC-AI-CS-ASSIST-2026-09

Privileged

Yes

Export treatment

Exclude

Add evidence

Review evidence suitability

An attestation is a judgement about evidence, not approval of the decision. A reviewer states whether a specific evidence requirement or assertion is adequately satisfied, and that statement is bound to the exact payload reviewed.

What it records. Who attested to what, under which role, whether they accepted or rejected it, their statement, and a hash of the exact material they reviewed.

What happens next. The relevant requirement becomes satisfied only when the correct role attests to the exact current material.

Approvals and evidence attestations are separate accountable actions.
The actor and the role under which they act are recorded.
Comments preserve the reviewer’s reasoning.

Review evidence suitability — shown with an AI service deployment case

Dashboard

Connected

Decision approval

This action authorises the overall decision after reviewing its current basis.

Required authority

CISO

Approver

authorised.approver

Decision

Approve with conditions

Payload reviewed

Case snapshot · hash 1b42…9e11

Comment

Approved for 30 days, revocable on material model or data-use change, and subject to continued operation of compensating controls.

Record approval

Approve or reject

Approval records authority over the decision itself, separately from evidence attestation, and is checked against the approver role the risk tier requires.

What it records. Who approved or rejected the decision, the role they acted under, the role the risk tier required, their comment, and a hash of the payload they approved.

What happens next. Validation can recognise authority only if the recorded role meets the configured requirement and the approval is bound to the current decision payload.

Approvals and evidence attestations are separate accountable actions.
The actor and the role under which they act are recorded.
Comments preserve the reviewer’s reasoning.

Approve or reject — shown with an AI service deployment case

Dashboard

Connected

Decision approval

This action authorises the overall decision after reviewing its current basis.

Required authority

CISO

Approver

authorised.approver

Decision

Approve with conditions

Payload reviewed

Case snapshot · hash 1b42…9e11

Comment

Approved for 30 days, revocable on material model or data-use change, and subject to continued operation of compensating controls.

Record approval

Flow 04 of 08

Patent Pending · AU 2026203358

Validate

Apply repeatable tests and resolve gaps.

Completeness and validity are different questions, asked in that order. On the API path the whole of it runs inside Trace; the steps below are where the progression can be watched. The deterministic assertions run against the assembled facts, and the same inputs return the same result whenever they are run again.

Select any step to see what it records and the view itself.

Validation gate · optional manual triggerCheck record completenessConfirm that the decision is ready to be tested—not necessarily valid. Rules-based validationRun deterministic testsCompare assembled facts with the applicable versioned assertions. Decision resultClassify results and actionsRecord passes, failures, missing inputs, reasons and the actions needed to proceed. Outcome · returnedRequest more informationReturn the case for evidence, correction, attestation or required authority. Outcome · terminalDeny or close decisionRecord a terminal outcome where requirements cannot be satisfied.

Check record completeness

For a decision arriving through the API this runs internally; the step here is the optional manual trigger, for a case somebody is working by hand. Either way it answers “do we have all the required inputs?” rather than “is this decision valid?” — a complete case can still fail its tests.

What it records. What is present, what is missing, and what to do about each gap.

What happens next. Evaluation runs only once the required inputs are present — and a complete case can still fail its tests.

Completeness means the record is ready to test—not that it will pass.
Missing evidence, authority and attestations remain visible.
The same view guides the user back to required actions.

Check record completeness — shown with an AI service deployment case

Dashboard

Connected

Completeness

Evaluation

Trail

Ready to evaluate?

This gate checks that every required input exists; it does not decide whether those inputs pass.

Required input	Present?	Recorded object
Reason, risk and duration	Yes	Case Customer service AI deployment
Scoped subject	Yes	AI-CS-ASSIST
Technical evidence	Yes	DOC-AI-CS-ASSIST-2026-09
Evidence attestation	Yes	Evidence reviewer
Decision authority	Yes	CISO

Run evaluation

Run deterministic tests

Evaluation executes the versioned assertions against the assembled case, turning stored facts and recorded human judgements into reproducible assertion results. The test-set version is retained with the result, and the view is where the progression through validation can be watched assertion by assertion.

What it records. Evaluation ID/time, input facts, test-set version, result and reason for every assertion, blocking reasons, required actions and provisional outcome. (Patent Pending · AU 2026203358)

What happens next. A passing evaluation can advance to binding readiness; failures route to correction, higher authority or a terminal outcome according to the configured rule.

Tests compare actual facts with defined expectations.
Rules-based results remain repeatable and explainable.
Judgement-dependent requirements are sent to a person rather than guessed.

Run deterministic tests — shown with an AI service deployment case

Dashboard

Connected

Completeness

Evaluation run

History

Evaluation EVAL-1048

Test set: ai-deployment.v1

Deterministic run complete

Input state

AI-CS-ASSIST · High risk · 30 days · approved evidence snapshot

Payload fixed

Assertion	Input tested	Result	Reason
Request complete	Required fields	Pass	All mandatory facts present
Evidence suitable	Reviewer attestation	Pass	Required role attested
Authority sufficient	High risk	Pass	CISO approval recorded
Duration permitted	30 days	Pass	Within configured maximum

Classify results and actions

The outcome states what the evaluation means operationally, translating raw assertion results into the actions required before the case can proceed. It is a view of where the case now stands rather than a step anybody performs.

What it records. Whether each test passed, why, how serious a failure is, whether it blocks, and what the test set says should happen next.

What happens next. Blocking items are resolved and re-evaluated, a terminal denial is closed, or the case continues once every binding prerequisite passes.

Every test records a result and reason.
Blocking items produce clear required actions.
Earlier evaluations remain available after correction and re-testing.

Classify results and actions — shown with an AI service deployment case

Dashboard

Connected

Evaluation

Required actions

History

4Assertions passed

0Blocking failures

0Missing inputs

ValidProvisional outcome

Decision result

The evaluation has converted individual assertion results into an actionable case outcome.

Classification	Reason	Required action
May proceed	All blocking assertions passed	Confirm binding readiness
Monitoring required	Approval is conditional	Monitor: Material model or data-use change

Request more information

One of two outcomes, and the one with no view of its own: the case is returned rather than decided — for missing evidence, a correction, an attestation, or an authority it does not yet have.

This step has no screen of its own: it is a record and a routing rule rather than a view.

Deny or close decision

The terminal branch for a case that cannot satisfy a required condition. The evaluated basis is preserved rather than deleted, so a refusal can be explained later.

What it records. That the case was denied and by which evaluation, the assertion that ended it, the reason, who acted, and everything that came before.

What happens next. The case no longer proceeds to binding. A materially different request becomes a new case, formally linked to this one.

A denial is recorded as an explicit outcome.
The reason and evaluated context remain available for review.

Deny or close decision — shown with an AI service deployment case

Dashboard

Connected

Customer service AI deployment

Denied / closed

The decision did not satisfy a terminal assertion. Its evaluated context and reasons remain retained.

Outcome	Reason
Deny	Required condition cannot be satisfied within policy

Flow 05 of 08

Patent Pending · AU 2026203358

Bind

Issue the precise, time-bound decision.

This is bind-time control. An immutable snapshot fixes the exact basis, and the binding object issued against it is time-bounded, carries its continuing conditions, and stays revocable.

Select any step to see what it records and the view itself.

Valid decisionConfirm binding readinessAllow binding only after validation and authority requirements are satisfied. Exact decision contextCapture approved stateCollate the case, evidence, tests, approvals and attestations being relied upon. Authorised outcomeIssue binding decisionRecord the issuer, exact outcome, expiry and continuing conditions. Active decisionActivate and monitorMake the decision effective and enable its continuing-validity checks.

Confirm binding readiness

The final gate before an immutable binding object is issued. It confirms that the latest evaluation and the authority behind it still apply to the exact payload about to be bound.

What it records. The evaluation being relied on, whether binding is permitted, which blocking requirements have been satisfied, and the reason if it is not yet available. (Patent Pending · AU 2026203358)

What happens next. The issue action is enabled only while the current payload remains the one that passed and received the required judgement.

Binding remains unavailable until required tests and authority are complete.
The readiness result is recorded before a binding decision can be issued.

Confirm binding readiness — shown with an AI service deployment case

Dashboard

Connected

Binding readiness checkpoint

This is a final consistency check immediately before issuance.

Binding prerequisite	Latest exact reference	Status
Evaluation	EVAL-1048 · current payload	Bind ready
Approval authority	CISO · hash 1b42…9e11	Satisfied
Evidence snapshot	SNAP-2051 · hash 93c1…7ab4	Current
Blocking reasons	None	Clear

Capture approved state

The snapshot assembles the precise basis that will be bound, and fixes it. Later evidence or comments cannot silently become part of an earlier decision.

What it records. Case, scope, controls, evidence metadata, attestations, approvals, evaluation results, packet hash and audit-ledger head. (Patent Pending · AU 2026203358)

What happens next. The binding is issued against this exact snapshot, confirmed as the approved state.

The exact decision basis is collated into one approved state.
A cryptographic identifier represents those exact contents.
Later activity cannot silently become part of the earlier approval.

Capture approved state — shown with an AI service deployment case

Dashboard

Connected

Approved-state snapshot

The objects below are frozen as the exact basis to be issued.

Component	Exact object	Integrity reference
Case and scope	Customer service AI deployment · AI-CS-ASSIST	7a10…13c8
Evidence	1 current item · 1 privileged reference	93c1…7ab4
Human judgement	1 attestation · 1 CISO approval	1b42…9e11
Evaluation	EVAL-1048 · bind_ready=Y	2f90…ac32

Snapshot hash

sha256:7f9e…41c2

Ledger head

LEDGER-SEQ-18 · e82a…1130

Use this state for binding

Issue binding decision

Binding is the authoritative issuance step. A validated case becomes an effective, time-bounded decision carrying explicit continuing conditions -- and it stays revocable.

What it records. Binding object ID, case/evaluation references, issuer, issue time, approved outcome, expiry, revocation conditions and snapshot/integrity references. (Patent Pending · AU 2026203358)

What happens next. The binding becomes active and enters monitoring; changing its basis requires a new recorded action rather than editing the issued object.

The binding record states what was authorised.
Expiry and continuing conditions limit the grant.
The issuer and issue time form part of the permanent record.

Issue binding decision — shown with an AI service deployment case

Dashboard

Connected

Issue binding decision

Customer service AI deployment

Authorised outcome	Approve limited pilot
Issued by	authorised.approver · CISO
Effective	Immediately on issue
Expires	30 days after issue

Continuing conditions

1. Required compensating controls remain healthy.

2. Revoke when: Material model or data-use change.

State-changing conditions

Object to be issued

Snapshot 7f9e…41c2 will become immutable binding object BIND-3017.

Issue BIND-3017

Activate and monitor

The operational view of an issued decision: what is currently permitted, for how long, and which conditions can suspend, expire or revoke it.

What it records. Whether the decision is currently in force, from when until when, the conditions it must keep meeting, when it was last checked, and the approved basis behind it.

What happens next. The decision stays active while scheduled and event-driven checks pass; any material event is routed to monitoring.

The decision is now effective under its recorded conditions.
Monitoring begins against the defined scope and expiry.

Activate and monitor — shown with an AI service deployment case

Dashboard

Connected

ActiveCurrent binding state

26 daysTime remaining

2Continuing conditions

HealthyLast check

BIND-3017 · Customer service AI deployment

Applies to	Permitted outcome	Owner	Next scheduled check
AI-CS-ASSIST	Approve limited pilot	Customer Operations	2026-09-23 00:00Z

Condition that can end the grant

Material model or data-use change

Event monitoring enabled

Flow 06 of 08

Patent Pending · AU 2026203358

Monitor

Keep testing whether it remains valid.

Assertions define what must be true; monitored conditions define what must remain true. Operational facts arrive from the customer's own systems, are matched to the decisions they affect, and are tested against those conditions.

Select any step to see what it records and the view itself.

Customer systemReceive operational eventAccept a verified event about a scoped asset, service or operating condition. CorrelationMatch event to active decisionsFind binding decisions whose recorded scope includes the affected subject. Ongoing validationTest continuing conditionsCompare new facts and scheduled time checks with the conditions of approval. No action requiredKeep active and record checkPreserve successful checks as evidence that monitoring occurred. Condition failedSuspend, expire or revokeApply the defined action and preserve why the active decision changed.

Receive operational event

The machine ingestion point for a material fact from a customer system. The event is stored once, then correlated to whichever active decisions it bears on.

What it records. Where the fact came from, its own reference so the same one is not counted twice, when it happened, what it is about and what it says.

What happens next. Accepted events are matched by their subject to active decision scope; duplicate external IDs are safely recognised.

Customer systems send structured events through the gateway.
Producer verification is agreed as part of deployment.
External event identifiers make safe delivery retries possible.

This step has no screen of its own: it is a record and a routing rule rather than a view.

Match event to active decisions

Matching shows why a source event affects this particular decision. Correlation uses the event subject against the scope captured before approval.

What it records. Which decisions an event bears on, what it matched on, which continuing condition applies, and the result of the correlation.

What happens next. Each matched active binding is evaluated; unmatched events remain recorded without changing unrelated decisions.

The event subject is matched to the decision’s recorded scope.
Only active decisions covering that subject are evaluated.

Match event to active decisions — shown with an AI service deployment case

Dashboard

Connected

Incoming event

External ID	EVT-10482
Subject	AI-CS-ASSIST
Type	Material model or data-use change

Why this decision matched

Binding	BIND-3017
Recorded scope	AI-CS-ASSIST
Status	Active

Correlation result

The event subject exactly matches a primary scope item on one active binding. One continuing-validity check will run; unrelated decisions are not evaluated.

1 matched binding

Test continuing conditions

Here the binding's continuing-validity rules run against the event or scheduled time facts. This is distinct from the original approval evaluation: the question is whether the decision still holds, not whether it should have been made.

What it records. Which event was tested, on which binding and case, against which condition, what the answer was and why — and what that answer did to the decision. (Patent Pending · AU 2026203358)

What happens next. A passing check records no action; a triggered rule applies its configured suspend, expire or revoke transition.

New facts are tested against the conditions of approval.
Scheduled checks handle expiry even without an external event.
The action comes from the recorded condition.

Test continuing conditions — shown with an AI service deployment case

Dashboard

Connected

Continuing-validity check CHECK-4402

This is a new evaluation of the active binding—not a rerun of the original approval.

Recorded condition	New fact	Test	Result
Revoke if material model or data-use change	Material model or data-use change (Event EVT-10482) = true	condition_met = false	Triggered
Not expired	Current time before expiry	now < expires_at	Pass

Selected action

Revoke

Causal references

BIND-3017 · EVT-10482 · CHECK-4402

Keep active and record check

Proof that monitoring occurred even though nothing changed. A healthy result is evidence in its own right, not the absence of evidence.

What it records. That the check ran, when, what triggered it, which conditions were tested, and that the decision was left active. A pass is recorded, not inferred from silence.

What happens next. The binding remains active and awaits the next scheduled check, source event or expiry.

A healthy check is retained as positive monitoring evidence.
No-action results show that monitoring occurred rather than merely finding nothing.

Keep active and record check — shown with an AI service deployment case

Dashboard

Connected

Monitoring check retained

The condition was tested and did not invalidate the binding.

Check	Source	Result	Binding after check
CHECK-4398	Scheduled daily check	No action	Active

Why this matters

The retained pass demonstrates that monitoring executed at the scheduled time; it is not inferred from the absence of an alert.

Suspend, expire or revoke

Where a binding-state transition is applied and explained when a continuing condition fails. It is the causal link between an incoming fact and a suspension, expiry or revocation.

What it records. What the decision was before and after, what triggered the change, which condition failed, why, and when.

What happens next. The former grant is no longer active. Any later permission requires the defined reinstatement process or a new decision.

Revocation, suspension and expiry are distinct outcomes.
The triggering event, tested condition and state transition remain connected.

Suspend, expire or revoke — shown with an AI service deployment case

Dashboard

Connected

Binding state transition

Active

CHECK-4402 triggered

Revoked

Current effect

Permission no longer active

AI-CS-ASSIST is no longer covered by the Customer service AI deployment decision.

Triggering event	Failed condition	Transition time	Reason retained
EVT-10482	Material model or data-use change	2026-09-22 01:00Z	Continuing condition became false

Flow 07 of 08

Patent Pending · AU 2026203358

Continuous audit

Write the record as it happens, not afterwards.

The audit record is not produced at the end. Every material action, evaluation and state transition is appended as it occurs, the history is tamper-evident, and an acknowledged copy reaches MyRISK Core.

Select any step to see what it records and the view itself.

Audit creationCreate the audit trail continuouslyAppend each material action, evaluation and state transition as it occurs. Tamper-evident historyProtect and verify integrityLink retained events and verify that their order and contents remain consistent. MyRISK platformMaintain the central recordSynchronise material records, preserve acknowledgements and avoid competing writers.

Create the audit trail continuously

The audit trail is written as the work happens. Every material action, evaluation and state transition appends to it, so there is never a point at which somebody has to go and assemble one.

What it records. What happened, who did it, when, which decision it belongs to, a hash of the payload, and a link to the entry before it.

What happens next. Each new material action appends another event; prior entries remain available for integrity verification and replay.

Audit creation occurs throughout the workflow, not at the end.
Material actions are appended instead of overwriting earlier history.
Actors, times and decision context remain connected.

Create the audit trail continuously — shown with an AI service deployment case

Dashboard

Connected

Audit events

State replay

Integrity

Append-only material actions

Seq	Event	Actor/source	Object hash	Previous link
15	Approval recorded	authorised.approver	1b42…9e11	9e10…4cb2
16	Evaluation completed	trace-evaluator	2f90…ac32	1b42…9e11
17	Binding issued	authorised.approver	7f9e…41c2	2f90…ac32
18	Source event accepted	asset-monitor	e82a…1130	7f9e…41c2

Protect and verify integrity

Integrity verification checks whether the retained history still agrees with its recorded hashes and ordering. It tests the record, not whether the decision was a good one.

What it records. When the history was checked, how much of it, against which ledger position, how many entries, any mismatch found, and whether it verified. (Patent Pending · AU 2026203358)

What happens next. A successful check supports replay/export; any mismatch becomes an assurance incident requiring investigation.

The retained history is tamper-evident.
Integrity verification checks ordering, links and retained content.
Tamper-evident, not tamper-proof: if retained history is altered, the check shows it.

Protect and verify integrity — shown with an AI service deployment case

Dashboard

Connected

VerifiedOverall chain status

18Events recomputed

0Broken links

e82a…1130Current ledger head

Verification detail

Check	Result	Meaning
Sequence continuity	Pass	No missing or duplicated ledger sequence
Payload hashes	Pass	Recomputed values match retained hashes
Previous-event links	Pass	Every entry points to the expected predecessor

Tamper-evident: if the retained history is altered, this check shows it.

Maintain the central record

Synchronisation delivers the authoritative gateway record to MyRISK Core as an acknowledged central copy, without giving Core authority to change it.

What it records. What was sent to MyRISK Core and when it was received, how many attempts it took, and the acknowledgement Core returned.

What happens next. A successful acknowledgement closes the queue item; failures remain retryable while local decision work continues.

MyRISK Core and the gateway do not act as competing writers.
Acknowledged central records provide an independent operational checkpoint.
Temporary outages are handled through retained, retried updates.

Maintain the central record — shown with an AI service deployment case

Dashboard

Connected

Customer gateway

Active authority

Local changes are queued and delivered to MyRISK.

MyRISK platform

Central record current

Latest update acknowledged.

Delivery status

Decision	State	Platform
Customer service AI deployment	Active	Acknowledged

Flow 08 of 08

Patent Pending · AU 2026203358

Review, replay & reporting

Answer the question months later.

The point of all of it. A decision is replayed from retained objects rather than reconstructed from memory, and what leaves the system is scoped, logged and governed.

Select any step to see what it records and the view itself.

Assurance reviewReplay the decision historyReconstruct what was requested, supplied, tested, approved and later changed. ReportingCreate controlled exportsGenerate a scoped output while respecting privileged and excluded evidence. Export accountabilityRecord export activityRecord who exported what, when, why, in which format and with which exclusions. Customer policyApply retention and dispositionApply the agreed retention treatment while preserving required accountability. Defensible recordSupport audit and assurancePresent the complete basis, history and current validity of the decision.

Replay the decision history

Replay reconstructs the decision chronologically from retained events and immutable objects -- what was known at each point, and what changed since. This is the difference between replaying a decision and re-arguing it.

What it records. The whole life of the decision in order — its creation, evidence, attestations, approvals, every evaluation, the binding, the monitoring checks and every change of state. (Patent Pending · AU 2026203358)

What happens next. A reviewer can open the underlying object for any event or use the reconstructed record as the basis of a controlled export.

Replay reconstructs how the decision reached its present state.
Earlier failures and later corrections remain visible.
Reviewers can inspect the detail behind each event.

Replay the decision history — shown with an AI service deployment case

Dashboard

Connected

Audit events

State replay

Integrity

Decision reconstructed in business order

Request createdCustomer service AI deployment for AI-CS-ASSIST

Evidence reviewedDocument 93c1…7ab4 attested as sufficient

Authority recordedCISO approved snapshot 1b42…9e11

Binding issuedApprove limited pilot · 30-day expiry

Material model or data-use changeEvent matched, condition tested and state transition preserved

Create controlled exports

Export produces a deliberately scoped assurance artefact, applying privilege and export restrictions rather than dumping the underlying record.

What it records. What was exported and by whom, for what purpose and in what format, what was deliberately left out, and a hash of the file produced.

What happens next. The artefact is delivered through the approved channel, and the export itself is logged.

Exports are scoped to the selected decision.
Privileged or excluded material is omitted according to its handling settings.
The generated output receives its own integrity identifier.

Create controlled exports — shown with an AI service deployment case

Dashboard

Connected

Configure controlled export

Decision

Customer service AI deployment

Format

JSON

Actor

assurance.reviewer

Purpose

Quarterly control assurance

Include privileged evidence

Integrity status

Verified

Included

Case, scope, control links, evidence metadata, attestations, approvals, evaluations, binding and monitoring history.

Excluded

1 privileged evidence item marked exclude_from_export=Y. Its existence and exclusion reason remain visible.

Generate controlled export

Record export activity

The accountability record for disclosure. It is kept separately so a reviewer can see who produced decision material and why.

What it records. Who exported what, when, why, and what was deliberately left out — with a hash of the file they received.

What happens next. Reviewers can reconcile the log with the generated artifact and investigate unexpected or repeated exports.

Exporting is itself an auditable action.
The record captures actor, time, purpose, scope, format and exclusions.

Record export activity — shown with an AI service deployment case

Dashboard

Connected

3Exports of this case

2Distinct reviewers

1Restricted exclusion each

VerifiedLatest artifact hash

Export activity

Time	Actor	Purpose	Format	Exclusions	Artifact
22 Sep 01:20Z	assurance.reviewer	Quarterly assurance	JSON	1 privileged item	EXP-889 · a330…be19
18 Sep 04:10Z	grc.manager	Management review	CSV	1 privileged item	EXP-871 · 3f9a…1002

Apply retention and disposition

An illustrative policy configuration rather than a completed automated disposal feature. It shows where governed retention and disposition would be set.

What it records. Which class a record falls into, how long it is kept, what would hold or except it, who approves disposal, and how evidence is treated when it happens.

What happens next. Automated disposal stays off until the legal, records and audit owners have agreed the policy and its effect on linked histories.

Retention periods are yours to set; MyRISK does not impose one.
Disposal obligations and the need to keep a defensible record pull against each other, and the policy is where that is settled.

Apply retention and disposition — shown with an AI service deployment case

Configuration

Connected

Retention and disposition policy

Illustrative extension requiring customer policy and implementation agreement.

Record class	Retention treatment	Approval
Binding decision history	Customer-defined period	Records owner
Restricted evidence reference	Policy-specific disposition	Legal / records review

Illustrative extension

Support audit and assurance

The assurance view combines the original basis, the authority, the binding terms, the monitoring results and the integrity checks, answering both “what was decided” and “can this record be trusted”.

What it records. Where the decision stands now, the basis it was approved on, who had authority, every evaluation and monitoring check since, whether the ledger verifies, and what has been exported.

What happens next. The record supports audit, management review, incident analysis, or a new governed decision.

Assurance uses the evidence, tests, authority, binding terms and later monitoring together.
The reviewer sees both the current state and how it was reached.

This step has no screen of its own: it is a record and a routing rule rather than a view.

Which decision would be hardest to defend next month?

A fixed-scope, fixed-price Decision Defensibility Diagnostic replays one real decision and shows precisely where it breaks.

Book the Diagnostic →