# ADR: Do not operate a public model catalog feed yet

Status: accepted  
Date: 2026-07-20  
Decision owners: AIWG maintainers  
Related: #1813, #1815, #1816

## Context

AIWG can optionally read a remote `model-catalog.v1.json`, but runtime model
routing does not require one. It already has three stronger local properties:

1. provider inventory prevents probes against merely configured providers;
2. native discovery reports account/runtime-local models where a stable
   provider interface exists;
3. a committed, schema-reviewed catalog is the deterministic offline fallback.

A nightly public feed would be useful only if it had authoritative,
entitlement-neutral upstream data for providers without native enumeration.
No such common source exists. Provider marketing/model pages do not prove CLI
availability, and local account observations must not be generalized.

## Decision

Do not publish or schedule `docs.aiwg.io/data/model-catalog.v1.json` at this
time. Keep remote-feed support operator-configured through `--url` or
`AIWG_MODEL_CATALOG_URL`; AIWG has no built-in production feed URL.

The authoritative sources remain:

- provider-native discovery for local account/runtime observations;
- provider primary documentation for reviewed committed mappings;
- `agentic/code/providers/model-catalog.v1.json` as the release-controlled
  fallback.

Account-scoped or local-runtime discovery output is prohibited from public
catalog publication. It may exist only in the user cache and drift report.

## Operational consequences

- Ordinary `aiwg show`, deployment, and `aiwg models sources` remain offline.
- `aiwg models refresh` performs native discovery and contacts a remote feed
  only when the operator explicitly configures one.
- Missing, invalid, unauthenticated, rate-limited, or unavailable feeds fall
  back to the committed catalog and record the remote error.
- There is no nightly job, feed monitor, rollback procedure, or production URL
  to own while the decision is “do not operate.”
- Catalog changes continue through normal review, schema validation, tests,
  signed commits, and release CI.

## Conditions for reversal

Enabling a feed requires a new reviewed change that provides all of:

1. authoritative upstream sources for every published row;
2. a schema version and per-row provenance/freshness metadata;
3. an explicit filter rejecting `local-account` and `local-runtime` records;
4. generated drift for human review rather than silent canonical mutation;
5. atomic publication, last-known-good rollback, freshness monitoring, and a
   named operational owner;
6. tests proving feed failure cannot change offline deployment behavior.

Until those gates are met, a hosted feed would add operational and
supply-chain risk without improving the truth of account-specific routing.