ADR-0003 — Model Registry and Promotion Strategy¶

Status¶

Accepted

Context¶

Models evolve over time and must be: - evaluated, - compared, - versioned, - and safely deployed.

The serving layer must load models in a stable and auditable way.

Decision¶

We use MLflow Tracking + Model Registry as the single source of truth for trained models.

Key rules: - every training run logs metrics, parameters, and artifacts, - successful models are registered, - serving loads models via stable model_uri, - promotion rules are explicit and documented.

Alternatives Considered¶

• Filesystem-based models: rejected due to lack of traceability.
• Custom registry: rejected due to unnecessary complexity.
• Direct deployment from CI artifacts: rejected due to weak rollback semantics.

Consequences¶

Positive¶

• Clear model lineage and auditability.
• Easy rollback to previous model versions.
• Decoupling between training and serving.

Negative¶

• Requires MLflow infrastructure.
• Registry governance must be maintained.

Rollback / Change Strategy¶

If MLflow becomes a bottleneck, model artifacts can be mirrored to object storage while preserving registry metadata.

References¶

• MLflow documentation