What the MDL Is — and What It Is Not

The Master Deviation Ledger (MDL-SYS-001) is the project-wide register of every departure from an expected test result across all validation phases — FAT, SAT, IQ, OQ, and PQ. One ledger, one project, all phases. It opens when FAT begins and closes when the Validation Summary Report is approved.

The MDL is not a fault log, a bug tracker, or an informal punch list. It is a controlled GMP document. Every entry represents a formally classified deviation with a traceable record of its root cause, resolution, re-test result, and QA closure. When a regulatory inspector reviews your validation package, the VSR references the MDL — and any deviation that appears in the VSR must have a complete, consistent record in the MDL behind it.

This distinction matters because engineers unfamiliar with GMP sometimes maintain an informal "issues list" alongside the MDL, or delay entering deviations until after the test session. Both practices are data integrity violations. The MDL entry must be created at the time the deviation is observed — not retrospectively.

Golden Rule

The MDL entry must be created before any corrective action is attempted and before any other test case on the affected function is executed. An undocumented fix — however well-intentioned — followed by a passing re-test produces a passing test record with no corresponding deviation. That is a data integrity gap that will be found.

When It Opens, When It Closes

The MDL is governed by VP-SYS-001 and opens at the start of FAT execution. It remains active and must be current throughout every subsequent test phase.

OPENS First day of FAT execution — before any test case is run
ACTIVE FAT → SAT → IQ → OQ → PQ — all deviations from all phases in one ledger
CLOSES When the Validation Summary Report (VSR-SYS-001) is approved — all entries must be closed

A single MDL covers the full validation project — not one per phase. This is intentional: it gives you and the inspector a single document showing the full deviation history, the resolution of each item, and confirmation that nothing was left open at release. A separate deviation log per phase creates a fragmented picture and makes the VSR reconciliation harder to perform and harder to audit.

MDL-SYS-001 — ONE LEDGER, ALL PHASES, FULL LIFECYCLE DOCUMENT MDL-SYS-001 SINGLE SOURCE OF TRUTH FAT SAT IQ OQ PQ QA Review CAPA (Cat A) VSR Section 4 Phase Gates EVERY DEVIATION FROM EVERY PHASE FEEDS INTO ONE LEDGER. VSR SECTION 4 IS GENERATED DIRECTLY FROM IT.
// MDL-SYS-001 — ONE LEDGER FOR ALL PHASES. INPUTS: DEVIATIONS FROM FAT/SAT/IQ/OQ/PQ. OUTPUTS: QA REVIEW, CAPA TRIGGER, VSR SECTION 4, PHASE GATE STATUS.

Every Field in the Deviation Log — Explained

The MDL-SYS-001 Deviation Log sheet has 16 columns. Each one serves a specific purpose in the regulatory evidence chain. Here is what each field requires and why:

