Keeping a model catalog current

Model catalogs change quickly: providers add releases, rename offerings, change availability, and publish new capability details. A public directory needs a workflow that absorbs those changes without making its own identity unstable.

Manage platform-owned data

ModelRegistry stores its organization, model family, model version, provider offering, and pricing records directly in D1. External provider IDs remain useful mapping data, but they do not become the primary key of the public product.

The current data flow is intentionally simple:

1. Enter or update catalog facts through the admin dashboard.
2. Store model, provider, organization, release, and capability fields as structured D1 records.
3. Let public pages and APIs read the latest database records directly.
4. Review the result through the public pages and the admin dashboard.

Administrators can mark records as deprecated or unavailable after a provider removes or renames an offering. Source-observation storage and Deployment records are not part of the current backend model.

The next quality boundary

The catalog already supports browsing, filtering, and side-by-side comparison. Query APIs, MCP access, stronger data-quality checks, and recommendation features are the next layer of work. They can be added on top of a stable catalog rather than compensating for inconsistent identities.

Explore the organization directory and provider directory to see the published catalog.