Docs menu
The mechanism behind the platform's governance mapping.
The governance-principles table at /compliance tells you what's guaranteed. This page explains the mechanism underneath it — how every mutation produces its own compliance evidence, structurally, as part of the operation itself.
Audit capture happens as part of the same operation.
Every data-mutating action — commissioning an asset, approving a decommissioning, resolving a reconciliation — runs through a capability method that writes its audit record as part of the same operation. There's no separate logging step to forget, disable, or fall out of sync with the data.
- Every mutation and its audit record are written together, not in two steps a developer could split apart
- The audit write isn't conditional on success alone — failed and rejected actions are captured too
- Each record is tagged with the specific governance principle it satisfies, not a generic "event logged" entry
- Structured reason capture is enforced at the same layer — an action without a required reason is rejected before it reaches storage
What an audit record contains.
An audit record isn't a free-text log line. It's a structured entry with everything an auditor needs to trust it on its own.
Who, what, when
User, action type, and the specific entity affected, paired with a system-generated timestamp — attribution and contemporaneity captured together, not reconstructed later.
Principle-tagged
Each entry names the governance principle it satisfies, so the audit trail itself is the mapping — not a separate document that claims to describe it.
Structured reason
Corrections carry a categorized reason-for-change, not just a note — the same categories used throughout the Validation Guide's evidence.
Append-only by construction
Every mutation creates a new record; existing entries are never updated or deleted. Today that's a code-level guarantee enforced by the capability layer's access pattern — see Roadmap below for where this is headed.
How Original and Contemporaneous are determined automatically.
Original
The first time an entity's data is recorded, the platform checks audit history at write time and finds nothing prior — the entry is tagged Original automatically.
Contemporaneous
Any later write to the same entity is a correction, not a replacement. It's tagged Contemporaneous, requires a structured reason, and leaves the original entry untouched and readable.
The asset-history timeline is composed from audit data.
The asset-history report isn't a parallel record-keeping system that could drift from the audit trail. It's composed at read time from audit events plus transfer and decommissioning records into a single per-asset timeline, from commissioning through end of life. There's one source of truth underneath both views.
Compliance surfaces are access-gated like everything else.
The audit trail, asset-history report, and their exports are visible only to roles with the matching access right (compliance:view, compliance:export). See Roles & Access Administration for how those rights are assigned, and the Configuration Guide for the full role mapping.
Roles & Access AdministrationEnforced in code today.
Append-only capture, principle tagging, reason-for-change enforcement, and composed asset history are live in the running application today — not a roadmap promise.
Stronger, independently verifiable integrity guarantees.
We're exploring how to move from a code-enforced guarantee toward one an auditor can verify independently of the application — plus a few other capabilities that come up repeatedly in compliance-heavy evaluations.
What we're exploring — not yet committed.
- Cryptographic tamper-evidence for the audit trail — hash-chaining each entry to its predecessor, so integrity can be verified independently of trusting the application
- Electronic signatures for operational sign-off events (decommissioning, waivers, project closure) — captured meaning/intent, session-authenticated, and non-repudiable
- A real-time data-integrity dashboard for compliance/admin roles — retrospective-entry counts, failed validations, and anomaly surfacing
- A per-point data-lineage view — which source system and submitter a stored value traces back to, per asset
- A one-click regulatory inspection data package — intake, history, audit, and transfer records for a project and date range, exported with a verifiable hash
- Jurisdiction-aware compliance profiles for multi-region portfolios, applying the most-stringent-applicable rule across regulatory regions
- Server-enforced data-classification tiers, applied to every exported or printed document
- A tenant data-rights workflow (GDPR-aligned) — access, rectification, erasure, restriction, and portability, with retention-conflict handling
- A GAMP-5-style aligned validation lifecycle — sandbox through production promotion — for computer-system validation