How to Write Expected vs Actual Results in an OQ Protocol

Write the expected result before the protocol is approved, as a quantitative statement with a value, units, a tolerance, and a named source, one observable outcome per test step. Record the actual result at the time of performance, as the observed reading itself, not a bare Pass, entered by the person who performed the step, dated, with raw data attached where an instrument produced it. The pass or fail verdict is then a comparison anyone can repeat: does the recorded value sit inside the pre-approved limit. When it does not, the actual result is recorded exactly as observed and routed to a deviation, which EU GMP Annex 15 requires explicitly: results which fail to meet the pre-defined acceptance criteria should be recorded as a deviation and be fully investigated. The one thing that never happens is the expected result bending to meet the data.

The two columns look like neighbors on the page, but they are different documents written at different times, often by different people, under different rules. Auditors often see OQ execution record problems when that boundary blurs: expected results vague enough that any actual result passes, actual results that record a verdict instead of an observation, or a failing value quietly absorbed by an edited criterion. This article covers how to write each column, what the record must capture at execution time, and the failure path when actual does not meet expected.

Two columns, two moments in time

The expected result is an authoring artifact. It is written while the protocol is a draft, reviewed by people who understand the process, and locked by the approval signatures. From that moment it is part of an approved document, and Annex 15 clause 2.7 is blunt about what changing it takes: any significant change to the approved protocol during execution, acceptance criteria included, should be documented as a deviation and be scientifically justified. There is no informal path to a different number.

The actual result is an execution record. It does not exist until someone runs the step, and the moment it exists it is evidence, subject to data integrity expectations rather than authoring judgment. FDA's data integrity guidance for drug CGMP draws the line precisely: when generated to satisfy a CGMP requirement, data become a record, and you must document or save them at the time of performance. The same guidance is equally direct about the shortcut everyone has seen: it is not acceptable to record data on pieces of paper that will be discarded after the data are transcribed to a permanent record.

The whole evidentiary value of an OQ lives in the gap between those two moments. Expected was fixed before anyone knew the outcome. Actual was captured when the outcome happened. A reviewer who can verify both timestamps can trust the comparison. This is also why criteria written or completed after results are known are a serious documentation integrity failure, a failure mode covered in depth in our guide to acceptance criteria that survive audits.

How to write the expected result column

A usable expected result has a fixed anatomy: the attribute being checked, a comparator, a value with units, a tolerance, the condition under which it applies, and the source that justifies it. Not every element is a separate clause, but every element is present or deliberately absent.

Weak: "Seal jaw reaches operating temperature." Strong: "With the setpoint at 150 degrees Celsius, the recorded jaw temperature shall remain within plus or minus 2 degrees Celsius throughout three consecutive seal cycles, per process specification PS-041 Rev C section 5.2." The strong version names the condition, the reading, the band, and the document that put the number there, which is what lets the criterion trace to a requirement instead of floating free.

Three rules keep the column honest.

One observable per step. An expected result that bundles temperature hold, cycle count, alarm behavior, and seal appearance into one sentence produces a verdict nobody can interpret when one of the four misses. Split them. Each step gets one expected outcome, one verdict, and one line in the traceability matrix. The general anatomy of an OQ protocol shows where these steps sit among the protocol's other sections.

Write what the instrument can actually show. The expected result must be checkable against a reading the verification method produces. If the logger resolves to 0.1 degrees, a plus or minus 2 degree band is verifiable. "Uniform seal with no irregularities" is not, because no instrument or count produces the word uniform. Attribute checks are phrased as counts: 10 of 10 samples pass dye penetration with zero channel defects.

The expected result dictates the recording field next to it. If the criterion is a band, the form provides a field for the measured value with units pre-printed, not a checkbox. If the criterion is a count, the form asks for the count and the sample identifiers. If the criterion needs a trace, the form has an attachment reference line. Designing the data capture at authoring time is what makes contemporaneous recording possible at execution time. Where the challenge points themselves come from, and why they bracket the claimed operating window rather than the machine's limits, is covered in how to set OQ machine parameters.

The per-step expected result is also distinct from the protocol's acceptance criteria summary table. The summary states, per test category, what passing means and why, in one auditable place. The step-level expected result is the specific number this step is judged against. They must agree, but they do different jobs, and collapsing them in either direction loses something a reviewer needs.

How to record the actual result

A common weakness in executed OQ protocols is an actual result column full of the word Pass. A verdict is not an observation. "Pass" proves someone ticked a box; "150.8, 151.1, 150.6 degrees Celsius across three cycles" proves a measurement happened and lets a second person reach the same verdict independently. Record the reading, the count, the elapsed time, whatever the expected result was written against, and let pass or fail be the conclusion drawn from it. FDA's data integrity guidance compresses the expectation into ALCOA: attributable, legible, contemporaneously recorded, original or a true copy, and accurate.

Contemporaneous means during, not after. The value goes onto the controlled record at the time of performance. Not into a notebook for later transcription, not onto a sticky note, not into memory until the run finishes. A common compliant electronic design, the one FDA's guidance itself offers as an example, is a system that automatically saves after each entry, combined with a procedure requiring data to be entered when generated: the electronic equivalent of indelible contemporaneous recording on paper.

