Skip to main content
Gateway is not intended to try every model it can discover. It needs reliable information about a particular offering: the model, provider, deployment or account context, protocol and capabilities that will actually be used. A smaller catalogue of well-understood offerings is more useful than a larger list of uncertain names when the application has requirements it cannot safely relax.

​
Capabilities must work together

Imagine a request that requires reasoning and a schema-valid JSON answer. One offering supports JSON-shaped text but not the required schema. Another supports the schema only when reasoning is disabled. A third supports the verified combination. These illustrative offerings are not interchangeable. Checking two separate feature boxes does not establish that the requested combination works. The same reasoning applies to streaming, output limits and allowed data-handling conditions.

​
A fact can be unknown without being false

The supply model distinguishes verified evidence, unverified claims, unknown facts and evidence that a feature is unsupported. If a mandatory capability is unknown, Gateway cannot treat it as supported. It should exclude that candidate before provider execution. This is different from claiming the model definitely lacks the feature: the problem may be insufficient evidence rather than a proven limitation. A verified fact must also be current and applicable. Yesterday’s test of another model revision, endpoint or account does not necessarily establish today’s offering. The freshness policy comes from its owner; this guide does not invent a universal number of days for every capability.

​
From a candidate to usable supply

Supply Qualification gathers the evidence. Registry approves and publishes the catalogue and policy. Gateway validates and consumes the resulting version. These roles need not be separate services. Manual preparation can use the same contract as later automation. Manually entering a candidate is not a shortcut around validation, approval or durable publication.

​
Publication must survive a restart

A catalogue is not published merely because a process changed an in-memory pointer. Its approved records and references must be committed as a coherent version. If publication confirmation is uncertain, the publisher must resolve that original publication rather than announce an uncommitted version as active. Gateway installs a complete compatible snapshot, not a mixture of records from different revisions. A running call keeps the plan and source references it started with. Current revocation and permission checks can still prohibit an effect; a historical pin is not a permanent permission grant.

​
Feedback can narrow selection, not invent approval

Runtime failures can temporarily exclude an offering or trigger review. A recovered connection does not automatically restore an officially retired offering. A single not-found response is not sufficient evidence of permanent model retirement. Likewise, general adapter streaming tests do not replace a probe of the exact offering when live streaming is mandatory. Read Planning a compatible request next. Implementation status distinguishes these design requirements from the real supplier evidence available at the recorded source cut.