Validation
Plans, requirements, test scripts and summary reports for a new system, a change, an AI feature or a retirement.
For validation and quality teams
Catalyst drafts. Your experts decide.
Test script, sample login
| Step | Action | Expected result |
|---|
The numbers name the source screens.
An 8-step walkthrough became a drafted test script document, with a screenshot cited at every step, in about 5 minutes.
Timed three times on our test environment, October 2026: 6.2, 4.4 and 5.4 minutes.
What it does
Each piece of work is sized to the risk of what it covers, from infrastructure to custom code, and to the equipment and procedures that have no GAMP category at all.
Plans, requirements, test scripts and summary reports for a new system, a change, an AI feature or a retirement.
Catalyst reads your SOPs and policies and proposes which regulation clauses each control meets. The ones it is unsure of are marked for you to check.
A library of 20 regulations and standards from the US, EU, UK, Japan, Brazil and Canada, 16 of them in the regulator's own words. Switch on the ones that apply, and drafts cite them.
Plans written the way an inspector reads them, and periodic reviews that show what a system in use needs to show.
Lab instruments, manufacturing equipment, and the procedures a system needs, such as administration, backup and recovery, and training.
Walk through what your developers built and get the requirements, test scripts and plan to validate it.
Who decides
Security
Capture starts and stops with you. Deleting a workspace removes everything in it.
Your content does not train any model.
At rest with AES-256 and in transit with TLS 1.2 or later.
SAML or OpenID, SCIM provisioning and multi-factor sign-in.
Every release is checked automatically and approved by name.
Walk through one screen flow, or add one SOP, and read what comes back.
Guided tour. The answers are written in advance. This is not a live AI.
Walk through your system. Catalyst drafts. Your experts decide.
Click through it as you normally would. Catalyst captures each screen as you go, with its address and the time.
Figure 1. A walkthrough of the example Halvern LIMS.
Each step of the draft cites the screen it came from. What Catalyst could not see, it asks you to confirm.
| Step | Action | Expected result |
|---|
Table 1. Test script HLV-TS-014, drafted from Figure 1. The numbers name the source screens.
Your experts review the draft, answer Catalyst's questions and approve the document in your own quality system. Catalyst is a drafting aid, never the system of record.
| Catalyst does | Catalyst does not |
|---|---|
| Draft validation documents from your walkthrough | Approve, sign or release documents |
| Cite the screen behind each statement | Replace your quality system |
| Fill your own Word templates | Make risk decisions for you |
| Ask about anything it could not see | Decide that a system is fit for use |
User requirements specification. An example drafted by Catalyst.
| ID | Requirement |
|---|---|
| URS-021 | The system shall let a user register a new sample from the Sample login screen. |
| URS-022 | The system shall offer the sample type from a fixed list that includes Stability. |
| URS-023 | Entering a study number shall fill in the study name and its pull points. |
| URS-024 | The system shall assign a unique sample ID when a sample is registered. |
| URS-025 | The system shall record who registered each sample, and when. |
The screen, the address, the time. Each source is a screen captured during the walkthrough.
Gaps come back as questions. What Catalyst could not see, it proposes and marks for you to confirm.
A document, not a web page. The draft reads and exports like the controlled document it will become.
Pick the work in front of you. Catalyst asks for what that validation needs, step by step.
| Path | Use it for |
|---|---|
| Initial validation | A new system, from the system assessment to the summary report. |
| AI validation | AI added to a system. It covers the AI part only. |
| Change validation | An upgrade, a configuration change, a new function or a move. Drafts follow your earlier documents' format. |
| Procedures | The procedures a system needs: administration, backup and recovery, training. |
| Equipment | Lab instruments and manufacturing equipment, sized by kind and impact. |
| Periodic review | A regular review of a system in use. |
| Data migration | GxP data moved from one system to another, mapped field by field and checked. |
| Retirement | Planning the retirement of a validated system and its records. |
| Dashboards and reports | A dashboard or report, sized by how people use it. |
The GAMP category sizes each path. A Category 3 system gets a lighter set of documents than Category 4 or 5.
Catalyst proposes answers and marks them for you to confirm. It never concludes that a system is fit for use or remains in a validated state.
Drafts come back in your format, with your headings and your tables.
Figure 1. Your template goes in. The draft comes back in the same layout, with the signature block left blank.
Add your Word templates to the Library, several at once.
Catalyst writes into your sections, numbering and tables, in your house style.
Signature and approval fields stay blank. Your team completes them in your own system.
Export to Word or PDF, then file the document in your quality system.
How Pi Health protects Catalyst and the content your team puts into it.
| Standard | Status | Scope |
|---|---|---|
| SOC 2 Type II | In progress | Independent audit of security controls |
| ISO/IEC 27001 | In progress | Information security management |
| ISO/IEC 42001 | In progress | AI management |
| GxP intended use | Statement | A drafting tool only |
| Area | Controls |
|---|---|
| Data protection |
|
| Access |
|
| Infrastructure |
|
| Change management |
|
| Monitoring |
|
| Testing |
|
A tick marks a control in place, and a half-filled circle one in progress.
| Company | Purpose | Location |
|---|---|---|
| Amazon Web Services | Cloud hosting, storage, email and AI model hosting | United States. AI backup in the EU. |
| Stripe | Billing. No document content. | United States |
| Document | Access |
|---|---|
| SOC 2 Type II report | Enterprise, when issued |
Open the full trust centerRequest documents
Two short films about Catalyst.
Film 1. Validating software your own team built. Narrated, with captions. 0:43.
Film 2. From a walkthrough to a draft. No sound; the words are on screen. 0:22.
Articles on validation, software assurance and AI, from the Pi Health team.
Last week Node.js patched a flaw in its Brotli decoder (CVE-2026-111497) that can let a malformed compressed stream corrupt memory and, in the worst case, run an attacker's code. Brotli is easy to overlook because it appears inside ordinary files, including web fonts and, in a recently published extension, PDFs, so software that reads an uploaded document may reach a Brotli decoder even when the file does not look compressed.
The lesson I take from it is to assume that a parser handling untrusted files may eventually be compromised, and to decide in advance what it could reach. If untrusted files are handled in an environment that is isolated from credentials and from the network, an attacker who gets in has far less to steal and far less ability to send it anywhere.
Generative AI adds a second layer, because the same document is also text that a model reads. The OWASP Top 10 for LLM Applications (2025) covers what hidden instructions can attempt, such as prompt injection and system prompt leakage, and the answer follows the same idea: give the model only the access its task needs, and keep a person in the loop for actions that matter.
At Pi Health, this is how we think about our applications: protect the file, limit the model, and keep a person in charge of what matters.
There are many ways to build with an LLM, and the diagram shows four, from the model alone, through an augmented model and a fixed workflow, to an agent that chooses its own steps. Whichever design is chosen, the same principle holds: a qualified person reviews the output, and the scrutiny scales with the risk. That risk has two parts. One is the intended use, meaning what happens if the output is wrong. The other is how much of the work the design keeps out of the reviewer's sight. That depends on what the reviewer can see, not on how the model works inside, and it grows as the model is given more say over its own steps. With the model alone, the reviewer sees the whole exchange. With an agent, the reviewer sees the result and only those steps the system records, so review of the result is not enough on its own and has to be backed by evidence such as testing across many runs and a record of every step.
This is close to how FDA's computer software assurance guidance scales assurance to risk, treating software that acts with "limited or no additional human awareness or review" as higher risk. The EU's draft Annex 22 goes further for generative AI: it should not be used in critical GMP applications, and in non-critical uses, qualified personnel remain responsible for confirming that the output suits its intended use.
Sources: FDA, Computer Software Assurance guidance, reissued February 2026. European Commission, draft GMP Annex 22, 2025 (not yet adopted). Anthropic, "Building effective agents", 2024.
FDA's draft guidance on AI in drug development (January 2025) sets out a seven-step framework for establishing that an AI model is credible for its context of use. Its scope is narrower than many assume. It states that it does not address AI "used for operational efficiencies (e.g., internal workflows, resource allocation, drafting/writing a regulatory submission)" that do not affect patient safety, drug quality, or the reliability of study results.
Out of scope for that guidance is not the same as unregulated. A tool that drafts validation documents still sits under the quality system that governs those documents. A qualified person reviews and approves them, and the approved record lives in the company's validated system.
Where the framework does apply, risk combines two factors: model influence, meaning how much of the evidence comes from the AI, and decision consequence. Teams control the first. Human review and approval lower model influence. The question being answered sets the consequence.
This is how we built Catalyst. It drafts validation documents from a recording of the system, cites the source screen for each statement, and leaves review and approval with the people accountable for them.
The guidance is still a draft. FDA has not announced a final version.
What FDA's guidance asks for, and what the record should hold.
Computer Software Assurance (CSA) is FDA guidance on building confidence in software used in medical device production or in the quality management system. It asks for effort in proportion to risk, rather than the same paperwork for every feature.1
FDA issued it as final guidance on 24 September 2025. A revised edition followed on 3 February 2026, now titled Computer Software Assurance for Production and Quality Management System Software, to match the amended device quality regulation in 21 CFR Part 820, which took effect on 2 February 2026.1, 3 Like all FDA guidance, it is a set of nonbinding recommendations.
It replaces Section 6 of FDA's General Principles of Software Validation. The rest of that guidance still applies.1, 2
The guidance also covers changes to software and further considerations for assurance.
| Generally high process risk | Generally not high process risk |
|---|---|
| Maintains process settings, such as temperature or pressure, that are essential to device safety | Collects and records process data for monitoring and review |
| Measures, inspects or decides product acceptability with little or no human review | Routes corrective and preventive actions, logs complaints, or manages change control or procedures |
| Produces instructions for use or labeling needed for safe operation | Manages data, automates an existing calculation, or raises alerts |
Table 1. Paraphrased from Section V.A of the guidance.1
One worked example is a spreadsheet that graphs nonconformance data for monitoring. Other controls stop nonconforming product from being released, so the spreadsheet is not high process risk, and rapid exploratory testing is enough.1
| Item | What to write |
|---|---|
| Intended use | What the feature is for |
| Risk | The result of the risk-based analysis |
| Testing | A description of the testing done |
| Issues | Issues found, and how each was resolved |
| Conclusion | A statement that the software is acceptable for its intended use |
| Who and when | Who did the testing, and the date |
| Approval | Review and approval, where appropriate |
Table 2. From Section V.A(6), "Establishing the Appropriate Record".1
FDA also recommends relying on records the software already keeps, such as system logs and audit trails, rather than paper, screenshots or copies of results the software already holds.1
The terms that apply when you use Catalyst.
| Document | Version | Date |
|---|---|---|
| Terms of Service | 1 | 16 Oct 2026 |
| Acceptable Use Policy | 1 | 16 Oct 2026 |
| Service Level Agreement | 1 | 16 Oct 2026 |
Each page keeps its earlier versions, with what changed and when.
If your organization has a signed agreement with Pi Health for Catalyst, that agreement governs where it differs from these documents.
How Pi Health handles personal information: pihealth.ai/privacy-policy.
Write to a person at Pi Health.
hello@askcatalyst.comWrite an emailPi Health uses your details to reply to you. See pihealth.ai/privacy-policy.
This preview fills a fixed template with your answers. Catalyst itself drafts from the systems you record and the documents you add.
Click Sample login to start.
What the system is for, its GxP impact and its category, in one document. Catalyst recommends the category, you confirm.
Scripted preview. The answers are written in advance.
Halvern LIMS 4.2
Recommended category: Category 4. Sample types, conditions and study pull points are set up for Halvern in configuration, and no custom code was seen.
This assessment records what Halvern LIMS is for, its GxP impact and its GAMP category, so the validation effort matches its risk.
Halvern LIMS registers stability samples for the QC laboratory. Each sample records its study, storage condition and pull points.
Used by QC analysts in the stability program. Its records fall under GMP and 21 CFR Part 11.
In scope: sample login and sample history. Out of scope: receipt, aliquots and disposal.◇ to confirm
A wrong condition or pull point would misdirect stability testing, so a failure could affect product quality and data integrity.
The system keeps an electronic record of each sample, and a history of who did what, and when. No electronic signature was seen.◇ to confirm
| Question | Finding | Points to | Evidence |
|---|---|---|---|
| Is it used as supplied, with parameters only? | No. Sample types and conditions are set up for Halvern. | Not Category 3 | Register sample |
| Is it configured to the business process? | Yes. A study fills in its own pull points. | Category 4 | Register sample |
| Is code written for Halvern inside it? | None seen. | Not Category 5◇ to confirm | The walkthrough |
None seen in the walkthrough.◇ to confirm
No supplier documents were added, so nothing is leveraged yet.◇ to confirm
| Deliverable | Depth for this system |
|---|---|
| User requirements | Full, with acceptance criteria |
| Configuration specification | Required, traced to requirements |
| Testing | Configured workflows, scripted for high-risk functions |
Observed in the system
Halvern LIMS 4.2, sample login
Verifies that a QC analyst can register a stability sample, and that the system records who registered it, and when.
Each step's result matches its expected result.
Objective: Verify that a QC analyst can register a stability sample, and that its history records the registration.
| Step | Action | Expected result |
|---|---|---|
| 1 | Open Sample login. | The sample list shows. |
| 2 | Select New sample. | The Register sample form opens. |
| 3 | Select Stability, enter STB‑2026‑031 and select 25 °C / 60% RH. | The study name and the pull points fill in. |
| 4 | Select Register. | Sample S-26-04417 registered shows, with Registered by M. Osei. |
| 5 | Open History. | Registered, ID assigned and Pull schedule set show, each with its user and time. |
A failure is recorded with the step where it occurred and the observed result.
Observed in the system
Validating software your own team built. Narrated, with captions. 0:43.