Skip to content
ProofPack docs
  • FDA AI-DSF lifecycle guidance: DRAFT (Jan 2025) — not for implementation
  • PCCP guidance: final (Dec 2024, updated Aug 2025)
  • FDA Statistical Guidance on diagnostic tests: final (2007)
  • Guidance map v1

The T12 IQ/OQ pack

T12 is the document that answers the question your quality system asks of any software whose output goes into a regulatory record: what is it, what could go wrong, what evidence is there that it computes what it says, and how do we qualify it here.

T12 supports, does not replace, your own validation per your SOP.

That sentence is in the pack, in the licence email that links to it, and here. ProofPack is statistical software. Its computational correctness is warranted by Global Phoenix Solutions Ltd to the tolerances the pack states, on the reference platform the pack states; the qualification of the tool inside your environment, under your procedures, is yours to perform and yours to record. No regulator has reviewed T12 or ProofPack.

What the pack contains

Section titled “What the pack contains”

T12 follows the structure of a computer software assurance record. Its sections, as specified for the engine’s packaging day:

  1. Intended use of the software, and the out-of-scope list from the scope statement — the same words every pack carries.
  2. Failure-mode risk table: the ways a statistical tool can produce a wrong or misleading number, and the control in the engine for each — the HALT gates, the typed refusals in place of a silent fallback, the confidence interval and sample size on every reported quantity, the [unverified] marking that survives to the page.
  3. Assurance evidence, auto-filled from fixtures_report.json: the result of every fixture in the engine’s register — closed-form values cross-checked against statsmodels and scikit-learn, values captured from R’s pROC and rms, published FDA 510(k) subgroup tables, the determinism and parity runs, the egress and licence fixtures. Each row says pass, fail or pending, and a fixture whose expected value has not yet been captured from its primary source is marked [unverified] in the report, not rounded up to a pass. The validation page publishes the same report for the current release.
  4. Determinism and tolerance policy: the reference platform (python:3.12-slim, linux/amd64, pinned lockfile) on which two runs of the same input give an identical manifest hash and byte-identical JSON; and the tolerances on every other platform — closed-form statistics to 1e-9, iterative ones to 1e-6, bootstrap intervals to their reported rounding with the same seed. T12 claims hash identity only on the reference platform.
  5. IQ/OQ script — the section your RA lead executes.

The IQ/OQ script

Section titled “The IQ/OQ script”

Installation qualification is proofpack doctor in the environment the tool will run in: interpreter, dependencies, schema files, write access, licence, platform. Operational qualification is three steps:

  1. proofpack fixtures — runs the fixture register on your machine and writes fixtures_report.json and .html; every value must match the frozen expectation to its tolerance.
  2. Mapping verification — proofpack map on your test table, and a person confirming that every role is the column it should be.
  3. Declaration echo — a run’s T8 manifest echoes criteria.yaml verbatim; the RA lead checks that what the engine used is what was authored.

Each step has a place in the pack to record who did it, when, and the result. Nothing in the script is a judgement about a model; it is a check that the tool computed what it claims, where you run it.

Completion

Section titled “Completion”

When the script is complete, T12 asks two things of the person who completed it: how long the IQ/OQ took, and whether any wording in the pack was changed. Both are read by us. The completion time is the one number we ask a customer for, and it is a number about the tool, not about the data. Any changed wording is reviewed against the sentence library and, if it is better, adopted for every customer.

Engine status

Section titled “Engine status”

proofpack fixtures and the T12 renderer are the engine’s packaging day and are not in engine 0.1.0.dev1. The fixture register they will run exists and is published on the validation page, where every row is pending until the engine’s CI publishes its artefact.

Section titled “Print and PDF”

Packs render to DOCX, HTML and JSON. There is no PDF renderer in version 1; the HTML pack prints to PDF from a browser, and T12 says so.