Validation document automation that drafts IQ, OQ and PQ protocols and keeps every requirement traced to its tests
Protocols drafted in minutes, every value traced to its source.
See one case, screen by screen ↓Every piece of GMP equipment is qualified before it touches product, and every IQ, OQ and PQ protocol is written from the same pile: the user requirements specification, the supplier's functional design spec, the P&ID, the approved IQ report, the alarm list and the calibration certificates. The validation engineer opens the locked template and copies setpoints, ranges, tolerances, tags and calibration dates across by hand, while the trace matrix lives in a spreadsheet beside the protocol and drifts the moment either one changes.
The risk sits in what nobody had time to cross-check. A design spec that leaves an alarm setpoint "to be set at commissioning" is found on the floor, not at the desk. A requirement asks for 150 rpm while the drive is limited to 140 rpm at full volume. And when a new URS revision arrives under change control, finding the test cases it touches means reading every section again — a missed one becomes a failed execution or an inspection finding.
Estimated split for one OQ protocol on a piece of process equipment, by hand and with the solution — the author's checks and decisions included.
Six specialist agents draft, trace and re-check every protocol; the validation engineer decides and QA signs.
Bioreactor BR-204 — a 500 L stainless-steel bioreactor in Suite B2 at Plant 3, Leiden — needs its OQ protocol, OQ-BR204-001. Its IQ was approved on Sep 18. On the morning of Oct 6 a new URS revision arrives. Here is what happens next, screen by screen, in the working solution.
Lena opens the requirements traceability for OQ-BR204-001. Every user requirement in URS-BR204 runs across to its functional-spec clause, its design and configuration record and the OQ test cases that prove it: 14 requirements, 31 test steps. Nine are traced end to end, one needs a decision, three — clean-in-place, steam-in-place and batch backup — are tested in their own approved protocols, and one is a gap. URS-031 asks for critical alarms within 5 s, but the alarm list has the DO_HI setpoint "to be set at commissioning".
“No source gives the DO_HI setpoint, so test 9.1-04 cannot state its expected result. The sister unit BR-203 sets it at 60 % air saturation.”
URS-022 asks for agitation from 20 to 150 rpm, ±2 rpm. FDS 6.3 on page 15 limits the drive to 140 rpm at the 400 L working volume, because of shaft torque. The matrix marks the row "Specs disagree" and the test runs at the equipment limit until Lena decides: keep 140 rpm, or ask for a URS change. It also shows a design clause with no requirement — antifoam dosing in FDS 5.4.
“URS asks for 150 rpm; the design spec limits the drive to 140 rpm at 400 L. The test runs at the equipment limit until the author decides.”
Dr. Maya Chen has approved URS-BR204 rev 4 under CC-26-142. On Source changes it sits at the top of six revisions received in 14 days, each with what changed and what it touches: URS-021 temperature goes from 30.0–40.0 °C, ±0.5 °C to 28.0–40.0 °C, ±0.3 °C — 3 tests to rewrite. A firmware change on autoclave AC-12, a renamed drain-valve tag on the P&ID and a DO meter's calibration due date are traced the same way.
“Approved documents are never edited in place — a change opens a new version under change control.”
Rev 3 and rev 4 sit side by side: the new cell line ProCHO-7 shifts to 28.0 °C on day 5, and QA tightened control to ±0.3 °C. Test 9.2-02 expects 36.5–37.5 °C where rev 4 needs 36.7–37.3 °C; 9.2-03 accepts ±0.5 °C; 9.2-04 tests 30.0 °C, not the new 28.0 °C low end. 9.2-01, the fill and setpoint step, is not affected. What still holds is listed too: the controller's 25.0–45.0 °C, ±0.2 °C range in FDS 6.2 covers rev 4, and reference thermometer TR-07 at ±0.05 °C is still 6:1 against ±0.3 °C.
The change impact checker marks; it never clears a mark and never edits an approved document.
Lena clicks “Draft the updated section 9.2”. The section writer reads URS-BR204 rev 4 page 4, rewrites test cases 9.2-02, -03 and -04 with the locked template wording kept, checks the instrument accuracy and updates the trace from URS-021 through FDS 6.2 and TT-204-01 to its four tests. Old and new expected results sit side by side: TT-204-01 now reads 36.7–37.3 °C, and steps 2–3 repeat at 28.0 °C and 40.0 °C within ±0.3 °C.
Lena reads the redraft and accepts it. The matrix header moves to URS-BR204 rev 4, the protocol to v0.2, and URS-021 shows “Traced · rev 4” with all four test cases green. The protocol goes to Omar Haddad, the automation engineer, for review, and the step is recorded on the activity trail.
“URS-BR204 rev 4 is now traced. Section 9.2 redrafted — 3 test cases rewritten, sent to Omar Haddad for review as v0.2.”
Lena ticks 19 of the 21 template sections and tells the agents how to write them in plain English — no template editing. The agents read 6 source records, 157 pages indexed by page, draft every ticked section, extract 19 values with their source pages and build the requirement-to-test trace. Draft ready in 52 s. They also suggest section 9.10 Foam control: the design spec lists antifoam pump P-204-05 and foam probe LS-204-07, and the requirements do not.
“Tell the agents how to write it. Plain English. No template editing — locked wording stays as approved.”
All 19 values are listed with the document and page they came from: 17 matched, 1 to check — agitation at 140 rpm — and 1 missing. The High DO alarm has no source, and FDS-BR204 rev B page 12 shows why: its alarm table leaves DO_HI “to be set at commissioning”. Lena can use 60 % from the sister unit and mark it for verification, ask Omar Haddad, or type a value with a reason. Until she decides, export waits.
The value extractor never fills an unreadable or missing value; the section writer leaves it empty and flags it.
Lena takes 60 % air saturation from the BR-203 alarm list, marked for Omar to verify on HMI-204 before test 9.1-04 runs. The protocol is written into the Plant 3 controlled document template — 38 pages with Appendix A, the requirement-to-test trace matrix of 14 requirements and 31 test steps, and Appendix B, every value with its document, page and passage. Blank results tables are ready for execution, and every page carries “DRAFT — NOT FOR EXECUTION” until QA signs.
Lena signs as author at 09:18. Omar Haddad signs at 09:41 with the meaning “Reviewed — test content and commissioning values checked”. Dr. Maya Chen, Head of Quality Assurance, re-enters her password to sign OQ-BR204-001 v0.2 with the meaning “Approved for execution”, and v1.0 is released.
“Each signature records name, date, time and meaning.”
The same protocol, seen by the four people who write, review, approve and own it — what their week looked like, and what it looks like now.
Six specialist agents draft, trace and re-check every protocol; the validation engineer decides and QA signs.
Finds the current, approved records for a piece of equipment — requirements, design spec, IQ report, P&ID, calibration certificates — and indexes every page so values can be cited by document, page and passage.
Pulls setpoints, ranges, tolerances, tags and calibration dates from the sources, including tables and scanned test sheets, with the unit exactly as written and the page and passage.
Drafts each ticked template section from the sources and the author's plain-English instructions, and redrafts a section when a source changes, citing the new page.
Compares every value with every other source that mentions it and with the rules for values: missing, disagreeing, out of range or wrong unit, showing the passage from each source.
Links each requirement to its functional-spec clause, its design record and the test cases that prove it, and builds the requirement-to-test and value-to-source appendices.
When a requirement, design spec, drawing or certificate gets a new revision, compares it line by line with the revision each document was drafted from, marks every linked test case and lists what still holds.
Engineer decides, QA signs. The agents propose; a named person decides.
Ask what a new revision changes, which requirements have no test, or where a value came from. Every answer points to its source page.
What does URS-BR204 rev 4 change?
One requirement changed. URS-021 goes from 30.0–40.0 °C, ±0.5 °C to 28.0–40.0 °C, ±0.3 °C — the new cell line shifts to 28.0 °C on day 5. Three test cases in OQ-BR204-001 must be rewritten: 9.2-02, 9.2-03 and 9.2-04. Test 9.2-01 is not affected. The design spec still covers it, and reference thermometer TR-07 (±0.05 °C) is still accurate enough.
Which requirements have no test yet?
One gap: URS-031 (alarms within 5 s) — test 9.1-04 has no DO_HI setpoint, because the design spec leaves it "to be set at commissioning". The sister unit BR-203 uses 60 % air saturation. Clean-in-place, steam-in-place and backup are tested in their own approved protocols. And one design clause has no requirement: antifoam dosing in FDS 5.4.
Why is BR-204 agitation 140 rpm and not 150?
The requirement asks for 20 to 150 rpm, but the supplier's design spec limits the drive to 140 rpm at the full 400 L to stay within the shaft torque limit. The factory test ran at 140 rpm and measured 140.4 rpm. The protocol tests at the equipment limit, and the value is marked Check so the author confirms it.
Where did the 60 % high DO alarm come from?
The BR-204 design spec leaves DO_HI "to be set at commissioning", so none of the six sources holds the value. The sister unit BR-203 has the same design, and its approved alarm list sets DO_HI at 60 % air saturation with a 60 s delay. The value is marked to verify at execution, and Omar Haddad confirms the commissioned value on HMI-204 before the test runs.
13 screens from the working solution, on its sample data. Pick one to see it large.
Approvers, the rules every value is checked against and what happens when a source changes are settings.
| Setting | Default | Choose from |
|---|---|---|
| Protocol review | Omar Haddad | Any person on the team |
| QA approval | Dr. Maya Chen | Any person on the team |
| Hold export while a value is missing | On | On · Off |
| Prefer the equipment limit when sources disagree | On — the author confirms | On · Off |
| Use superseded revisions | Off — only for comparison | On · Off |
| Approved documents, when a source changes | Open a new version | Open a new version · Note only, no new version |
| Who hears about a change | Author and reviewer | Author and reviewer · Author only · Author, reviewer and QA |
| PDF type for the signed copy | PDF/A-2b | PDF/A-2b · PDF/A-3 (with attachments) |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample equipment and documents · “target” = the design goal, measured in the live solution (by-hand times from an 8-hour working day) · “estimated” = our estimate of where an OQ protocol's days go. Equipment, documents and change controls on this page are sample data. People named on this page are characters in the working solution.
Software that drafts the qualification documents a GMP site writes for every piece of equipment and computerised system — IQ, OQ and PQ protocols, reports and the trace matrix — from the requirements and design records instead of by hand. Validation Document Automation adds six agents that find the current sources, extract every value with its page, draft each section, keep the requirements traceability matrix and mark the tests a new revision touches, for the validation engineer to decide and QA to sign.
The author picks an approved template, ticks the sections that apply and writes instructions in plain English, such as the run setpoint or readings per setpoint. The agents draft each ticked section from the current, approved sources, citing the document and page for every value, and leave a value empty and flagged when no source holds it. On the sample bioreactor OQ, 19 sections were drafted in 52 seconds.
The trace-matrix builder links every requirement to its functional-spec clause, design record and test cases, and reports requirements with no test and design with no requirement. When a new revision arrives, the change impact checker compares it line by line with the revision each document used and marks every linked test case amber until it is rewritten or justified.
The change impact checker shows the old and new wording, marks the test cases the change touches and lists what still holds. The section writer drafts the updated section citing the new page, and the author accepts it, which opens a new version for review. Approved documents are never edited in place.
No. Locked template wording is never changed in a draft, and no value is written without a source page. A value missing from the sources, like an alarm setpoint left to commissioning, is flagged for the author, who can take it from a sister unit marked for verification, ask the reviewer or type it with a reason.
Yes. The agents draft, mark and flag; only the author accepts a draft or clears a flag. The automation engineer signs as reviewer and the Head of QA approves for execution, each signature recording name, date, time and meaning. Drafts carry “DRAFT — NOT FOR EXECUTION” until QA signs.
Yes. Your approved templates are the ones the agents draft into, and approvers, the rules for values, what happens when a source changes, the Word template per site, the PDF type and where source references print are all settings.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your approved templates, a set of source records and a few past protocols — and it goes live once every quality gate has passed. We will walk you through it on one of your own pieces of equipment first.
Any batch-record question answered in seconds, cited to the page and step.
1-min demoManufacturing Batch AnalyticsBatch analysis that took three months now takes hours, with the query behind every answer.
1-min demoDeviation & CAPA ManagementEvery deviation closed inside the 30-day target, with a CAPA aimed at the cause.
1-min demoWe'll run Validation Document Automation on your own URS, design spec and a protocol template.