Attributable means signed and dated per step. The person who performed the test records the result and signs or initials it with the date. Where the program requires a witness or a reviewer, that is a second identified person, not a second signature from the first. Executed records then get a documented review, the same discipline auditors check first in any validation package.

Original means the raw data comes along. Where the instrument produces a trace, a printout, or a data file, the actual result references and attaches it. A transcribed mean with the trace discarded is a transcription, not an original record.

On paper, the printed protocol is a controlled form. FDA's data integrity guidance expects blank forms to be controlled, issued as numbered sets where appropriate, and reconciled on completion, with incomplete or erroneous pages kept as part of the permanent record along with written justification for their replacement. Corrections follow the site's good documentation practice procedure, classically a single line through the error, the correct entry beside it, initials, date, and reason, with the original still legible underneath.

Electronically, Part 11 does the same work. E-signatures with the appropriate controls stand in for handwritten ones, and the audit trail captures every change to a recorded value with who, when, and what. The controls that make an electronic execution record defensible are the subject of our Part 11 CSV protocol guide.

No blanks. Controlled-record practice is that every result field either holds an observed value or an explicit N/A with a recorded rationale for why the step did not apply. A blank field is an incomplete record, and a reviewer cannot tell an intentionally skipped step from a forgotten one.

When actual does not meet expected

Record it exactly as observed, and open the deviation your local procedure requires. Annex 15 clause 2.8 leaves no discretionary space about the classification: results which fail to meet the pre-defined acceptance criteria should be recorded as a deviation and be fully investigated according to local procedures, with the implications for the validation discussed in the report.

The investigation classifies the deviation, finds the cause, assesses impact on the results already collected, and decides what re-testing is justified. That sequence is what separates a defensible deviation from the practice FDA's data integrity guidance calls testing into compliance, which it states plainly is not consistent with CGMP: re-running the step until a passing value appears and reporting only that one. Any repeat testing follows the documented investigation and the site's deviation procedure, with the original failing result and the retest both in the record.

The mirror-image failure is editing the expected result to fit. Clause 2.7 requires any significant change to the approved protocol during execution, acceptance criteria included, to be documented as a deviation and scientifically justified, and clause 2.9 asks the report to summarise the results obtained against the acceptance criteria, with any subsequent changes to those criteria scientifically justified. A criterion that moved after the data existed, without that trail, reads as retrofitting no matter how sound the engineering argument was, and it contaminates every other result in the protocol. If the limit really was wrong, the deviation record is where that argument lives, in the open.

A failing result does not automatically halt the whole qualification. Annex 15 clause 2.10 allows a documented conditional release to the next stage where the open deviation is assessed as having no significant impact on the activity ahead. The condition is the documented assessment, not optimism.

A worked example in real test-step shape

A rotary liquid filler, OQ speed challenge, fill volume at the high edge of the claimed range.

The step as written and approved. Test item: fill volume accuracy at maximum claimed line speed. Setup: 120 bottles per minute, nominal fill setpoint 100.0 mL. Expected result: the mean fill volume of 20 consecutive bottles shall be 100.0 mL plus or minus 1.5 mL, and no individual bottle shall fall outside 100.0 mL plus or minus 3.0 mL, volumes determined gravimetrically per SOP-QC-012, using tared bottles and the product's specific gravity of 1.010 at 20 degrees Celsius to convert net weight to volume, per process specification PS-058 Rev B section 4.3. Data to record: tare and gross weight of each of the 20 bottles, the calculated net volume per bottle, mean, minimum, maximum, balance identifier and calibration due date, data sheet attachment, performer initials and date.

The actual result as recorded, passing. Twenty individual values on the data sheet. Mean 100.4 mL, minimum 99.1 mL, maximum 101.8 mL, 20 of 20 bottles within individual limits. Balance BAL-007, calibration due date recorded. Performer initials, date, verdict Pass. A second reviewer can take the data sheet and reach the same verdict without asking anyone anything. That is the standard.

The counterpart step failing. The protocol's separate low-speed challenge, the same criteria run at 40 bottles per minute, turns up one bottle at 96.7 mL, outside the individual limit. The record shows exactly that: 19 of 20 within limits, minimum 96.7 mL, verdict Fail, deviation DEV-051 opened. The investigation finds foaming at slow fill speed on the first bottle after an idle pause, a real process behavior the development data had not exposed. Impact assessment covers the passing runs already executed. The corrective action and the justified retest, with both the failing and passing data sets attached, live in the deviation. The final report discusses it. Nothing was reworded, and the qualification is stronger for the finding, not weaker.

The compact version: expected results are quantitative, sourced, and frozen at approval; actual results are observed values, captured at the time of performance, attributable and complete; and a miss between them is a deviation to investigate, never a sentence to rewrite. Programs that hold those three lines produce execution records that review cleanly years after everyone involved has moved on, which is the entire point of writing them down.

Valiqa generates OQ protocols with the expected result written into every step as a quantitative specification with units, tolerances, and a per-step rationale, and its guided execution walks each step with that specification in view, capturing the pass or fail verdict with an optional measured value, requiring a rationale for any N/A, opening a deviation with an impact assessment when a step fails, and signing every entry into a hash-chained audit trail, so the expected column and the actual column stay the two independent records an auditor needs them to be.

---

Valiqa is an AI-powered validation lifecycle platform for regulated manufacturing. Learn more at valiqa.io