Every record from the plan to the summary report.
Each step of the validation is an identifiable, versioned record with an audit trail and electronic signatures. The steps below are the order you work in.
-
Plan
Start from a Validation Plan template that already describes the risk-based assurance strategy. Edit it in Markdown with a live preview, then submit it for review and QA approval.
Help: The validation lifecycle -
Assess the system
Four GxP impact questions and the GAMP category give the system risk (High, Medium or Low) and the deliverables it calls for, shown as you answer.
Help: System risk assessment -
Specify
Write URS, FS, DS and IS requirements, trace them to each other, tag them, import them from Markdown or copy them from your library. Risk-assess each one into Tier 1, 2 or 3.
Help: Requirements -
Plan the tests
Automated (pytest node IDs), scripted manual (action => expected result) or unscripted (a session charter). Create automated test cases in bulk from a pytest-gxp report.
Help: Test cases -
Execute
Record each step's actual result and pass or fail, attach evidence (hashed with SHA-256) or capture the screen, and sign. Executions are write-once and need an approved protocol.
Help: Executions -
Run automated suites
Build one Docker image per commit and run it in each environment over SSH. Review the log and evidence, then sign to record one execution per test.
Help: Automated runs -
Resolve deviations
Raise a deviation from a failed step, pre-filled. Record root cause, impact and CAPA. QA closes it with a signature, and never the person who raised it.
Help: Deviations -
Report
The traceability matrix is built live and lists every gap with a link to the record to fix. The summary report can be signed only when there are none.
Help: RTM gap codes
For the whole organization
- Your own workspace
- Each organization gets its own subdomain. The database enforces that one organization can never read another’s records.
- Single sign-on
- Connect Entra ID, Okta, Google Workspace or any OIDC or SAML provider, and enforce it so nobody signs in with a password.
- Roles that match the work
- Author, Reviewer, Approver (QA) and Tester, assigned per system. Authors can’t approve their own documents.
- AI assistants over MCP
- Assistants connect with OAuth, read your validation and edit drafts. Signing and approval stay with people.
- Reusable requirements
- Keep a versioned requirement library. Copies link to the exact library version they came from.
- Print and export
- Documents print or save as PDF; the RTM also exports to CSV.