Appearance
Cross-Module Journeys
Individual module documentation tells you what each register does. These articles show what happens when a real situation moves through several of them.
Each journey is a single worked example, followed end to end, with the records that get created at each step and the decisions that get made.
The journeys
| Journey | Starts with | Ends with |
|---|---|---|
| Regulation to Compliance | A regulator publishes | A governed compliance determination |
| Framework Adoption to SoA | A decision to adopt a standard | A Statement of Applicability for an assessor |
| Control Failure to Remediation | An indicator fails | A verified fix, or an accepted deviation |
| Incident to Risk | Something goes wrong | A closed incident and an updated risk position |
| Audit Journey | An audit plan | A signed opinion and validated finding closure |
| Third-Party Onboarding | A proposed supplier arrangement | An approved engagement under lifecycle governance |
What these examples are
The organisations, records and figures are fictional, constructed to illustrate the platform. They use realistic enterprise situations — a bank adopting a standard, a regulator publishing a circular, a payments incident — because those are the situations the platform is built for.
Where a journey references a specific standard's structure, it is labelled as an illustrative example rather than a claim about that standard.
The pattern they all share
Every journey shows the same underlying discipline:
- Something happens — externally, or in the control environment
- A person decides what it means — the platform surfaces, it does not conclude
- Governed records are created with owners, dates and references
- Approval routes through the organisational workflow layer with segregation of duties
- The position updates truthfully, including where the truthful position is "we do not know"
- The whole chain remains reconstructable afterwards
If you read only one, read Regulation to Compliance — it traverses the most modules.