Status: ⛔ Superseded by
ADR-009 (model
lifecycle moves to a ModelDeployment CRD + controller; Helm's role shrinks
to installing the controller) · Date: 2026-07-31 (team meeting; recorded
2026-08-03) · Deciders: Ronen, Michael, Phil, Dmitrii
Superseded — but it did its job
This was always an explicitly temporary MVP choice, taken while the
orchestration question was still open
(TKF-61). It remains the accurate
description of how the MVP ships today, and the multi-model lifecycle
semantics it demanded were proven at the Helm layer before anything depended
on them — the chart's validation rules port directly into the controller's
admission webhook. The long-term model-management design is
ADR-009.
Customers will want models added, removed, upgraded and routed-to without
redeploying the world — and eventually through an admin UI, because the
person who decides which models exist will stop being the person who runs
Helm. Building that UI first means building a second configuration surface
before the underlying operations are proven, and a dynamic-orchestration
layer (llm-d / Dynamo / KServe) is still under evaluation
(TKF-61).
Model-management capabilities land in Helm first. MVP phase 2 is
entirely Helm-managed: multi-model serving
(TKF-59 /
TKF-60) and external
OpenAI-compatible backends
(TKF-62) — roughly three values
lines per model, with the lifecycle guarantee that changing one model never
disrupts the others.
The admin UI is deliberately MVP phase 3
(TKF-53): it is a lot of
complexity, and when it comes it generates the same operations Helm
performs (or drives the orchestrator chosen in TKF-61). The UI never
becomes a second source of truth beside Helm.
helm upgrade for model changes. Acceptable while