Record: Independent Code Review of a GxP Script, Notebook, or Low-Code Project

This is a ready-to-use record of an independent code review. It answers the question that homegrown analytics tools fail most often: who other than the author confirmed that the logic is correct, and against which exact version. Complete one per release of every tool that requires independent review. Replace every <<FILL: ...>> placeholder with your own specifics and route the completed record through your normal review and retention process. A filled specimen follows. This content is educational reference, not legal or regulatory advice; verify each cited regulation against the current source before you rely on it.

The independence rule, stated plainly

Self-review is not independent review. A record signed by the person who wrote the logic does not satisfy this control, no matter how carefully that person checked their own work. The reviewer must be a qualified person who did not author any part of the logic under review, and the record must say so explicitly.

Three variations that also fail the independence test, and are worth naming because each one appears in practice:

• The reviewer wrote the function under review and the author wrote the rest. Independence is judged per unit of logic, not per file.
• The reviewer’s only qualification is availability. A reviewer who cannot follow the calculation cannot confirm it, and the record should not claim otherwise.
• The review was a verbal walkthrough with no record of what was examined or what was found. An undocumented review is indistinguishable from no review.

Where the team is genuinely too small to supply an internal reviewer, draw the reviewer from another function or an approved external party and record the arrangement in section 2. A reviewer shortage is a resourcing problem, not a justification.

Record control header

Section 1: What was reviewed

For low-code projects, name the artefact actually examined. A binary project file cannot be reviewed by diff, so state what the reviewer opened, in what tool, and how the comparison against the previous version was made.

Section 2: Reviewer identity, qualification, and independence

Where the reviewer is external or drawn from another function, record the arrangement and its approval: <<FILL>>

Section 3: Review checklist

Mark each item Pass, Fail, or N/A. Any Fail raises a finding in section 4. An N/A carries a reason.

3.1 Correctness of the calculation

3.2 Edge cases, missing data, and rounding

3.3 Hard-coded values

3.4 Silent failure paths

3.5 Maintainability

3.6 Repository hygiene and data protection

3.7 Notebook-specific items (complete where the tool is a notebook)

3.8 Low-code-specific items (complete where the tool is a dashboard or visual data-preparation flow)

Section 4: Findings

Severity definitions:

Findings accepted without correction:

Section 5: Impact on testing

Section 6: Reviewer conclusion

Select one.

Reviewer statement:

<<FILL: two to four sentences stating what was examined, what was found, and the basis for the conclusion>>

Filled specimen

Independent code review of tool ANL-0007, the class A stability regression script, at initial release. Names, identifiers, and dates are illustrative.

Section 1

Section 2

Reviewer: M. Larsen, Process Statistician, Manufacturing Science. MSc in statistics, nine years applying regression and stability data evaluation in commercial biologics, routine Python user, trained on the governing SOP on 12 January 2026. Author of the logic under review: K. Osei, Stability Lead. The reviewer confirmed in writing that she authored no part of the code, has no reporting relationship to the author, and is competent to assess both the statistical method and its implementation. No second reviewer required; the risk classification specified a statistical reviewer, which this reviewer satisfies.

Section 3, results summary

Thirty-six applicable checklist items, being all of sections 3.1 to 3.6. Thirty-two Pass and four Fail, with the four Fails raising findings F-01 to F-04. The nine items in sections 3.7 and 3.8 were recorded N/A as a group with the reason stated once for each group: 3.7 because the tool is a script rather than a notebook, and 3.8 because it is neither a dashboard nor a visual data-preparation flow.

Selected evidence entries:

Section 4, findings

No findings were accepted without correction.

Section 5, impact on testing

Code changed, so TC-05, TC-06, TC-07, TC-08, and TC-11 required execution against a3f19c4 rather than 7bd0e21. Two new test cases were added to the protocol as a direct result of this review: TC-06b (prediction at a shelf life of 18 months, to prove the supplied parameter is honoured rather than a constant) and an extension of TC-11 asserting a non-zero exit status on unreadable input. The specification was found to be correct and unambiguous; no specification change was raised.

Section 6, conclusion

Approved with minor findings tracked, at commit a3f19c4.

Reviewer statement: I reviewed the five files listed in section 1 against SPEC-ANL-0007 v1.0 and the stability data evaluation SOP, and independently recomputed the slope, intercept, residual standard deviation, prediction at 24 months and the one-sided lower 95% bound on the seven-point reference dataset by hand and in a second statistical package. At commit 7bd0e21 I raised one Critical finding, one Major and two Minor. All four were corrected at commit a3f19c4, which I re-reviewed in full for the affected code paths and by diff for the remainder. At a3f19c4 the implementation matches the specification, fails visibly on the error conditions I could construct, and contains no hard-coded value that should be a controlled parameter. I did not author any part of this code.

The finding worth pausing on is F-01. The script produced correct numbers throughout development, because every dataset the author tried had a 24-month shelf life. The defect was invisible to testing until the reviewer read the code and compared it to the requirement. That is what an independent code review buys that testing does not.

Common inspection findings this record prevents

• The only person who confirmed the calculation is the person who wrote it.
• A review is claimed but no record exists showing what was examined or what was found.
• A review record exists but does not identify the version reviewed, so it cannot be tied to the version that ran.
• The reviewer is named but there is nothing on record showing they were qualified to assess the calculation.
• Findings were raised in a review but no record shows whether they were fixed, and the tool was released anyway.
• A hard-coded specification limit or date cut-off survived into production because nobody read the code.
• An exception handler suppressed a failure, so a scheduled run reported success while producing nothing, and the gap went unnoticed for weeks.
• A notebook’s saved output was never produced by its saved code, and no reviewer checked the execution order.
• Credentials or GxP data are present in the repository history.
• A dashboard has measures in the project that appear nowhere in the specification, so they were never reviewed or tested.

How to adapt this record

1. If your version control platform records merge or pull request approvals, use that as the record and attach or reference this checklist, rather than duplicating the approval in two places. What matters is that the checklist content is evidenced and the approval is attributable and timestamped.
2. Trim the checklist by risk class. Class C tools can reasonably use sections 3.1, 3.2, 3.3, and 3.4 only. Do not trim section 3.4, because silent failure is the defect that testing is least likely to catch.
3. Define reviewer qualification criteria once in the governing SOP and reference them here, so that section 2 is a confirmation rather than an argument.
4. Keep the severity definitions exactly as written or map them onto your existing defect severity scale, but preserve the rule that a Critical finding cannot be accepted with a rationale.
5. Section 5 is the part teams skip and the part that pays. A review that changes the code and does not trigger re-testing has produced a record about a version that no longer exists.
6. For low-code projects, decide in advance how a reviewer will compare versions when the project format is binary, and write that method into the governing SOP. Where the platform offers a text-diffable project format, require it for new content.
7. Retain this record for the retention period of the records the tool supports, not the life of the tool. The tool may be retired long before the results it produced leave the retention window.