Computer system validation software for paperless CSV and qualification

What the module does

• Five validation types: equipment, facility and utilities, process, cleaning, and computer systems (CSV) with a GAMP 5 software category of 1, 3, 4 or 5, each project with its system, risk level, target date and change control reference.
• A validation plan drafted by the AI with the approach, scope, deliverables, acceptance criteria, prerequisites and risks, and 10 to 30 activities across planning, pre-execution, execution, reporting and closure, each with an owner and a due date; assignees are emailed and one view tracks open, overdue and unassigned activities across projects.
• Eighteen document types from templates that carry the Part 11, Annex 11 and good documentation practice elements: validation plan, URS, risk assessment, supplier assessment, functional, configuration and design specifications, DQ, IQ, OQ, PQ, PPQ and cleaning validation protocols, traceability matrix, test execution record, qualification report, validation summary report and protocol deviation report.
• AI drafting of every section, with 4 to 20 test cases per protocol (steps, expected results and acceptance criteria); facts the AI cannot find are left as [placeholders] for the author.
• Electronic test execution of an approved protocol: each step recorded as it is performed with the actual result, pass or fail and evidence, under the tester's name and the server time. A failed step ends the run, a deviation is raised, and the retest states its reason.
• For computer systems, a system assessment (intended use, GxP impact, Part 11 and Annex 11, data criticality, hosting, supplier), a requirements register with a GAMP 5 functional risk assessment of severity, probability and detectability, and the deliverables GAMP 5 expects for the software category and risk.
• Verification scaled to risk in line with computer software assurance: high-priority requirements tested with positive, negative and boundary tests and evidence, medium ones tested or covered by assessed supplier testing, low ones verified by inspection, review or supplier evidence with the rationale.
• A readiness check before execution (environment and baseline, trained testers, checklist, pre-execution activities); only testers named on the project with a training reference can execute, and the execution is reviewed by people who executed none of the tests.
• A live traceability matrix from each requirement to its tests and their latest execution, downloadable as CSV, and closure with the outcome Validated, Validated with conditions, or Not validated.

How it fits the platform

A validation project can be opened from the record that requires it, such as a change control, and a CMMS modification that affects an asset's qualified state links to the validation project that requalifies it. The risk assessment module carries a CSV FMEA template for the GAMP 5 functional risk assessment, and a validation project can also be planned and tracked in project management with its baseline and critical path.

Every plan, protocol, execution record, report and deviation is a record with its signatures and audit trail, listed in document management's index with the rest of the quality system's documents. Open validation projects and documents appear in the work queue, and overdue validation activities raise an alert. The inspector follows the trace from requirement to test to executed step to signed report without a paper binder.

Where people decide

The AI drafts the plan, the activities, the requirements and their risk, and every document section; it does not approve, execute or sign. The validation lead assigns owners and dates, signers approve the plan and each protocol before execution, testers record every step themselves, people who ran none of the tests review the execution, and the validation summary report and closure are signed. A recorded outcome is never changed: a correction of an actual result or evidence carries a reason and stays in the audit trail.