MDL Ref.
Sequential reference number — MDL-001, MDL-002, etc. Never reuse or delete a number. This reference appears in the protocol execution record, the CAPA, and the VSR deviation summary table. The chain must be complete.
Phase
FAT / SAT / IQ / OQ / PQ. Identifies which test phase the deviation was raised in. One MDL covers all phases — this column is how you filter by phase at gate reviews.
Protocol Ref.
The document ID of the approved protocol containing the test case — e.g. FAT-SYS-001, OQ-SYS-001. Must reference an approved, controlled document. An unapproved protocol cannot generate a valid deviation record.
Test Case / IQ Item
The specific test case ID or IQ checklist item number — e.g. TC-OQ-047, IQ-HW-012. The inspector will cross-reference this directly to the protocol execution record to verify the deviation matches the executed test step.
Category A / B
Category A (Critical / Blocking) or Category B (Minor / Non-blocking). Joint decision by Validation Lead and QA. This field drives the entire response — Category A halts testing on the affected function; Category B is carried forward with QA acceptance.
Deviation Description
Factual description of what was observed. What happened — not why. "Audit trail entry not created when setpoint changed from 1.2 to 1.4 µS/cm by Operator user account." Root cause belongs in the Root Cause field, not here.
Expected Result
The pre-approved acceptance criterion from the protocol — copied verbatim. This field proves that the test had a defined pass/fail criterion before it was executed. If this is blank, the test lacked acceptance criteria — that is itself a finding.
Actual Result
Exactly what the system produced. Objective and specific — measurements, error messages, screenshots described in text. Not "system failed" — "Historian showed no new record for tag PWS_QAL_Conductivity_PV for 23 minutes following setpoint change at 14:32."
Root Cause
Confirmed root cause after investigation. For Category A: requires documented 5-Why or equivalent analysis. For Category B: brief but specific. "Software bug" is not acceptable — "PLC logic error in DB10.DBX4.2 audit trail trigger condition — bit not set on analogue setpoint write" is.
Corrective Action
What was done to fix the specific failure — code correction, configuration change, document update, procedure revision. Must be specific enough that QA can verify it was implemented. "Fixed the code" is not acceptable.
Resolution Date
Date the corrective action was implemented and verified. Not the date it was planned — the date it was done and confirmed.
Re-test Required?
Y / N. For Category A: always Y — the complete test case must be re-executed from the beginning after the correction. For Category B: depends on the nature of the finding. A typographical error in a protocol footnote does not require re-testing.
Re-test Result
PASS / FAIL / N/A. If re-test was required and failed, a new deviation row is created — the original row is not overwritten. Every execution attempt gets its own record.
Status
OPEN or CLOSED. This field must be kept current at all times. A deviation showing as OPEN that was resolved weeks ago is a finding during inspection. Only QA can change a deviation from OPEN to CLOSED.
QA Acceptance Signature
The QA representative's signature (or initials + date in the cell if electronic). Only QA closes deviations. The engineer cannot close their own deviation. This field is what an inspector looks for to confirm the closure was independently verified.
Closed Date
Date QA signed off the closure. This is the date used in the VSR deviation reconciliation table. All closed dates must precede the VSR approval date.

How the MDL Feeds the VSR

VSR-SYS-001 Section 4 is the Deviation and Change Control Summary. It contains a reconciliation table that references every entry in the MDL. The VSR cannot be approved until:

First-Pass Rate

The VSR also reports an overall first-pass rate — the percentage of test steps that passed on first execution without a deviation. The QLean PQP sets an acceptance criterion of ≥98% first-pass rate across all executed test steps. This metric is calculated from the MDL and the protocol records together. A poor first-pass rate is not a compliance failure in itself — but it will attract questions about the quality of design and pre-FAT testing.

How to Keep It Current

The single biggest MDL failure mode is not a wrong entry — it is a stale one. An MDL where deviations are entered weeks after the fact, or where closed items still show as Open, is worse than no MDL at all. It suggests the document is being maintained for appearances rather than as a live operational record.

When Action Required Owner
Deviation observed during testing Create MDL entry immediately — before continuing any testing. Do not wait until end of test session. Any team member
Within 24 hours of observation Validation Lead and QA jointly classify as Category A or B. Category A: halt affected function, notify QA Manager. Validation Lead + QA
When corrective action is implemented Update Root Cause, Corrective Action, and Resolution Date fields. Do not leave these blank while awaiting re-test. Validation Lead
When re-test passes Update Re-test Result. Request QA sign-off for closure. Validation Lead
When QA signs off Status → CLOSED. Closed Date populated. CAPA reference added if applicable. QA Representative
At every phase gate review MDL reviewed for completeness. Open Cat A count confirmed as zero before gate sign-off. Validation Lead + QA
Before VSR approval All entries closed. MDL revision baselined. VSR Section 4 populated from MDL. Validation Lead + QA
In the QLean Framework

MDL-SYS-001 is a pre-structured Excel workbook with all 16 columns, the Category A/B definitions on the Cover sheet, the Golden Rule prominently displayed in the log header, and a dashboard showing live open/closed counts per phase and category. The counts update automatically as you fill in the Status column — no manual totalling required.