Docs menu
How the platform's validation approach affects your CSV burden.
Compliance is built into the platform's architecture rather than added through configuration. This section covers what's validated at the platform level, and what your QA team still validates.
Compliance is enforced by the node architecture.
Traditional systems prove compliance by validating a configuration, then re-validating on every change. CMS Life Sciences builds compliance into the node architecture, so validation is continuous and built in rather than a manual re-do on every release.
- Every node maps to an ALCOA+ principle — see the full mapping at /compliance
- A change to the system is itself readable and auditable
- Reason-for-change is captured structurally, not by policy alone
- The audit trail is immutable and append-only
- Data is available for audits via surface views and CSV export — not a data-pull request to us
- Access is gated by role, so every screen a user sees is already within their authorized scope
Every mutation requires a categorized reason.
When a user corrects a record, the platform requires a structured reason before the change is accepted — the same categories your CSV process already recognizes.
| Category | When it applies |
|---|---|
| Correction of error | Fixes a data-entry or process mistake. |
| Additional information | Adds detail that wasn't available at the time of entry. |
| Protocol amendment | Reflects a change to the study protocol. |
| Sponsor request | Made at the sponsor's direction. |
| Regulatory requirement | Required to meet a regulatory obligation. |
| System-generated | Automated correction (e.g. reconciliation), still attributable. |
| Other | Requires a free-text note — the only category that does. |
Reports available to auditors today.
These reports exist in the running application, not as mockups, and compose into a single exportable audit trail.
Chain-of-custody report
Composes audit events, distribution, and disposition into one timeline per sample, from receipt through final disposition.
Audit trail
Immutable, attributable event log — every event tagged with the specific ALCOA+ principle it satisfies, filterable by user and action type, and exportable to CSV for your auditors.
Ethics & consent approvals
Ethics-approval tracking with expiry alerts, satisfying ICH GCP consent-gating requirements.
Effort & capacity reporting
Manager-level effort broken down by workflow stage (reception, distribution, reconciliation, disposition) — useful evidence for staffing and workload review during an inspection.
Regulatory standards this platform is built against.
21 CFR Part 11
Digital records with an immutable, hash-verified audit trail — every governed change is attributable, contemporaneous, and carries a structured reason.
GxP
Structured reason-for-change captured on every governed data mutation, enforced by a build-time gate rather than by review.
ICH GCP
Ethics-approval tracking with expiry alerts and consent gating.
What this page covers, and what it deliberately does not.
Most validation activity on a deployment like this is performed by the customer or a customer-nominated contractor. This page describes the half a supplier can answer before that work is scoped: what the platform generates as evidence, how it is built and released, and which of our own test evidence transfers into your validation.
- Covered: the responsibility split, our SDLC and change control, the traceability shape, and which supplier-side evidence is transferable.
- Not covered: your validation methodology, approach or plan. Those are yours — the processes used for validation are decided by the system owner, and we do not propose them.
- Supplied, not described here: IQ and OQ protocol documentation for the product, as part of the standard validation package. What it contains is agreed at contract stage against your CSV procedure.
- Not covered: the concrete QA engagement process, which depends on your quality organisation's own governance.
- The system does not validate itself. Protocol authoring, execution, review and approval remain human work, and the customer remains accountable for the validated state of its systems.
- Evidence produced as a by-product of operation is still supplier testing. It demonstrates that the system behaves as built — it does not demonstrate that your configuration is correct or that the system is fit for your intended use, and it does not reduce performance qualification.
Who does what, across the validation lifecycle.
R = performs · A = owns the outcome. This is the allocation we propose, and it is the same allocation as the contractual responsibility matrix — deliberately, so the technical and commercial answers cannot drift apart.
Planning
We author the Validation Plan and the GAMP 5 categorisation; you approve them, and you own risk assessment, validation scope, and any supplier assessment or audit of us.
Specification
You own the User Requirements Specification. We author the Functional, Configuration and Design Specifications and the traceability matrix from URS through FS to test, for your approval.
Testing and qualification
We author the IQ and OQ protocols and supply the evidence they are executed against. You execute them, or your nominated contractor does. You own PQ and UAT, because performance qualification tests the system against your actual process — which is yours, not ours. We record and investigate deviations; you approve them.
Reporting and release
We author the Validation Summary Report and the training materials. You approve the report, deliver training, and make the release-for-GxP-use decision.
Operation
You own periodic review, change control decisions and audit-trail review, and backup, restore and business-continuity testing. We own change impact assessment, regression protocols and evidence, and revalidation on change. All of it runs against evidence the system produces as a by-product of normal use rather than as a separate documentation exercise.
Infrastructure
The platform is deployed into your tenancy under your identity. Infrastructure qualification follows your own hosting controls; we supply the deployment evidence for what we place into it.
How a change gets from a request to your environment.
This is the part of validation where a supplier's answer is either specific or it is nothing. Ours is specific because the controls are mechanical rather than procedural.
- Every change enters as a tracked unit of work with a stated requirement behind it — a change with no requirement has nowhere to land.
- Requirement coverage is enforced by tests that fail the build, not by a reviewer remembering. A governed write with no corresponding audit event reds the build.
- Versioning is explicit and monotonic; environments are promoted rather than edited, so what you qualify is the artifact that ships.
- Defects are recorded against the requirement they violate, so a defect trend is readable per requirement rather than per release note.
- Release evidence — what changed, who approved it, what it was tested against — is generated by the pipeline, not assembled afterwards.
Requirement → specification → test → evidence → state.
A traceability matrix is normally reconstructed by hand at the end of a project. Ours is the working state of the build, which means it is current by construction rather than current as of the last time somebody rebuilt it.
Requirement
Your words, carried verbatim, with an identifier we do not reassign.
Specification
The phase that states how it gets built — not a lane it is merely mentioned in.
Test
A named assertion about behaviour. The test name states the claim, so a reviewer can judge the claim without reading the implementation.
Evidence
A recorded run of that test against the running system, addressable per requirement.
State
Derived from the above and gated — a state that stops being true fails a build rather than going quietly stale.
A traceability link demonstrates coverage. It is not a qualification record, and we do not offer it as one — qualification is protocol execution against acceptance criteria, and that work is described in the responsibility split above.
What of our testing you can rely on, and on what terms.
The useful question is not whether we test, but which of our evidence reduces work your team would otherwise repeat.
Functional test results
Per-requirement assertions with their results, versioned against the release they ran on. These support OQ rather than replacing it, and they are the largest single reduction in duplicated effort.
Audit-trail integrity evidence
Hash-chain verification from genesis to tip, exportable and independently re-verifiable. You do not have to take the trail's integrity on our word.
Recorded demonstrations
Addressable per requirement, so a reviewer can watch the specific behaviour a specification clause describes without watching a whole walkthrough to reach it.
Supplier audit
We will host a supplier audit and will show the development process, the change-control record, the test evidence and the release history for the system you are buying.