This is a ready-to-use master tracker for an entire statistical programming validation package: one row per analysis dataset, table, listing, or figure, showing tier, who is assigned, where the compare and log review each stand, and whether sign-off is complete. Replace every <<FILL: ...>> placeholder, keep it live during production and validation, and retain the final version as a GCP record. A filled sample follows. This is general educational content to adapt, not regulatory advice.
Why this tracker earns its place
The SOP’s filled specimen shows what a completed validation record looks like for one output. The discrepancy log records defects for one output or output group. The TLF package QC sign-off record asks, at the end, whether the whole package is complete and consistent, and its evidence for “every Tier 1 and Tier 2 output has a closed, signed validation record” is a count, so many validated out of so many in the package. None of those three documents is a live, row-per-output roster a lead programmer can actually look at halfway through a 150-table package and say which outputs are done, which are mid-compare, and which have not started. This tracker is that roster. It is the working evidence behind the package-level count, not a replacement for the per-output validation record or the discrepancy log.
Header
| Field | Entry |
|---|---|
| Study / protocol | <<FILL>> |
| Validation plan reference | <<FILL: plan ID, e.g. SPVP-ABC301-01>> |
| Package scope | <<FILL: e.g. Final CSR TLF package>> |
| Tracker owner | <<FILL: Lead Statistical Programmer>> |
| Last updated | <<FILL: date>> |
Field definitions
| Field | Format | Required | Who enters | When |
|---|---|---|---|---|
| Output ID | Dataset/table/listing/figure ID | Yes | Lead programmer | At plan approval |
| Description | Short text | Yes | Lead programmer | At plan approval |
| Tier | 1 / 2 / 3 | Yes | Lead programmer, per the validation plan | Before production starts |
| Production programmer | Name | Yes | Lead programmer | At assignment |
| Validation programmer | Name | Yes (Tier 1/2) | Lead programmer | At assignment |
| Spec / shell version used | Version ID | Yes | Production programmer | At production start |
| Production status | Not started / In progress / Complete | Yes | Production programmer | Ongoing |
| Compare status | Not started / In progress / Clean / Clean after reconciliation | Yes | Validation programmer | Ongoing |
| Open discrepancies (count, ref) | Number plus discrepancy log IDs | Yes | Validation programmer | Ongoing |
| Log review status | Not done / Done, clean / Done, issues resolved | Yes | Either programmer | After compare |
| Shell / cross-output check | Pass / Fail / Pending | Yes | Validation programmer | Before sign-off |
| Sign-off | Name plus date, or blank | Conditional | Independent reviewer | At closure |
| Status | Not started / In progress / Blocked / Complete | Yes | Lead programmer | Ongoing |
Entry rules
- Open every row at plan approval, before production starts, using the output list and tiers from the validation plan. An output with no row is an output no one is tracking.
- Update status at least weekly during active validation, or at each milestone (compare run, discrepancies closed, sign-off), whichever is more frequent.
- “Clean after reconciliation” is a valid compare status only once the open discrepancy count for that row is zero and the discrepancy log entries are closed.
- A row cannot move to Complete without a sign-off entry naming someone other than either listed programmer.
- A row stuck at Blocked for more than
<<FILL: threshold, e.g. 5 working days>>is escalated to the lead programmer and noted with a reason.
The tracker table
| Output ID | Description | Tier | Production | Validation | Spec/shell ver | Prod status | Compare status | Open disc. | Log review | Shell check | Sign-off | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Acceptance criteria
The tracker is adequate as a GCP record when every output named in the validation plan has a row opened before production started; every row’s tier and assignments match the validation plan; status fields are current as of the “last updated” date; no row shows Complete without a sign-off naming an independent reviewer; and the total of Complete rows reconciles exactly to the count cited in the package-level QC sign-off record.
Retention
Retain the tracker, in its final state at package sign-off, with the validation package (plan, discrepancy logs, program logs, signed validation records) under the trial master file retention schedule, for not less than <<FILL: retention period>>.
Filled sample
Excerpt from a 41-output final CSR package, tracker updated midway through validation.
Header: Study ABC-301; plan SPVP-ABC301-01; Final CSR TLF package; owner R. Mehta; last updated 02-Apr-2026.
| Output ID | Description | Tier | Production | Validation | Prod status | Compare status | Open disc. | Log review | Shell check | Sign-off | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|
| ADSL | Subject-level dataset | 1 | J. Okafor | L. Serra | Complete | Clean after reconciliation | 0 (D-001, D-002 closed) | Done, clean | Pass | R. Mehta, 20-Mar-2026 | Complete |
| Table 14.2.1 | Primary efficacy | 1 | J. Okafor | L. Serra | Complete | In progress | 1 (D-003 open) | Done, issues resolved | Pending | None yet | In progress |
| Table 14.3.2 | AE overview | 1 | M. Ruiz | J. Okafor | Complete | Clean after reconciliation | 0 (D-004 closed) | Done, clean | Pass | R. Mehta, 28-Mar-2026 | Complete |
| Table 14.4.5 | Exposure summary | 2 | L. Serra | M. Ruiz | In progress | Not started | 0 | Not done | Pending | None yet | In progress |
| Listing 16.2.9 | Concomitant meds | 3 | M. Ruiz | QC by L. Serra | Complete | Clean | 0 | Done, clean | Pass | R. Mehta, 25-Mar-2026 | Complete |
At this snapshot, 3 of 41 outputs show Complete, one (Table 14.2.1) has an open discrepancy against the primary efficacy table and is correctly blocked from sign-off until it closes, and the exposure table has not yet reached compare. A lead programmer or an auditor reading this one table can state the package’s real status without opening 41 separate validation records.
Common inspection findings this tracker prevents
- A package-level claim of “all outputs validated” with no row-level roster to support the count, discovered only when an auditor asks to see it broken down.
- An output quietly marked Complete with an open discrepancy still on the log, because the only record of that discrepancy lived in a different document no one cross-checked.
- A production programmer and validation programmer pairing that, across the whole tracker, always matches the same two names, visible only once every row is in one place.
- Status updates that lag so far behind reality that the tracker itself becomes a stale, unreliable record rather than the live evidence it is meant to be.
How to adapt this tracker
- Generate the initial row set from the approved validation plan’s output list, not from a running memory of what exists.
- Keep the field set; add columns only if your tooling genuinely tracks more, such as a link to the exact compare-log file or a pipeline run status.
- Decide and state your own staleness threshold for “last updated” and for escalating a Blocked row.
- Reconcile the tracker’s Complete count against the package-level QC sign-off record before that record is signed; a mismatch is a finding to resolve before release, not after.