GxP Copilot · Every artifact, canonical and provable

One source of truth for every document version, section and status.

Every document version is fingerprinted and tagged with its provenance and any AI assistance used. Data-driven sections stay canonical across every deliverable — so what you sign is what you keep, and what you keep is what you show an auditor.

Quick chat on WhatsAppPart of GxP Copilot

GxP Copilot: Document Control & Versioning

Anchored to requirementsLinked as it is drafted

Human reviewBefore anything is approved

In short

Document control keeps approved records trustworthy. In GxP Copilot a signed version is frozen at the database level — its content, hash and version cannot be changed and it cannot be deleted or un-frozen. Corrections happen the only legitimate way: a new version with its own review and approval cycle.

The problem

"How do you know this record has not been altered?"

It is a reasonable question and most organisations answer it procedurally. Nobody is supposed to edit an approved document. There is an SOP. Access is restricted. The audit trail would show it.

Each of those is a control, and each depends on something continuing to work — a permission set that nobody changes, an application rule that no future release bypasses, a log that someone reads. They are assurances about intent rather than statements about what is possible.

The question an inspector is really asking is whether the record could have been altered, not whether anyone was supposed to alter it.

How GxP Copilot handles it

Frozen in the database, not in the application

Once a document version is signed, its content, its hash, its version number and its file are immutable, and the record cannot be deleted or returned to an editable state. The rule is enforced at the data layer, so it holds regardless of which part of the system attempts the change.

That turns a procedural answer into a structural one. 'It cannot be edited' is a stronger position than 'it must not be edited', and it is the kind of difference that shortens an inspection conversation.

Audit trail

14:32Signed: Approved for releaseQA Manager
11:05Changed risk of URS-015Validation lead · Supplier test evidence acceptedMedium → Low
10:48Edited expected result, OQ-07Validation lead · Lockout after 5 attempts, per URSv3 → v4
09:12Recorded result, OQ-07Tester · Evidence attachedPassed

Append-only. Entries cannot be edited or deleted.

Who, what, when and whyOn every change

An audit trail an inspector can read: who did what, when, the old and new value and the reason. Entries are append-only and each one is linked to the one before, so a changed or missing entry shows.

Revisions preserve approved text

A revision typically changes a small share of a document. In most systems revising an approved document means generating a fresh draft and comparing it against the old one by eye, hoping nothing shifted in the sections that were supposed to stay the same.

Here, the approved version is the baseline. Only the sections your change basis actually affects are revised; every other section is carried across unchanged, and the platform can show you which is which, section by section. A revision you can describe as a defined percentage changed and the remainder untouched is far easier to review and far easier to defend.

Versions that match reality

Documents approved outside the platform enter at their real version. A URS approved at v12.0 comes in as v12.0, and its next revision is v12.1 — not a system restarting the numbering at v0.1 and leaving your document history looking like the system was installed yesterday.

Deliverables

What you get

Signed versions physically immutable — content, hash, version and file cannot be altered or deleted

Corrections handled as new versions with their own approval cycle, never as edits

Revisions that preserve approved text and show exactly what changed, section by section

External approved documents imported at their true version number

A structural answer to the question of whether a record could have been altered

Summary

What Document Control & Versioning delivers

Document Control & Versioning is part of the GxP Copilot platform — an AI-native, CSA-first validation system built for regulated Life Sciences. See how it fits with AI Classification Engine, Risk-Based Validation Scoping, AI Risk Assessment.

validation metadatadocument provenancecontrolled documentsvalidation metadata

Content fingerprints per version
Provenance and AI-assist tagging
Canonical, data-driven sections across deliverables
One record of truth across the estate

FAQ

Common questions

Prefer to talk first? Chat with us on WhatsApp or book a call with an expert.

Chat on WhatsApp Talk to an expert

Can an approved document be edited?

No. Once a version is signed its content, hash, version number and file are immutable, it cannot be deleted, and it cannot be returned to an editable state. Any attempt fails at the data layer. A correction is made by creating a new version that goes through its own review and approval.

What happens when we revise an approved document?

The approved version becomes the baseline. Only the sections affected by your stated change basis are revised; the rest is carried across unchanged. The platform shows which sections changed and which did not, so a reviewer reads the delta rather than re-reading the whole document hoping nothing shifted.

Can we bring in documents approved outside the platform?

Yes, and they enter at their real version. A URS approved at v12.0 is registered as v12.0 and its next revision becomes v12.1. This matters when you are revalidating an existing estate, where restarting every document at v0.1 would misrepresent its actual control history.

Related capabilities

All capabilities

AI Classification Engine

A guided intake — accelerated by AI, decided by your team — produces GxP impact, GAMP category and composite risk, along with the exact reasoning behind each result. Instead of week-long assessments, you get a classification you can defend to an inspector on the same day. The AI accelerates the input; the classification itself is transparent and controlled.

Learn more about AI Classification Engine Risk-Based Validation Scoping

The Strategy Engine picks the applicable deliverable set for each GAMP category and scales test rigor to per-requirement risk under CSA — choosing between scripted testing, unscripted verification, and leveraged supplier evidence. The output is a validation plan sized to reality, easy to defend, and quick to execute.

Learn more about Risk-Based Validation Scoping AI Risk Assessment

Every requirement is scored against an ICH Q9 lens for severity, probability and detectability. That score drives the test strategy, the traceability coverage and the inspection-readiness view — so risk stops being a compliance formality and starts sizing your actual work.

Learn more about AI Risk Assessment AI Validation Document Drafting

The Documentation Engine drafts your validation deliverables in the style of the templates your organisation already uses — with confidence checks, review gates, and a fully functional fallback when the AI is unavailable. Your team stays in control; the platform removes the drudge work.

Learn more about AI Validation Document Drafting Live Traceability Matrix

The Live RTM is always up to date — coverage gaps, orphan tests and inspection-readiness are computed on the fly from the links between requirements, design, tests and results. No more spreadsheet upkeep, no more RTM-freshness debates before an audit.

Learn more about Live Traceability Matrix AI Test Case Generation

Installation, Operational and Performance Qualification protocols are drafted from your requirements and design, right-sized by the risk engine, and structured for straightforward execution. Effort follows risk — high risk is scripted with an independent witness, medium is scripted or hybrid, and low risk can be unscripted with supplier evidence.

Learn more about AI Test Case Generation