This is a ready-to-use approval record for the moment before a new third-party package gets written into a GxP script, notebook, or low-code pipeline, not for a version you already use and are simply updating. It is the gate that keeps “it had the right function on PyPI” from being the entire due-diligence record. Complete one per new package before the import lands in a reviewed commit. Replace every <<FILL: ...>> placeholder with your own specifics and route the completed form through your normal review and approval. 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.
Record control header
| Field | Entry |
|---|---|
| Form title | Open-Source Library and Package Adoption Approval |
| Form number | <<FILL: form ID, e.g. FRM-CSV-032-01>> |
| Governing procedure | <<FILL: SOP-ID for validation of GxP scripts, notebooks, and low-code analytics>> |
| Approval record number | <<FILL: PKG-YYYY-nnnn>> |
| Package name | <<FILL>> |
| Ecosystem | PyPI / CRAN / Bioconductor / npm / Other: <<FILL>> |
| Requesting tool ID | <<FILL: from the analytics tool inventory register>> |
| Requested by | <<FILL: name and role>> |
| Request date | <<FILL>> |
| Reason for this record | New adoption / Re-approval following a major version change / Periodic re-check <<FILL>> |
Section 1: Package identification
| Field | Entry |
|---|---|
| Package name and short description of what it does | <<FILL>> |
| Source repository (project home, not a mirror) | <<FILL: URL>> |
| Latest published version at the time of this review | <<FILL>> |
| Exact version requested for pinning | <<FILL>> |
| Why this package instead of writing the function in-house or using an already-approved alternative | <<FILL>> |
Pin the exact version you intend to approve, never a range. If the answer to the last row is “it was the first result in a search,” that is a reason to look again, not a reason to approve.
Section 2: Maintenance status
| Check | Entry |
|---|---|
| Date of most recent release | <<FILL>> |
| Release cadence over the last two years (steady, sporadic, dormant) | <<FILL>> |
| Number of active maintainers (named, committing within the last year) | <<FILL>> |
| Open issue tracker triaged, or a backlog with no visible response | <<FILL>> |
| Single-maintainer risk present | Yes / No. If yes, state the compensating plan: <<FILL: e.g. vendored fork retained, pinned version archived independently of the upstream project>> |
| Maintenance status | Acceptable / Acceptable with a noted risk / Not acceptable |
A project with no commits in two years is not disqualified on that fact alone if the function is small, stable, and the behavior has not changed in that time, but say so explicitly rather than treating silence as a passing score by default.
Section 3: License review
| Check | Entry |
|---|---|
| License identified (exact SPDX identifier where available) | <<FILL>> |
| Permissive (MIT, BSD, Apache 2.0, or equivalent) | Yes / No |
| If not permissive, obligations that apply to your intended use (attribution, source disclosure, copyleft scope) | <<FILL>> |
| Legal or IP review required | Yes / No. If yes, reviewer and outcome: <<FILL>> |
| License decision | Approved for intended use / Approved with conditions / Not approved |
Section 4: Known-vulnerability history
| Check | Entry |
|---|---|
| Vulnerability source(s) checked (software composition analysis tool, public vulnerability database, project security advisories) | <<FILL>> |
| Date checked | <<FILL>> |
| Open vulnerabilities against the exact version requested | <<FILL: list CVE IDs, or "None found">> |
| For each open vulnerability, reachability in this configuration and decision | <<FILL>> |
| Vulnerability decision | Clear to proceed / Proceed with a documented accepted risk / Blocked pending a fix or an alternate version |
Section 5: Core-function spot-check
Complete this section only if the package performs, or materially contributes to, a calculation whose result feeds a GxP decision. If the package is purely structural (logging, file I/O, a command-line interface framework) with no computational role in the result, mark it not applicable and state why.
| Field | Entry |
|---|---|
| Does this package’s output matter to a GxP calculation | Yes / No |
| If No, basis for that conclusion | <<FILL>> |
| If Yes, the specific function(s) being relied on | <<FILL>> |
| Independent reference used for the spot-check (hand calculation, a second package implementing the same method, a validated tool) | <<FILL>> |
| Test inputs and expected result | <<FILL>> |
| Actual result from the package | <<FILL>> |
| Agreement to stated precision | Pass / Fail |
| If Fail, disposition | <<FILL: package rejected, different version tried, or function usage corrected>> |
Testing the package’s output against a reference produced by the same package proves nothing. The reference has to come from somewhere else.
Section 6: Scope of approval
| Field | Entry |
|---|---|
| Approved for (name the specific function, class, or module) | <<FILL>> |
| Explicitly not approved for | <<FILL: other functions in the same package not reviewed>> |
| Downstream tools permitted to use this approval | <<FILL: tool ID(s), or "this tool only">> |
| Pinned version recorded in the environment manifest from the first commit | Yes / No (No is not an acceptable closing state) |
Section 7: Decision
| Field | Entry |
|---|---|
| Overall decision | Approved / Approved with conditions / Rejected |
| Conditions, if any | <<FILL>> |
| Linked tool risk classification record | <<FILL: reference to the completed analytics tool risk classification form>> |
| Next scheduled re-check (tie to the tool’s periodic review cycle) | <<FILL>> |
Section 8: Signatures
| Role | Name | Signature | Date | Statement |
|---|---|---|---|---|
| Requester | <<FILL>> | I confirm the information in sections 1 to 6 is accurate as of the date checked. | ||
| Independent reviewer or SME (required if section 5 applies) | <<FILL>> | I confirm the spot-check reference was independent of the package under review and the result is correctly recorded. | ||
| Validation or CSV lead | <<FILL>> | I confirm the decision is consistent with the risk class of the tool this package feeds. | ||
| Quality Assurance (required for Class A tools per the tool’s risk classification) | <<FILL>> | I approve the adoption decision and the scope stated in section 6. |
Section 9: Version history for this approval
Record every subsequent version change reviewed under this approval record, so a reader can see the full history without hunting through change control separately.
| Date | From version | To version | Reason for change | Re-reviewed sections | Approved by |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Acceptance criteria
- Every new third-party package has a completed record before its first import in reviewed GxP code, never backfilled after the fact.
- Sections 2 through 4 are each completed with a stated decision, not left blank on the assumption that “it’s popular, it’s probably fine.”
- Section 5 is either completed with an independent spot-check or marked not applicable with a stated, specific reason.
- The approval states the exact scope it covers and the exact version pinned; a version range or “latest” anywhere in section 1 or 6 fails this form.
- A version change after initial approval is logged in section 9, not treated as a non-event.
References
21 CFR 211.68(b) (controls over computers and accuracy of input and output). EU GMP Annex 11 (risk-based validation of computerised systems). GAMP 5 Second Edition (custom and configured software categories, risk-based critical thinking). FDA guidance, Computer Software Assurance for Production and Quality Management System Software (scale assurance effort to risk).
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows the form completed for a statistics package added to a continued process verification notebook. Company, system, and numbers are illustrative.
| Field | Entry |
|---|---|
| Approval record number | PKG-2026-0014 |
| Package name | Changepoint-detection package for time-series monitoring |
| Ecosystem | PyPI |
| Requesting tool ID | ANL-0057, CPV monitoring notebook |
| Requested by | M. Okafor, Statistician |
| Request date | 12 September 2026 |
| Reason for this record | New adoption |
Section 1. Detects a shift in the mean of a time-ordered series; proposed to replace a manual control-chart rule set with a formal changepoint method. Source repository is the project’s public home, not a third-party mirror. Latest published version at review: 3.2.1. Version requested for pinning: 3.2.1. Chosen over writing the method in-house because the method has a published, peer-reviewed basis and a second, independent package implements the same method for cross-checking.
Section 2. Most recent release six weeks before this review. Release cadence over two years: steady, four to six releases per year. Two active maintainers with commits in the last year. Issue tracker triaged within roughly two weeks of filing. No single-maintainer risk. Maintenance status: Acceptable.
Section 3. License identified as BSD-3-Clause. Permissive: Yes. No copyleft obligations. No legal review required for this internal use. License decision: Approved for intended use.
Section 4. Checked via a software composition analysis scan and a manual check of the public vulnerability database on 12 September 2026. No open vulnerabilities found against version 3.2.1. Vulnerability decision: Clear to proceed.
Section 5. Does the package’s output matter to a GxP calculation: Yes, it flags the changepoint used to set revised CPV control limits. Independent reference used: a hand-derived reference series with a known injected shift at observation 40, cross-checked against a second, independently maintained package implementing the same underlying method. Test inputs: synthetic series, 80 points, shift of 1.5 standard deviations injected at point 40. Expected result: changepoint detected at point 40 plus or minus 1. Actual result: changepoint detected at point 41. Agreement to stated precision: Pass.
Section 6. Approved for: the single changepoint-detection function used in this notebook. Explicitly not approved for: the package’s plotting utilities and its experimental multivariate module, neither of which was reviewed. Downstream tools permitted: ANL-0057 only; any other tool proposing to use this package files its own record. Pinned version recorded in the environment manifest from the first commit: Yes.
Section 7. Overall decision: Approved. No conditions. Linked tool risk classification record: RC-2026-0071 (Class A, feeds CPV control limits). Next scheduled re-check: at the tool’s annual periodic review, or immediately on any new major version release, whichever comes first.
Section 8. Requester M. Okafor, signed 12 September 2026. Independent reviewer D. Kessler, Senior Statistician, signed 13 September 2026. Validation lead signed 15 September 2026. QA approval signed 16 September 2026, noting the Class A tool risk classification made QA sign-off mandatory.
Common inspection findings this form prevents
- A package adopted because it had the right function, with no record anyone checked who maintains it.
- A statistical or numerical package trusted on reputation alone, with no independent check of its output against a reference the team did not also produce with the same package.
- A package approved in general terms that later gets used for an unreviewed function deep inside it.
- A version range left in a requirements file because “we’ll pin it later,” which never happens.
- A known vulnerability discovered after the fact with no record that anyone looked before adoption.
- A major version upgrade applied with no re-review, carrying a silently changed default into a validated calculation.
How to adapt this form
- Set your document number and point the governing procedure field at your real analytics script and notebook validation SOP.
- If your organization already runs software composition analysis automatically across repositories, reference its output as the evidence for section 4 rather than re-running a manual check, and say so in the field.
- Decide in your governing SOP whether a Class B or C tool (see the analytics tool risk classification form) can close this form without QA sign-off, and state that threshold explicitly rather than leaving section 8 ambiguous.
- For a team adopting many small utility packages with no computational role, allow a lighter version of sections 2 through 4 for that category, but keep section 5’s independence rule absolute whenever a package’s math feeds a result.
- Reconcile this form’s package list periodically against your software composition analysis or dependency-scanning tool output, the same way a device SOUP inventory reconciles against its SBOM, so the two never silently diverge.
- Confirm every regulation in the references section against the current published version before issue.