Model registry vs vendor list: know which models run

A vendor list names the suppliers you buy from; a model registry names the models your systems call and the terms under which each may run. One is a procurement view. The other is an operating view.

An approved supplier can serve an endpoint that nobody has authorized for a particular task or data class. A locally hosted model can process production requests without appearing on any supplier list. Both are model decisions. Neither is settled by naming the vendor.

The Model Portfolio calls the registry the canonical catalog of every model in the portfolio. It is the Register step of ROUTE. With low volume, one task type and no regulated data, one model may be enough. That model still needs a mandate, an owner and a data boundary.

What does each list answer?

Question	Vendor list	Model registry
Who is the counterparty?	Provider, contract and renewal	Not its question; records this model’s host and entry owner
What is running?	A purchased service or product	Model ID and, where material, its host and run configuration
What work may it handle?	A purchased capability	Mandate naming authorized task types
What data may it receive?	Provider data-use terms	Privacy class for this model on this host
What happens when it changes?	Supplier or contract review	Route review, status change and eventual retirement

The vendor view has a real job. Chapter 11 of the book keeps a separate provider risk register, one row per counterparty, for dependency share, notice floor and track record, pricing stability, data-use terms, validated alternatives and renewal date. Several models from one provider share one counterparty exposure, and a contract with that provider still does not say which of them a route called.

The two lists drift apart because access is cheap and validation is not. A prototype built in an afternoon on an existing account can start carrying live traffic without a formal decision, and no supplier review fires because no supplier is new. Teams also add models in parallel: data science runs an embeddings model, product wires a vision model into a prototype, devops provisions a local model for log analysis. Each adds an operating position without a new contract.

The registry’s row unit is a model and its material run configuration. Register distinct hosts separately, even for the same weights: the host changes cost, latency and privacy constraints. Behind a multi-provider gateway, the book warns, pinning a model does not by default pin a host; the gateway can pick the provider and fail over to another. Where a privacy tier or contract requires one host, Chapter 5’s remedy is to pin the provider order, switch off automatic cross-provider fallback and write the permitted hosts into the row. The gateway itself gets a row in the provider risk register.

What belongs in the smallest useful registry?

Chapter 3 of The Model Portfolio gives a nine-field minimum, each field answering an operating question.

Field	What to write
Model ID	A stable identifier that can be matched to configuration and call records.
Display name	A label a person can recognize in a dashboard or policy table.
Tier	The portfolio role: frontier, workhorse, local or specialist.
Mandate	The task types this model is authorized to handle here.
Cost class	Low, medium or high relative to your own portfolio, rather than a copied price.
Privacy class	The data this model may receive on its registered host.
Deployment host	The API, private endpoint, server or device where it runs.
Retirement status	Active, deprecated or sunset.
Registry owner	The person accountable for keeping the entry current.

Mandate is permission, not a capability claim. A model may generate code in a test yet be authorized only for internal batch summaries. A code-generation route needs a separate decision. Tier is also a role in your portfolio, not a badge the vendor awards. Frontier, workhorse and local are three of the book’s classes; its fourth, specialist, is for a frequent, well-defined task where general models miss the quality bar.

Cost class is a routing signal, not an invoice. Low, medium and high are relative to your portfolio. Keep prices and the class-to-price mapping separately. Recalibrate when asymmetric repricing moves a model across a band or your model mix changes. A low cost class says nothing about quality; the model still has to pass your task evaluation.

Privacy class comes before cost or capability. Where the model runs, the provider’s data-processing terms and your own data policy decide what a route may receive. Write under-review for an unknown class, with an owner and a resolution date. The book lets such an entry sit in the registry but not serve production requests. Its one written exception is a time-boxed continuation, granted and logged by the registry owner and capped at the resolution date, for an already-running route that carries no personal or regulated data. A resolution date is a deadline for a decision, not permission to route.

Chapter 3 then adds five fields as the portfolio grows:

• Ability tags and dated performance notes, once you must tell models within a tier apart. Use one controlled vocabulary, such as structured-extraction and code-generation, and keep dated notes from your own evaluations, failures included.
• License and run configuration, once open-weight or reasoning-tier models enter. A permissive MIT license and a community license with commercial restrictions are different legal postures, and a 4-bit quantization or a higher reasoning effort can change quality, latency and cost on the same model ID.
• Stack dependency, on every row: the SDK, API version, serving framework and runtime the route was evaluated against. The book observes that this layer usually decides whether a migration is a swap or a wait.

A registry row makes a model eligible; it does not prove that the model meets your quality bar on a new route.

How can an approved supplier still hide a shadow model?

Hypothetical example. A software team has two approved suppliers. North provides a model API. South provides a document-enrichment integration. The vendor list holds both contracts, data-use terms and renewal dates. Procurement has done its job.

The platform team reconciles thirty days of API logs with South’s integration usage export. The records show two different model calls:

Observed use	Vendor-list view	Registry check
batch-summary-v2 on North’s API summarizes internal tickets	North is an approved counterparty	Entry found: ID, host, internal-summary mandate, cost and privacy classes, active status, owner
extract-a inside South’s integration processes new account documents	South is an approved counterparty	No entry: the model, its host, mandate, privacy class and owner are absent

