IQ, OQ and PQ protocols drafted from your templates and source records, every value traced to its page
Validation protocols and reports drafted in minutes, every value traced to its source page.
See one case, screen by screen ↓Every value an OQ protocol needs is already written down somewhere: the setpoint range in the URS, the alarm table in the supplier's functional design spec, the relief valve set pressure on the P&ID, the reference thermometer's accuracy and due date on a calibration certificate. The validation engineer's job is to find the current revision of each, copy the value across, and write the test around it — section by section.
That is where the days go. A protocol is re-keyed by hand from a stack of PDFs, the trace matrix is built at the end in a spreadsheet, and a value that was never set — an alarm left “to be set at commissioning” — or two sources that disagree are found by the reviewer, or on the floor during execution. One missed value is a deviation waiting to happen.
Estimated split for one OQ protocol, in hours — about four 8-hour days by hand, and under an hour with the solution.
Six specialist agents find the sources, pull the values, draft and check every section; the author decides and QA signs.
Bioreactor BR-204 in Suite B2 at Plant 3 — Leiden has an approved IQ and is ready for its operational qualification. Here is the OQ protocol written, checked and signed in under an hour, screen by screen, in the working solution.
Lena opens the solution: 9 documents in progress across two plants, 3 values to check, 2 waiting for approval with Dr. Maya Chen. Below, the source records that changed — the supplier sent FDS-BR204 rev B on Oct 5, replacing rev A, and it is already linked to the BR-204 OQ protocol.
“CAL-26-1184 — Portable DO meter DM-11 is due Nov 20 · used by 2 open protocols.”
She picks Bioreactor BR-204 — 500 L, IQ approved Sep 18, ready for OQ. BR-205 is greyed out: its IQ is still in execution. The OQ protocol — process equipment template, v4.2 with 21 sections, is marked best fit for a bioreactor. Templates are approved and locked; she only chooses.
6 records found for BR-204 — URS, design spec, IQ report, P&ID, calibration certificates, FAT report — current, approved revisions only.
The source finder maps the 21 template sections and links the six records — 157 pages, indexed by page. 19 sections are ticked. Clean-in-place is left out because skid CIP-B2 has its own protocol. And it suggests a section: the design spec lists an antifoam pump.
“Section 9.10 Foam control looks relevant. The design spec lists antifoam pump P-204-05 and foam probe LS-204-07. Tick it to include the test.”
Lena ticks Foam control and writes how she wants it: use 37 °C as the run setpoint, short commands, three readings at each setpoint, the requirement number on every test. The draft is ready in 52 s — 20 sections, 20 values, a trace of 14 requirements to 31 test steps. Test 9.2 compares TT-204-01 with reference thermometer TR-07 at 30.0, 37.0 and 40.0 °C, within ±0.5 °C.
“Draft ready in 52 s. 20 sections · 20 values. Check them next.”
18 values matched, 1 to check, 1 missing. The high DO alarm has no value: the design spec’s alarm table says DO_HI is “To be set at commissioning”. The checker shows the closest match — the approved alarm list of sister unit BR-203, same design: 60 % air saturation, 60 s delay. Export waits until Lena decides.
“1 missing — export waits for it.”
Lena takes the 60 % value and marks it for verification: Omar Haddad will confirm the commissioned value on HMI-204 before the test runs. Next, agitation: URS-022 asks for 20 to 150 rpm, but the supplier’s design spec limits the drive to 140 rpm at 400 L to stay within the shaft torque limit. The equipment limit was used, and the value is marked Check for her to confirm.
“URS-022 says 150 rpm; the design spec limits the drive to 140 rpm at 400 L. Used the equipment limit.”
OQ-BR204-001_v0.1.docx: 38 pages in the Plant 3 controlled document template, watermarked DRAFT, with blank results tables for execution — Actual, Pass/Fail, initials and date. The DO_HI line carries a footnote telling the executor to verify the commissioned value on HMI-204 before running the step.
Appendix A is the requirement-to-test trace matrix: URS-021, temperature ±0.5 °C, is proved by tests 9.2-01 to 9.2-04; URS-031, alarms within 5 s, by 9.1-01 to 9.1-07. Appendix B lists every value with its document, page and passage. All 14 requirements are covered.
Lena signs as author when she sends it. Omar reviews the test content and the commissioning values, then signs: he re-enters his password, and the meaning — “Reviewed — test content and commissioning values checked” — is recorded with his name, date and time.
Dr. Maya Chen signs as QA approver with the meaning “Approved for execution”. OQ-BR204-001 v1.0 is released for execution, the DRAFT watermark comes off, and the signed copy is stored as PDF/A with the full value-to-source trace. Created at 09:12, approved at 10:05.
The same BR-204 OQ protocol, seen by the four people who carry it — what their week looked like, and what it looks like now.
Six specialist agents find the sources, pull the values, draft and check every section; the author decides and QA signs.
Finds the current, approved records for a piece of equipment — requirements, design spec, IQ report, P&ID, calibration certificates — skips superseded revisions, and indexes each page so values can be cited by document, page and passage.
Pulls setpoints, ranges, tolerances, tags and calibration dates from the sources — tables and scanned test sheets included — into values with their page and passage.
Drafts each ticked template section from the sources, following the author’s plain-English instructions, with a source page on every value.
Compares every value across the sources and against the rules for values, and raises a flag when one is missing, two sources disagree, it is outside the required range or the unit does not match.
Links each requirement to the test steps that prove it and builds the requirement-to-test and value-to-source appendices.
Writes the draft into the controlled Word template for the site, numbers sections and tables, adds the signature block and both trace appendices, and renders PDF/A for the signed copy.
Author validates, QA signs. The agents propose; a named person decides.
Authors, reviewers and QA can ask in plain words — or tell it what to change. Every answer points to the page it came from.
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. 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.
What happened with F₀ on the AC-12 report?
The cycle printout for run 3 is faded on page 41, so F₀ could not be read. The qualified data logger recorded the same run: the lowest F₀ in the load is 18.6 min against a limit of ≥ 15. The author can take that value with one click on the Validate stage, and the reason goes into the audit trail.
Add a rule: read the sister unit’s alarm list before flagging
Done. New rule in Settings → Rules for values: when the design spec leaves an alarm setpoint “to be set at commissioning”, read the approved alarm list of a sister unit of the same design and propose its value, marked for verification. In the last 8 weeks this would have pre-filled 6 of the 11 “not found” flags. The author still decides on every one.
13 screens from the working solution, on its sample data. Pick one to see it large.
Who reviews and signs, how values are treated and how the document comes out are settings, not a project.
| Setting | Default | Choose from |
|---|---|---|
| Protocol review | Omar Haddad | Any named person on the team |
| QA approval and report approval | Dr. Maya Chen | Any named person on the team |
| Every value needs a source page | On | On · Off |
| 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 — comparison only | On · Off |
| PDF type for the signed copy | PDF/A-2b | PDF/A-2b · PDF/A-3 (with attachments) |
| Where source references are printed | Appendix B table | Appendix B table · Margin and Appendix B · Footnotes |
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 plant data · “target” = the design goal, measured in the live solution (by-hand times from an 8-hour working day) · “estimated” = our estimate. People, companies and products named on this page are fictional — characters and sample data in the working solution.
Drafting validation protocols and reports — IQ, OQ and PQ protocols, OQ and PQ reports, summary reports and the validation master plan — from your approved templates and the equipment’s own records, instead of re-keying values by hand. The Validation Document Generator uses six agents to find the sources, pull the values, draft and check every section, build the trace matrix and write the Word and PDF files. The author decides and QA signs.
Every value carries its document, page and passage, and the consistency checker compares it with every other source that mentions it and with your rules for values. Missing values, sources that disagree, values outside the required range and units that do not match are flagged, and only an author can clear a flag.
It is left empty and flagged — never guessed — and export waits until the author decides. Where it can, the solution proposes the closest approved match, such as a sister unit’s alarm list, and marks the value for verification at execution. The author can also type a value with a reason, or ask a colleague.
Yes. The trace-matrix builder links each requirement in the URS to the test steps that prove it and reports any requirement with no test as a gap. The matrix is exported as Appendix A, and a value-to-source trace as Appendix B.
Yes. Your approved templates — process equipment, computerized system and utility protocols, reports and the master plan — are loaded and locked. Authors tick sections and write instructions in plain English; the locked wording changes only through change control with the template owner.
Yes. Agents draft and flag; people decide, review and sign. The author signs when sending, the reviewer and the QA approver sign in turn with their password and the meaning of the signature, and drafts carry the DRAFT watermark until QA signs.
The solution finds the documents that use that record, re-checks their values and tells the author which values changed. Superseded revisions are kept for comparison only, never used as a source.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your approved templates, rules for values and a sample of source records — and it goes live once every quality gate has passed. We will walk you through it on one of your own protocols first.
Any batch-record question answered in seconds, cited to the exact page and step.
1-min filmAsk the PlantBatch analysis that took three months now takes hours, with the query behind every answer.
1-min filmDeviation & CAPAEvery deviation reaches a ranked, evidence-backed root cause in days, closed inside the 30-day target.
1-min filmWe’ll draft one of your protocols from your own templates and source records.