# Model catalog: what a platform team should keep in one

URL: https://infro.io/blog/ai-model-catalog
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-19
Last modified: 2026-10-19
Last reviewed: 2026-10-19 (next review due 2026-11-18)
Topic: Security and governance
Format: Guide

> A model catalog is an organization's inventory of the AI models it may use: for each model, the providers that serve it and the id each one expects, its modalities and limits, its reference list rate and your negotiated rate, its lifecycle state and shutdown date, and who is allowed to call it. It differs from an ML model registry, which versions models you train, and from a cloud provider's catalog, which lists what one platform offers rather than what your organization has approved.

Key takeaways:
- A model catalog answers four questions per model: may we use it, where is it served and under which id, what will it cost on our contract, and when does it stop working.
- An ML model registry versions models you train; a cloud catalog lists what one platform offers. Neither says what your organization approved across every provider it uses.
- Lifecycle is per platform: Anthropic, OpenAI and Amazon Bedrock each publish their own states, notice periods and dates for the same family of models.
- A catalog written by hand goes stale within weeks. Feed it from vendor deprecation pages, from each provider key's own model list and from your request data.
- Governance only holds when the catalog is enforced in the request path: allow and block lists checked before a provider is called.

A model catalog is the list a platform team keeps of the AI models its organization may use, and everything needed to use each one safely: which providers serve it and under which id, what it can take and return, what it costs on your contract, when it will stop working, and who is allowed to call it. Without one, those answers live in a wiki page, three SDK config files and somebody's memory of the last vendor email.

This guide covers what an AI model catalog should record, how it differs from an ML model registry and from the catalogs cloud platforms publish, how to keep it current when vendors retire models on their own schedules, and how to make it something the request path enforces rather than a document people consult.

## What is a model catalog?

For a team that consumes models from providers, a model catalog is an inventory with one row per model and one sub-row per place that model is served. It is the source that other systems read: the gateway reads it to decide whether a request is allowed and where it can go, finance reads it to price usage, and the people who own a feature read it to find out that the model they depend on retires in six weeks.

The word is used for three different things, which is where most confusion starts:

|  | ML model registry | Cloud provider catalog | Platform team's model catalog |
| --- | --- | --- | --- |
| Example | MLflow Model Registry | Vertex AI Model Garden, Amazon Bedrock model cards | Your own inventory, enforced by a gateway |
| What it lists | Models you trained | Models one platform offers | Models your organization approved, on every provider it uses |
| Unit of change | A new version from a training run | The platform adding or retiring a model | An approval, a contract, a vendor retirement |
| Lifecycle | Your own stages and aliases | The platform's states and dates | Each provider's dates, per provider |
| Answers "may we call it?" | No | No | Yes |

Table: Three things called a model catalog, and the question only one of them answers.

### Model registry vs model catalog

MLflow describes its registry as a centralized model store, with a set of APIs and a UI, that versions each model registered under a name, attaches mutable aliases such as `champion` to a version, records tags and annotations, and links every version back to the run or notebook that produced it[1]. That is lineage for artefacts your team builds and deploys. A frontier model you call over an API has no training run of yours to link to and no version you control; the vendor decides when a snapshot changes and when it disappears.

If you fine-tune or train models, keep the registry for them. The catalog then points at the registry for those rows and at providers for everything else.

### Cloud catalogs

Cloud platforms publish catalogs of what they host. Google's Model Garden groups Google's own models, partner models such as Anthropic's Claude and Mistral's, and open models that can be run as a managed service or deployed by you[2]. Amazon Bedrock's "Models at a glance" page lists models by provider, with a card per model holding its ids, Regions, modalities and inference parameters[3].

These are the right reference for that platform. They are not an organization's catalog, for two reasons. They list what you *could* use, not what you *approved*. And a team that calls Anthropic's own API, Bedrock and an aggregator ends up with three catalogs, three lifecycle schedules and three spellings of the same model.

## What an AI model catalog should record

A useful entry is short. What matters is that every field has an owner and a source.

| Field | What it holds | Where it comes from |
| --- | --- | --- |
| Canonical id | One name your code and reports use, such as `vendor/model` | You |
| Served by | Each provider that can serve it, and the wire id that provider expects | Provider docs and each key's own model list |
| Modalities and task | Text, image, video, speech, transcription, embeddings; chat, edit, rerank | Vendor model page |
| Limits that change behaviour | Context window, maximum output, parameters the model refuses | Vendor model page, per snapshot |
| Reference list rate | The vendor's published rate, in the vendor's billing unit | Vendor pricing page |
| Negotiated rate | Your contract's rate, per provider where it differs | Your contracts |
| Lifecycle | State, deprecation date, shutdown date, named replacement, per provider | Vendor deprecation pages |
| Access | Which organization, projects and keys may call it | Your approval process |
| Owner and evidence | Who approved it, against which evaluation | You |