Supplier approval records no model-specific mandate or privacy class. That makes extract-a a shadow model in the book’s sense: in use without a registry entry. Neither the supplier relationship nor the integration bill says what it was authorized to receive.

Suppose a sampled input contains customer contact details. That makes the classification urgent; it does not establish what South’s terms allow or whether a legal rule was broken. The team records the observed model ID, marks the host unresolved until South confirms it, assigns an owner and a resolution date, and sets privacy to under-review. Because the route carries personal data, the continuation exception does not apply: the team holds the route while it checks the data, host and provider terms.

If the route clears, the owner completes the nine fields and the Model Allocation Mandate, and the routing policy is updated before traffic resumes. If it cannot clear, the team replaces or retires the route and keeps the finding on record. The example illustrates a method and reports no real audit outcome or saving.

How do you build it from evidence rather than memory?

Start with traffic, not recollection: memory misses forgotten routes, inherited services and calls buried inside integrations. Chapter 3’s full worksheet looks back ninety days; chapter 2 gives a thirty-day first pass, which starts the work but does not prove that older or rarer calls are absent.

1. Export observed calls. Pull thirty days of API logs and usage or billing records. List distinct model IDs and endpoints, including low-volume calls, with route and service account where logged. If billing hides the model ID, mark it unresolved instead of guessing.
2. Add what bills miss. Check local serving logs, deployed checkpoints, gateways and third-party integrations. A model on your own hardware may produce no provider bill. An integration may expose only a product name; ask for its underlying model and host.
3. Match calls to rows. For each observed model and material configuration, compare host, mandate and status with the route that called it. List unmatched calls and duplicate aliases. An active row with no calls in the window needs review; silence does not prove retirement.
4. Complete the nine fields for each discovered entry, and keep unresolved fields visible.

Your own logs cannot see a colleague’s personal browser account and may miss calls inside a vendor’s service. The book’s wider Shadow Model Audit runs four moves in fixed order: Detect (API logs and billing, expense and procurement records, aggregate network egress to known model endpoints, an anonymous blame-free survey), Measure (who uses what, for which tasks, and which data classes are leaving), Govern (approved routes for the most common shadow uses, each with an entry and a mandate, then a published approved-model list) and Policy (an acceptable-use rule tied to privacy tiers). Announce the audit first, look at tools and data classes rather than people, and involve whoever owns employee monitoring policy.

How does a registry support routing and an audit?

A routing policy needs eligible model entries. For each request, it checks whether the data class permits the registered host before it compares cost or ability. Then it checks status, mandate, tier and tested abilities against the task, and names the assignment and its fallback. A supplier name settles none of those model-level decisions.

The book grows each row into a Model Allocation Mandate: a one-page authorization that pins the evaluated identity and configuration, capability tier, assigned objective types, cost envelope, latency SLO, privacy tier, escalation path, review cadence and retirement date or trigger. The row makes a model visible. The mandate states the terms on which it may run. A route outside those terms is a visible policy violation rather than invisible drift.

Retirement status changes what the policy may assign and what a later reviewer can reconstruct. Active means in use under a current mandate. Deprecated means being phased out: no new routes, and chapter 11 sets any remaining traffic by the reason for the demotion. Sunset means no traffic, with the entry kept as audit history. Keep dated status changes and the replacement record. A reviewer examining an earlier call needs the model’s status then, not today’s field value.

A register can also fail through lifecycle drift: registered, once-mandated entries stay active long after their routes moved on, and at audit time nobody can tell maintained rows from forgotten ones. The book’s answer is a quarterly owner review of mandate, performance note, retirement status and cost class; an entry whose review lapses is flagged review-overdue and gets no new routing assignments.

Even a well-kept register cannot prove on its own that past calls followed policy. Compare route logs with the model ID, host, status and mandate in force at the time, and check provider terms for data-use questions. Where records are missing, say what cannot be reconstructed. The book’s own evidence ledger grades the registry schema as an authorial design and clears no measured reduction claim for it.

Try this today

Export the last thirty days of model calls and bills your team can reach, plus local serving records and integration usage exports. List each distinct model ID and host that actually appears. Where an integration reveals no model ID, write “unknown” and name who will obtain it; do not infer an endpoint from a vendor invoice.

Match every observed model and material configuration to a registry row and fill the nine fields from the table above. Circle any row with no owner or no mandate: that is your first authority gap to assign and date. Put an unknown privacy class under review and keep production traffic off that route until it is resolved, unless the narrow continuation exception above applies. Extend the window to ninety days when you run the book’s full inventory.

Save the window, source exports, unmatched calls and decision owners. Then ask a teammate to pick one call and find its row, mandate, privacy class and status on the call date. The test passes when all four come from the records. Anything missing is a gap to write down, not to guess.

Cite this:Model registry vs vendor list: know which models run.Len P. van der Hof. https://lenvanderhof.com/en/blog/model-registry-vs-vendor-list/ · Published 1 November 2026.