Project-derived · sanitized
Model Change Control Log (sanitized)
Turns 'we updated the model' into a governed decision. Every change carries a risk level, the metrics it touches, whether revalidation is required, a named approval owner, and the evidence to keep, so no silent update reaches a patient without someone accountable signing for it.
What this artifact is for
A change control log exists to stop the most common failure mode of a deployed medical AI: a silent update that shifts behaviour with no record of who approved it, what it affected, or how to roll back. It makes every change a governed decision. Each row answers five questions at once: what changed, how risky it is, which metrics it touches, whether revalidation is required, and who has the authority to approve it, plus the evidence that must survive the change.
This is the change-control structure I apply in pre-deployment governance design for my patient-facing cardiometabolic twin. It maps to FDA Predetermined Change Control Plan (PCCP) thinking: classify the change, pre-define the revalidation and approval envelope, and keep the evidence trail. It is the fillable log that pairs with the Change control and PCCP case, which sets out the change-class gates, the no-deployable-version fallback, and the retirement state this log records against. Because the system I build has not yet deployed, the worked rows are an illustrative change-control plan used to exercise the structure, not entries from a live system. It carries no confidential project or patient detail.
Fixed metadata
| Field | Value |
|---|---|
| Data provenance | Version records, change requests, validation reports, test records, UI screenshots, workflow assessments |
| Model version | Applies across pre- and post-change versions (version pinned at each validation point) |
| Approval owner | Defined per change in the table below |
| Effective date | Not yet in force (pre-deployment) |
| Version | v0.1 |
| Last updated | August 2026 |
| Known limitation | Different changes affect risk differently; risk level and approval owner must be judged against the clinical use context, not applied mechanically |
Change control log
| Change ID | Change Description | Risk Level | Metrics Affected | Revalidation Required? | Approval Owner | Evidence to Keep |
|---|---|---|---|---|---|---|
| C-001 | Update model from v1.2 to v1.3 | High | Sensitivity, false negatives, subgroup gap | Yes | Clinical Director / Change Control Board | Validation report, version log |
| C-002 | Adjust high-risk threshold from 0.70 to 0.65 | High | Sensitivity, specificity, PPV | Yes | Clinical Safety Lead or Clinical Director | Threshold analysis, decision memo |
| C-003 | Add new hospital data to training set | Medium/High | Calibration, subgroup performance | Yes | Governance Lead + Clinical Safety Lead | Data provenance, validation report |
| C-004 | Change image preprocessing pipeline | Medium | AUC, sensitivity, false negatives | Yes | ML Lead (escalates to Clinical Safety Lead if clinical metrics move) | Technical change note, test result |
| C-005 | Change alert wording in clinician UI | Medium | Override rate, clinician reliance | Maybe | Clinical Safety Lead (Product Owner cannot approve alone) | UI screenshots, user-testing notes |
| C-006 | Integrate AI alert into emergency workflow | High | Time-to-review, false negatives, workflow risk | Yes | Clinical Director / Change Control Board | Workflow risk assessment |
Who approves what: the four-question test
When it is not obvious who signs for a change, four questions decide the approval owner:
- Does it affect patient safety? → Clinical Director / Clinical Safety Lead.
- Does it affect technical performance but not yet clinical impact? → ML Lead, with the Governance Lead keeping the evidence; escalate if clinical metrics move.
- Does it change how clinicians read or use the AI? → Clinical Safety Lead; the Product Owner cannot approve alone.
- Does it affect legal duties, patient consent, data use, or regulatory notification? → Legal / Compliance.
The design principle
Change control is only real when each change is tied to a risk classification, a revalidation trigger, a named approval owner, and a retained evidence trail. The point of the Governance Lead is not to approve everything: it is to make sure the right people approve on the basis of the right evidence, and that a safe prior version always remains to fall back to.
Citation metadata
| Field | Value |
|---|---|
| Title | Model Change Control Log (sanitized) |
| Author | Xiaoyan Qian |
| Public page version | v0.1 |
| Publication date | 2026-08-10 |
| Stable URL | https://xiaoyanqian.com/artifacts/change-control-log/ |
| Licence | All rights reserved |
| Suggested citation | Qian, X. (2026). Model Change Control Log (sanitized) (v0.1). https://xiaoyanqian.com/artifacts/change-control-log/ |