This is a ready-to-use discrepancy log for independent (double) programming validation. It records every difference the compare reports, its root cause, which program was correct, and the resolution, so a reviewer can see that the right program won each disagreement. Replace every <<FILL: ...>> placeholder, keep it under version control with the validation package, and retain it as a GCP record. A filled sample row follows. This is general educational content to adapt, not regulatory advice.
Purpose and when to use
Open one discrepancy log per output (or per related output group) under validation. Record a row for every discrepancy the automated compare flags, and for every mismatch against the approved shell. A discrepancy stays open until its root cause is documented and the compare reruns clean. A closed log with a clean final compare is the evidence that the delivered output equals the validated one.
Header (one per log)
| Field | Entry |
|---|---|
| Study / protocol | <<FILL: study ID>> |
| Output(s) covered | <<FILL: table/listing/figure ID(s)>> |
| Validation tier | <<FILL: 1 / 2 / 3>> |
| Production programmer | <<FILL: name>> |
| Validation programmer | <<FILL: name>> |
| SAP version | <<FILL: version>> |
| Shell version | <<FILL: version>> |
Field definitions
| Field | Format | Required | Who enters | When |
|---|---|---|---|---|
| Discrepancy ID | Sequential (e.g. D-001) | Yes | Validation programmer | At detection |
| Date raised | Date | Yes | Validation programmer | At detection |
| Output / variable | Table/variable name | Yes | Validation programmer | At detection |
| Description | Free text: what differed | Yes | Validation programmer | At detection |
| Compare evidence | Reference to compare log line | Yes | Validation programmer | At detection |
| Suspected source | Production / validation / spec / data | Yes | Either programmer | During investigation |
| Root cause | Free text | Yes | Owner of the defective program | At resolution |
| Which program was correct | Production / Validation / Both wrong / SAP ambiguous | Yes | Both, agreed | At resolution |
| Resolution / action | Free text: what was changed | Yes | Owner of the defective program | At resolution |
| SAP amendment needed | Yes / No / N/A | Yes | Statistician | At resolution (if spec issue) |
| Rerun compare clean | Yes / No | Yes | Validation programmer | After fix |
| Status | Open / Closed | Yes | Validation programmer | Ongoing |
| Date closed | Date | Yes at close | Validation programmer | At close |
Entry rules
- Record every flagged difference, including ones that turn out to be the validation program’s own defect. A log that only shows production defects looks curated.
- “Matches except rounding” is a discrepancy, not a pass. Record it, find which program implemented the SAP rounding rule wrong, and fix it.
- Name the SAP section when the root cause is an ambiguous or misread specification, and route it to the statistician; if the analysis itself changes, that goes through a dated SAP amendment, not a quiet code edit.
- A discrepancy is closed only when the compare reruns clean and the root cause and resolution are recorded. Do not close on “could not reproduce.”
- The reviewer who signs the validation record confirms the log has no open rows before sign-off.
The discrepancy table
| ID | Date raised | Output / variable | Description | Suspected source | Root cause | Correct program | Resolution | SAP amend? | Rerun clean | Status | Date closed |
|---|---|---|---|---|---|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Retention
Retain the discrepancy log with the validation package (programs, compare logs, program logs, signed validation record) under the trial master file retention schedule, for not less than <<FILL: retention period>>. The log is a GCP record and is subject to the same integrity expectations (attributable, contemporaneous, complete) as any study record.
Filled sample
The following shows two completed rows for a primary efficacy table, so you can see the expected detail. Names and numbers are illustrative.
Header: Study ABC-301; Output Table 14.2.1 (responder rate, Week 24, ITT); Tier 1; Production J. Okafor; Validation L. Serra; SAP v3.0; Shell v2.
| ID | Date raised | Output / variable | Description | Suspected source | Root cause | Correct program | Resolution | SAP amend? | Rerun clean | Status | Date closed |
|---|---|---|---|---|---|---|---|---|---|---|---|
| D-001 | 10 Jul 2026 | Table 14.2.1, placebo denominator | Placebo N = 88 (prod) vs 90 (val) | Production | Prod dropped 2 subjects with a Week 24 visit outside the window; SAP keeps all randomized ITT in the denominator | Validation | Corrected prod denominator logic to keep out-of-window subjects | No | Yes | Closed | 11 Jul 2026 |
| D-002 | 10 Jul 2026 | Responder %, treatment arm | 41.15% (prod) vs 41.2% (val) | Spec | SAP rounding rule read two ways; SAP specifies round-half-up to one decimal | Validation | Corrected prod rounding to match SAP | No | Yes | Closed | 11 Jul 2026 |
In this example the second program caught a denominator error that would have inflated the placebo response rate and shrunk the treatment difference in the primary endpoint, and a rounding difference that revealed the SAP rule had been implemented two ways. Both were traced to a documented root cause, corrected in the program that was wrong, and closed only after the compare reran clean. That is the evidence that makes the primary endpoint defensible.
Common inspection findings this log prevents
- Discrepancies closed with no documented root cause, so there is no evidence the correct program won.
- A log that shows only production defects, implying the validation program was never itself wrong.
- Rounding differences dismissed as trivial rather than traced to a SAP rule implemented inconsistently.
- An analysis change made directly in code when the root cause was a specification issue that needed a SAP amendment.
- The validation signed off with open discrepancy rows.
How to adapt this log
- Open one log per output or related output group, and fill the header before validation starts.
- Keep the field set; add columns only if your tooling captures more (for example a link to the exact compare-log line or commit).
- Route specification-level root causes to the statistician and record whether a SAP amendment resulted.
- Store the log with the rest of the validation package under version control, and confirm your retention period against the records schedule.