Docs menu
The mechanism behind the platform's ALCOA+ mapping.
The ALCOA+ mapping 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 — receiving a sample, approving a disposition, 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 ALCOA+ 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 ALCOA+ 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 GxP 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 chain-of-custody timeline is composed from audit data.
The chain-of-custody 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, return, and disposition records into a single per-sample timeline, from receipt through final disposition. There's one source of truth underneath both views.
Compliance surfaces are access-gated like everything else.
The audit trail, custody 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 chain-of-custody 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 (destruction, waivers, study closure) — captured meaning/intent, session-authenticated, and non-repudiable
- A real-time data-integrity dashboard for QA/Admin roles — retrospective-entry counts, failed validations, and anomaly surfacing
- A per-field data-lineage view — which source system and submitter a stored value traces back to, per sample
- A one-click regulatory inspection data package — manifest, custody, audit, and shipment history for a study and date range, exported with a verifiable hash
- Jurisdiction-aware compliance profiles for multi-region studies, applying the most-stringent-applicable rule across regulatory regions
- Server-enforced data-classification tiers, applied to every exported or printed document
- A GDPR Data Subject Rights workflow — access, rectification, erasure, restriction, and portability, with retention-conflict handling
- A GAMP-5 aligned validation lifecycle — sandbox through production promotion — for computer-system validation