Validation evidence generated from the architecture — not authored after it.
What a quality director or Responsible Person actually receives from us when the system has to be validated for its intended use under EU GMP Annex 11 and GAMP 5.
You validate the system. Our job is to make that inexpensive and defensible.
Under Annex 11 the regulated company validates its computerised systems for their intended use, in its own operating environment, against its own requirements. That responsibility is not transferable, and no vendor can discharge it for you. What a vendor can do is arrive with the supporting evidence already built, structured, and current.
Truth QMS is designed as a GAMP 5 category 4 configured product. Brand packs, module selection, your SOP set, roles, workflows and training matrix are all configuration of the shipped product — not custom code written for your site. That distinction is what keeps your validation effort proportionate: you validate a configured standard product, with the vendor evidence underneath it, rather than a bespoke application you must qualify line by line.
We support your validation lifecycle end to end — planning, requirements, the qualification runs, and the report — but the validation decision, the approvals and the record remain yours.
The traceability matrix is generated, never hand-maintained.
In most projects, traceability is a spreadsheet somebody updates after the fact — and it is stale the moment the build moves. Here the requirements are structured records inside the system, and the matrix is an output of those records.
Structured URS / FS / DS records
User requirements, functional specifications and design specifications are held as records with explicit parent links — each FS declares the URS it satisfies, each DS the FS it realises. The requirement hierarchy is queryable data, not prose in a document nobody can diff.
Matrix generated from records plus tests
The traceability matrix is produced by walking the requirement records and the automated test suite together. Nobody types it. A requirement with no covering test, or a test citing a requirement that does not exist, shows up as a gap in the generated output rather than as a silent omission.
Your URS lives in the same store
Your site-specific user requirements are entered into the same requirement store under a customer namespace, alongside the product URS. Your requirements trace through the same generated matrix and appear in the same evidence, instead of living in a separate document that has to be reconciled by hand.
A suite run produces the evidence bundle. Your OQ largely becomes executing it.
Automated tests are named by requirement id, so the link between a requirement and the test that exercises it is mechanical rather than editorial. Running the suite is therefore also an evidence-producing act.
- Suite output The complete run result, with each test attributed to the requirement it covers, and pass or fail recorded per test.
- Traceability matrix Generated in the same run, from the requirement records and the tests that executed — so the matrix and the evidence always describe the same build.
- Build identity The exact version of the software the evidence was produced against, so an auditor can tell whether the bundle in the binder matches the system in use.
- Environment manifest The runtime and platform the run was executed on, so the qualified configuration is stated rather than assumed.
What this changes for your qualification
Your operational qualification largely becomes executing the vendor evidence run on your own instance, reviewing the output, and countersigning it — supported by OQ script templates we ship, each mapped to the FS records it verifies. Your performance qualification stays yours: your processes, your data, your people, exercised on the configured system.
ALCOA+ enforced in the data layer, and written down for the inspector.
Data integrity is a property of the storage model here, not a policy asserted on top of an editable database. Every record change is an append-only, hash-chained event: prior states are never overwritten, corrections are recorded as new events that reference what they correct, and the chain makes silent modification detectable rather than merely discouraged.
Electronic signatures carry signer, time and meaning — who signed, when, and in what capacity (authored, reviewed, approved) — bound to the record version they applied to. Attributable, legible, contemporaneous, original and accurate, plus complete, consistent, enduring and available: the ALCOA+ principles are anchored in the data layer—the attributability, originality and completeness properties enforced as record-level constraints, the operational properties (endurance, availability) addressed through the platform’s retention and export design.
The audit-trail design rationale document
We maintain a standing vendor document describing exactly how this works: append-only enforcement, the hash-chain construction, e-signature semantics, the correction model, and retention and export. It is the document you hand an inspector who asks how the system ensures data integrity, and it is written to the expectations set out in EU GMP Annex 11 for computerised systems and electronic records.
Expectations around audit trail review come from the PIC/S guidance, PI 041, rather than from Annex 11, and the document addresses them separately: what a reviewer is actually given to work with, how exceptions surface, and how the system makes review feasible rather than theoretical.
Because the document is maintained against the shipped design rather than written for a single deal, it does not go stale between customers — and when the design changes, the document changes with it.
The supplier-audit answers are prepared before you ask for them.
A GAMP 5 supplier assessment asks a predictable set of questions: quality management of the development process, requirements and design control, testing and release, configuration and change management, security and access control, backup and restore, incident handling, and support arrangements.
We keep a prepared answer pack covering those categories, and every answer cites the real mechanism in the system rather than a reassurance — the requirement store, the generated matrix, the evidence bundle, the event model, the access model. If your assessment questionnaire asks something the pack does not cover, the answer comes back with the same standard: name the mechanism, or say plainly that it does not exist yet.
Postal-audit questionnaires get answered from that same pack rather than drafted from scratch each time.
Ask us for the validation story in full.
We will walk your quality director or Responsible Person through the requirement records, a live evidence run, and the audit-trail design rationale — on the working system, in the detail your validation plan needs.