# Keeping model capabilities and rollout state consistent

Keep advertised model capabilities aligned with replica rollout through feature matrices, readiness checks, tools and schema fixtures, publication and rollback.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/provider-capability-rollout-consistency/
Language: en

A catalog advertises tool support while one replica still uses an older parser. Clients then receive inconsistent behavior depending on the node selected. The problem is not merely a field list: publication and rollout disagree. Providers need checks connecting advertised capabilities to serving instances and a defined configuration version.

## Define the capability source

[OpenAPI](https://spec.openapis.org/oas/v3.1.1.html) describes interfaces, but a documented field does not establish a working capability. A release record should identify whether each claim comes from configuration, test evidence or a managed registry. Automatically generated lists still need their data sources checked.

Do not invent a universal provider-registration schema from a client catalog. Public capabilities and external-platform onboarding belong to different layers. This procedure concerns internal service consistency rather than implying that publishing a file connects a router automatically.

## Link features to implementation

The [vLLM documentation](https://docs.vllm.ai/en/stable/serving/online_serving/) lists interfaces and limitations. Tools and structured output depend on model, engine version, parser and launch settings. One supported=true flag does not explain that combination. Link it to a tested release and supporting fixture.

Where behavior depends on mode, record stream and non-stream separately. Successful ordinary chat does not establish tool calling. Likewise, one simple schema does not prove support for every restriction in a complex document.

## Check participating replicas

Old and new instances can coexist during rollout. Decide whether publishing a new feature before transition completion is allowed. If client traffic can reach an unprepared replica, the advertised state leads reality. A separate route or delayed publication may fit the selected strategy instead.

[Kubernetes readiness](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) can remove unready instances from normal traffic, but it does not independently understand your feature matrix. Application checks must confirm relevant configuration rather than only an open port. Avoid heavy generation on every probe; use bounded control steps.

## Create a release checklist

Include public model ID, internal release, advertised functions, fixture results and replica admission state. Add publication time and change ownership. This explains why a capability became available without reconstructing scattered logs after a complaint.

A negative fixture invokes the capability on a deliberately unprepared test configuration. It verifies that the gate distinguishes states rather than always reporting ready. Run this in isolation instead of intentionally sending real traffic to an incompatible node.

## Preserve rollback behavior

Rolling back can remove a newly advertised capability. Documentation and actual routing should change consistently with compatibility policy. Do not retain a promise merely because the catalog already changed. Handle open operations and new requests separately.

Related material covers the [OpenRouter catalog](/journal/openrouter-model-catalog-api/) and [model canaries](/journal/model-update-canary/). This checks an owned rollout and its description. Passing the checklist establishes neither external approval, universal task quality nor a project's production resources. Store both positive and negative fixture results so later reviewers can distinguish evidence of real feature gating from a release record that only repeats configuration intent.