> ## Documentation Index
> Fetch the complete documentation index at: https://infercrane.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 0009 qualified support and backend registration

# ADR 0009: Separate qualified support from backend registration

* Status: Accepted
* Date: 2026-08-09

## Context

InferCrane v0.1 is qualified only for vLLM on RunPod, using SkyPilot for elastic capacity and the
RunPod API for provider-native serverless capacity. That release boundary must not become an
architectural dependency. Provider names, runtime defaults, and cleanup allowlists had begun to
leak into generic lifecycle and reconciliation code, making a future integration require edits to
unrelated control-plane logic.

## Decision

Public support policy and executable integration registration are separate concerns. The versioned
support matrix states which cloud, runtime, and compute-mode combinations are qualified for a
release. Composition registers elastic and serverless backends that satisfy narrow lifecycle
contracts. Registration alone never advertises an integration as supported.

An elastic backend has a stable adapter name, cloud, runtime, and `ReplicaProvider`. Registries
resolve provisioning by cloud/runtime and replay or deletion by the adapter identity persisted on
the replica. Direct serverless targets use the same composition principle during reconciliation.
Cleanup queries receive the registered provider identity; persistence contains no provider
allowlist. Runtime identity is preserved from the deployment specification and defaulted only at
an input boundary.

Adding a qualified integration therefore requires an adapter, explicit process composition,
support-matrix qualification, configuration and documentation, and real lifecycle acceptance. It
does not require a provider conditional in the durable workflow.

## Consequences

RunPod and vLLM remain the honest v0.1 support statement while other adapters can be added without
changing lifecycle algorithms. A cloud may register different backends for different runtimes.
Historical replicas with no adapter identity can be replayed only when exactly one backend is
registered, avoiding an unsafe guess in an ambiguous process.

Runtime-specific health and metrics implementations remain adapters. vLLM Router remains the
single router for qualified standalone vLLM replicas; this decision does not introduce a second
general-purpose router or promise arbitrary engines.

## Alternatives

A provider switch inside each workflow was rejected because every integration would fork durable
semantics. Treating every registered adapter as publicly supported was rejected because existence
is not qualification. A plugin framework and dynamic loading were rejected as unnecessary before
there is a second implementation.

## Verification

Registry tests cover independent cloud/runtime resolution, durable adapter lookup, duplicate
registration rejection, and unambiguous legacy replay. Support-policy tests prove the v0.1 matrix
is explicit and that a later release can qualify a new combination without changing validation
logic. Workflow, reconciliation, control API, store, and CLI unit suites cover the composed v0.1
backends.