Table: The fields of a catalog entry, and the source each must be read from.

Three of these deserve more care than they usually get.

**Wire ids are per provider.** The same model can be addressed by a different string on its vendor's API, on a cloud platform and on an aggregator, and a regional or dated snapshot can add another. A catalog that stores only a marketing name cannot answer "which of our keys can serve this?", and a gateway cannot route on it.

**Two prices, kept apart.** The list rate is reference data: what the vendor publishes. The negotiated rate is what your provider will actually bill you under contract, and it can differ per provider for the same model. Estimates that silently use the list rate drift from the invoice; [negotiated rates vs list price](https://infro.io/blog/negotiated-rates-list-price-drift) walks through every way that happens. Where no rate is known, the honest value is "unpriced", never zero.

**Lifecycle is not one date.** It is a state per provider, covered next.

## Lifecycle: preview, active, deprecated, shut down

Every major provider publishes a lifecycle, and they do not use the same words or the same notice.

- **OpenAI** treats a model as deprecated as soon as a retirement is announced, at which point it receives a shutdown date, after which it can no longer be reached. It commits to at least six months' notice for generally available models, at least three months for specialised variants, and much shorter notice, such as two weeks, for preview models, unless safety or compliance requires faster action[4].
- **Anthropic** uses four states — active, legacy, deprecated and retired — and gives at least 60 days' notice before retiring a publicly released model. Its dates apply to Anthropic-operated platforms; Amazon Bedrock and Google Cloud set their own schedules for the same models[5].
- **Amazon Bedrock**, for models launched from 7 September 2026, uses active, legacy and end-of-life. Most models get a six-month legacy period, some 45 days; once a model is legacy, new customers cannot adopt it and existing customers may lose access after 15 days of inactivity. After end-of-life, requests fail. Bedrock states that its dates may differ from the model provider's own[6].

So the lifecycle field in a catalog is a small table per model: one row per provider, each with its own state and dates. A catalog that records "Claude X retires on date Y" without saying where will be wrong for some of your traffic.

The useful states for a catalog are a superset that maps onto each provider's terms:

1. **Preview**: callable, not approved for production; expect short notice.
2. **Active**: approved and supported.
3. **Deprecated or legacy**: still works; has a shutdown date and, usually, a named replacement. New use is refused.
4. **Shut down**: requests fail at the provider. Your own gateway should refuse them first, with an error that names the replacement.

The per-date view across vendors is maintained in the [AI model deprecation calendar](https://infro.io/blog/ai-model-deprecation-calendar), and the step-by-step move to a replacement is in the [model deprecation migration playbook](https://infro.io/blog/model-deprecation-migration-playbook).

## Keeping the catalog current

A catalog edited by hand is accurate on the day it is written. Three feeds keep it accurate afterwards.

**Vendor lifecycle pages.** Deprecations are announced on pages, not in an API every vendor shares. Someone or something has to read them and write each new date into the catalog with its source. Some APIs help: OpenAI's list-models response now carries a `shutdown_date` per model, null when none is announced[7]; Bedrock exposes a model's state in a `modelLifecycle` field on its model APIs[6].

**Each provider key's own model list.** What a vendor's page says is served and what *your* key can call are different facts. Aggregators move models between groups, accounts are scoped to projects, and access can lapse: Bedrock's own policy says existing customers may lose a legacy model after 15 days without using it[6]. Reading each key's model list on a schedule, and marking a model your key has stopped listing, catches this drift before a user does.

**Your request data.** The catalog says what is approved; traffic says what is used. Join them weekly. A model in traffic and not in the catalog is an unapproved dependency. A deprecated model still in traffic is a migration with a deadline. Anthropic suggests the same audit from its own usage export, broken down by key and model[5].

> **Warning: Do not let the gateway pick a replacement for you**
> When a model shuts down, the tempting fix is to map the old name to the new model inside the gateway, silently. That changes behaviour, cost and output format for every caller without anyone testing it. Refuse the old id with an error that names the replacement, and repoint a route or alias you own only after the replacement has passed the same evaluation the original did.

## Governance: turning the catalog into policy

A catalog that nobody enforces is a recommendation. It becomes policy when the request path checks it before a provider is called.

The simplest enforcement is an allow list per scope — organization, project, key — with block entries for exceptions:

- An organization list sets the outer boundary, for example every model from approved vendors.
- A project list narrows it to what that workload has been evaluated on.
- A key list narrows it again for a single service or environment.
- Block entries remove one model or one vendor even when a broader rule allows it, which is how a deprecated model is cut off on a date.

Two rules keep this manageable. Each scope can only narrow, never widen, what the scope above allows; and a named route or a fallback target must be checked against the same lists, or routing becomes a way around policy. The wider approval process — who proposes a model, what evidence is required, how exceptions expire — is covered in [model access governance](https://infro.io/blog/model-access-governance).

Approval should also record *why*. "Approved for summarisation in project X after an evaluation on 200 recorded tickets" is something a reviewer can check and re-run when the model changes; "approved" is not.

## A minimal checklist

- [ ] One canonical id per model, with the wire id each provider expects.
- [ ] List rate and negotiated rate stored separately; unknown rates recorded as unpriced.
- [ ] Lifecycle state and dates recorded per provider, each with its source page.
- [ ] A scheduled read of every provider key's model list, with drift flagged.
- [ ] A weekly join of request data against the catalog.
- [ ] Allow and block lists at organization, project and key, enforced before the provider call.
- [ ] Shut-down models refused with the replacement named, never swapped.

## How INFRO keeps the catalog in the request path

INFRO is a BYOK control plane: you connect your own provider accounts, and the catalog it keeps is reference data about the models those accounts can serve, not a price list. The public [model directory](https://infro.io/models) lists those models with each vendor's published list rate and the provider kinds that serve them in production, with search, filters and sorting. Inside an organization, `GET /v1/models` returns only what the calling key can reach: models served by an enabled connection in the key's environment and permitted by every allowlist that applies.

The feeds described above are built in. INFRO records each vendor's deprecations and shutdown dates; before the shutdown it marks the model in the console and sends a `model.retiring` alert to organizations that sent it in the last 30 days, and from the shutdown date it refuses the model before any provider call with `model_shut_down`, naming the vendor's replacement. It never answers with a different model on your behalf; to keep an old name working you point a [route](https://infro.io/docs/routes) at the replacement ([model lifecycle](https://infro.io/docs/models)). It reads each connected key's own model list every three hours and stops offering a model the key has stopped listing, with the date ([provider connections](https://infro.io/docs/providers)). [Model allowlists](https://infro.io/docs/org/model-allowlists) apply at organization, project and key, with `!` entries to block a model or a vendor. Estimated cost uses the rates in your contracts before the list rate when you enter them, from the Team plan.

## Questions

### Is a model catalog the same as a model registry?

No. A model registry such as MLflow's stores versions of models your own team trains, with lineage back to the run that produced each one. A model catalog for a platform team covers models you consume from providers: which are approved, which provider ids they map to, their rates and their retirement dates. Teams that both train and consume models usually need both.

### Can I use my cloud provider's model catalog as our enterprise model catalog?

Only if every model call goes through that one platform. A cloud catalog lists what that platform offers and its own lifecycle dates. It does not record what your organization approved, models you call on other providers, or the rates in your contracts.

### What should happen when a model in the catalog reaches its shutdown date?

Requests for it should fail before any provider call with an error that names the replacement, and nothing should swap the model silently. The catalog entry moves to shut down, stays in the history for reporting, and the route or alias that pointed at it is repointed after the replacement has been tested.

### How often should a model catalog be reviewed?

Lifecycle data should be read continuously from vendor deprecation pages and provider model lists, because preview models can be retired on two weeks' notice. Approval decisions and negotiated rates are commonly reviewed on a fixed cycle, such as monthly, and whenever a contract changes.

## Sources

1. MLflow Model Registry — MLflow. https://mlflow.org/docs/latest/ml/model-registry/ (accessed 2026-10-19)
2. Overview of Model Garden — Google Cloud. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/model-garden/explore-models (accessed 2026-10-19)
3. Models at a glance — Amazon Web Services. https://docs.aws.amazon.com/bedrock/latest/userguide/model-cards.html (accessed 2026-10-19)
4. Deprecations — OpenAI. https://developers.openai.com/api/docs/deprecations (accessed 2026-10-19)
5. Model deprecations — Anthropic. https://platform.claude.com/docs/en/about-claude/model-deprecations (accessed 2026-10-19)
6. Model lifecycle — Amazon Web Services. https://docs.aws.amazon.com/bedrock/latest/userguide/model-lifecycle.html (accessed 2026-10-19)
7. List models — API reference — OpenAI. https://developers.openai.com/api/reference/resources/models/methods/list (accessed 2026-10-19)