01 / Evidence
Unknown means ineligible.
The public model catalog separates input and output modalities, tasks, feature support, and hard limits. A provider route is eligible only when every requested capability is explicitly supported; unknown evidence is treated as unavailable, never as probable support.
- Images and audio require the matching input modality plus known item, byte, and duration ceilings.
- Tools require chat text output, explicit tool support, and known definition and call ceilings.
- Reasoning, JSON mode, and JSON-schema output are independent feature claims.
02 / Public API
The accepted surface is explicit.
Chat Completions accepts text, streaming, JSON object mode, and bounded function tools with normalized tool-call history and deltas. Responses accepts the text subset, while Embeddings accepts bounded text and returns ordered float vectors. Image and audio inputs, Responses tools, JSON Schema output, and reasoning-effort controls are rejected until their normalized transport and accounting paths are released.
- response_format.type=json_object requires the model's JSON-mode capability.
- Streaming requires explicit streaming support on the selected route.
- Function tools require explicit tool capability plus known definition and call ceilings; parallel calls additionally require parallel-tool evidence.
- Reasoning-token usage is reported even though reasoning controls are not yet accepted.
03 / Enforcement
Selection cannot weaken the request.
OpenWaya derives capability requirements from the validated request and sends that evidence to the private router. The router reauthorizes the organization and key, resolves the active model profile and provider-route limits, and fails closed before provider traffic when any required task, modality, feature, or ceiling is absent.
- Capability checks happen before cost or latency scoring.
- Provider-specific labels never cross the public contract directly.
- Catalog changes are reviewed and versioned before they affect routing.