Implementation Kit
AI Model Registry Template and Entry Checklist
The registry as a governed source of truth, not a spreadsheet nobody updates. A field schema, a pre-deployment entry gate, a versioning policy that says what triggers a new record, and a retirement process.
Who this is for: The MLOps or governance owner standing up a model registry and wiring it to approval and monitoring workflows.
1. Model registry data schema
SpreadsheetThe fields every entry must carry. Required fields gate deployment; optional fields add context.
Template
| Field | Required | Description | Example |
|---|---|---|---|
| model_id | Yes | Stable identifier | mdl-fraud-scoring |
| version | Yes | Semantic version of this record | 3.2.0 |
| owner | Yes | Named accountable individual | |
| use_case | Yes | What decision or output it produces | |
| lifecycle_status | Yes | Preview / Testing / Production / Deprecated / Retired | |
| risk_tier | Yes | From the classification method | |
| training_data | Yes | Sources, cut-off, lawful basis | |
| applicable_regulations | Yes | Named regimes | |
| eval_summary | Yes | Latest performance, and bias where people are affected, with dates | |
| last_review | Yes | Date of last governance review | |
| upstream_dependencies | No | Base models, vendors, datasets | |
| deployment_targets | No | Where it runs |
Worked example
| Field | Value |
|---|---|
| model_id | mdl-resume-screen |
| version | 2.4.0 |
| owner | D. Portillo, Head of Talent |
| use_case | Ranks applicants 1-5 for recruiter triage |
| lifecycle_status | Production |
| risk_tier | High |
| training_data | 5 yr hiring outcomes (internal), base model VendorLM-4; lawful basis legitimate interest with notice |
| applicable_regulations | EU AI Act Annex III, NYC LL144, GDPR |
| eval_summary | Accuracy 0.81 (2026-08); adverse-impact ratio 0.88 (2026-08), above the 0.80 line |
| last_review | 2026-08-30 |
| upstream_dependencies | VendorLM-4 base model; Greenhouse ATS |
Acceptance criteria
- ✓Every required field is defined with a data type and an allowed-values list where relevant.
- ✓The schema is the same one the deployment gate checks against.
- ✓Regulation and eval fields carry dates, so staleness is visible.
2. Registry entry pre-deployment checklist
SpreadsheetThe hard gate. No model reaches production without a complete entry.
Template
| # | Check | Status | Blocker if not met |
|---|---|---|---|
| 1 | All required schema fields populated | Y / N | Yes |
| 2 | Risk tier assigned via the classification method | Y / N | Yes |
| 3 | Latest evaluation attached, dated within 90 days | Y / N | Yes |
| 4 | Human oversight design documented (High tier) | Y / N | Yes for High |
| 5 | Applicable regulations confirmed with Legal | Y / N | Yes |
| 6 | Owner has accepted accountability in writing | Y / N | Yes |
| 7 | Rollback plan recorded | Y / N | Yes |
Worked example
| # | Check | Status | Note |
|---|---|---|---|
| 1 | Required fields populated | Y | |
| 2 | Risk tier assigned | Y | High |
| 3 | Evaluation within 90 days | Y | 2026-08-30 |
| 4 | Human oversight design documented | Partial | Override exists; no gate on low scores. Blocker. |
| 5 | Regulations confirmed with Legal | Y | Memo 2026-03 |
| 6 | Owner accepted in writing | Y | |
| 7 | Rollback plan | Y | Revert to v2.3.1, 15 min |
| Gate decision | Blocked | Close item 4 before deployment |
Acceptance criteria
- ✓The checklist is enforced in the deployment pipeline, not run on the honor system.
- ✓A failed check blocks deployment unless a named approver records a time-boxed exception.
3. Model versioning policy
DocumentSays which changes create a new registry version and which of those need a fresh governance review.
Template
One page. Attach to the schema.
A new version record is created when any of these change:
- Model weights (retrain, fine-tune, base-model swap)
- The prompt or system instructions, for prompt-based systems
- Inference parameters that affect output (temperature, thresholds, retrieval config)
- The training or retrieval data set
- The intended use case or the population affected
A new version also triggers a governance review when:
- The risk tier could change
- The change affects a High-tier system
- Evaluation shows a material shift in performance or bias
- A new regulation now applies
Every version record carries: version number, date, author, changelog, evaluation delta, reviewer (if triggered).
Worked example
Change: swapped base model from VendorLM-3 to VendorLM-4 on the resume screener.
- New version: 2.4.0 (weights changed).
- Governance review triggered: yes (High-tier system; eval delta).
- Changelog: base model upgrade; re-ran adverse-impact eval, ratio moved 0.85 to 0.88.
- Reviewer: R. Nkemelu, 2026-08-30. Outcome: approved, monitoring cadence unchanged.
Acceptance criteria
- ✓The list of change types that create a version is specific enough that two engineers would agree.
- ✓Every production model in the registry has at least one version record with a changelog.
- ✓Review-triggering changes have a linked reviewer and outcome.
4. Model retirement process
SpreadsheetDecommissioning steps so a retired model does not linger in code, storage, or documentation.
Template
| Step | Owner | Done | Evidence |
|---|---|---|---|
| Confirm no production traffic and no scheduled jobs call the model | Y / N | ||
| Migrate or sunset dependent systems | Y / N | ||
| Delete or archive model weights per the data policy | Y / N | ||
| Archive documentation, evaluations, and version history | Y / N | ||
| Set registry lifecycle_status to Retired with a date | Y / N | ||
| Notify stakeholders and update the AI inventory | Y / N | ||
| Owner sign-off | Y / N |
Worked example
| Step | Owner | Done | Evidence |
|---|---|---|---|
| Confirm no traffic or jobs | MLOps | Y | 30-day traffic log, zero calls |
| Migrate dependents | MLOps | Y | Legacy chatbot moved to support copilot |
| Delete or archive weights | MLOps | Y | Weights archived to cold storage, prod copy deleted |
| Archive documentation | AI Gov Lead | Y | Moved to governance archive, 7-yr retention |
| Set status to Retired | AI Gov Lead | Y | 2026-09-15 |
| Notify and update inventory | AI Gov Lead | Y | Inventory row marked retired |
| Owner sign-off | Head of Support | Y | 2026-09-15 |
Acceptance criteria
- ✓Retirement is not complete until every step has evidence and an owner sign-off.
- ✓The registry and the AI inventory both show the model as retired with a date.
Governance controls this kit produces evidence for
Completing the artifacts above gives you a head start on the evidence requirements for these controls.
The schema and versioning policy are the model version control standard, with a version record per change.
Each version record's changelog and evaluation delta are the model change documentation.
The retirement process is the model deprecation procedure with evidence per step.
The pre-deployment entry checklist is the intake and approval gate.
The populated registry serves as the algorithm register for production models.
This kit backs one playbook. Read the full guidance for the reasoning behind each artifact.
Decide what to implement next
Assess your governance gaps, then create an action plan with owners and target dates. Build and export without an account; sign in when you want to save your plan.
Start the AI governance assessment →