# Model approval — how a model earns the right to be used

`model-tiers.md` decides *which approved model* handles a data class. This is the
process that puts a model on the approved list in the first place — and takes it
off. Without it, "approved models" is a list nobody can defend, and every new
model arrives through whichever developer tried it first.

The principle: **a model is a third-party service that makes decisions.** It goes
through the same governance you'd apply to any vendor touching customer data or
processes of record — proportionate to what you'll let it do.

## Who decides

A small standing group, not a single enthusiast and not a committee that meets
quarterly. Practically: an owner from engineering, one from risk/compliance, and
one from security/privacy. They own a **model register** — the source of truth
for what's allowed, on what data class, for what use.

## The approval criteria

A model is assessed on what it would actually be trusted with:

- **Capability** — does it pass the task's quality bar, measured against a graded
  baseline, not a vibe? (`verify-with-data.md`)
- **Data handling** — residency, retention, and whether your inputs train the
  vendor's model. This gates the highest data class it may ever see.
  (`vendor-eval.md`)
- **Security posture** — auth, tenancy isolation, the vendor's own certifications.
- **Auditability** — can every call be logged and reconstructed? A model you
  can't audit can't touch regulated data.
- **Cost profile** — price per unit of work at the expected volume, so routing
  decisions have real numbers behind them.
- **Reversibility / exit** — can you switch away? What's the lock-in?

## The register entry

Each approved model records: the model + version, approved data classes, approved
use cases, the data agreement reference, the owner, the approval date, and the
**re-approval date**. Approval is *time-boxed*, not permanent.

| Field | Example |
|-------|---------|
| Model + version | `provider/model-x-2026-01` |
| Max data class | Internal (not Sensitive/Regulated) |
| Approved uses | Code generation, internal summarisation |
| Data agreement | DPA-2026-014; no training on inputs |
| Owner / review by | Platform team / re-approve 2026-12 |

## Operating it without strangling delivery

- **A fast lane for low stakes.** Public-data, low-blast-radius experimentation
  on already-approved models needs no new approval — just logging. Reserve the
  full process for new vendors, new data classes, or new decisions of record.
- **Version awareness.** A model version bump can change behaviour. Material
  upgrades re-enter assessment; the register pins versions for regulated use.
- **A revocation path.** When a model fails — a security finding, a quality
  collapse, a pricing change — it can be pulled, and the register says what
  replaces it.

## The one-line test

> Point at any model in use and ask: who approved it, for what data, and when does
> that approval expire? If the answer is "it was already there," it isn't governed.