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.

Publish platform-owned data

ModelRegistry reads external catalogs during synchronization, then publishes a platform-owned catalog with its own organization, model family, model version, provider offering, and pricing records. 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. Read the current external catalogs.
2. Normalize model, provider, organization, release, and capability fields.
3. Replace the publishable catalog in the static output and D1.
4. Review the result through the public pages and the admin dashboard.

This full-replacement approach keeps stale rows from lingering 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.