Casebook/Case 01
Data & platform

Michelangelo: one ML platform across the lifecycle

How a shared platform joined data preparation, training, deployment, prediction, and monitoring for many teams.

Reported by the primary sourceFACT LAYER

What we can attribute directly

Uber describes Michelangelo as an internal end-to-end system for building and deploying ML models at scale.

The published architecture includes a feature store, model repository, offline training, online prediction, and monitoring.

Read Uber Engineering — Michelangelo Primary source · last checked 26 Aug 2026
01 · Problem & constraints

The operating envelope

Many teams, heterogeneous use cases, shared infrastructure, and both batch and low-latency prediction paths.

Actors

Model teams, platform owners, operators, downstream product systems, and people affected by decisions.

Evidence

Versioned data, configs, traces, artifacts, deployments, and outcomes aligned on one timeline.

Failure cost

Before a paved road, teams repeat integration work and struggle to reproduce features and models across environments.

02 · Architecture reconstruction

Trace the system before naming the bug.

  1. 01

    Producers emit versioned data or model artifacts.

  2. 02

    A platform validates, computes, stores, schedules, or routes them.

  3. 03

    Training or inference consumes the exact declared version.

  4. 04

    Telemetry joins the decision to system, data, and model identity.

  5. 05

    Operators compare outcomes, stop conditions, and the last known-good path.

03 · Symptoms & investigation

Follow the evidence boundary by boundary.

Symptoms

Before a paved road, teams repeat integration work and struggle to reproduce features and models across environments.

Investigation

Map every artifact boundary: source data → feature computation → training dataset → run → model version → serving endpoint → observed outcome.

DIAGNOSTIC EXERCISE

A prediction regresses after a feature backfill. Which identities must you join to reconstruct the exact online decision?

Open investigation scaffold
  1. Write the earliest known-bad timestamp.
  2. Compare exact identities on either side of that boundary.
  3. Find the smallest affected slice and a known-good counterexample.
  4. Separate mitigation from root-cause confirmation.
04 · Root cause & fix

Repair the contract, not only the symptom.

ROOT CAUSE

Lifecycle components owned in isolation create handoff gaps, skew, and weak lineage.

FIX

Create versioned platform contracts that connect feature definitions, runs, artifacts, deployments, and monitoring.

Rollout

Adopt by one high-value workflow, retain escape hatches, and expand the paved road only after real operating feedback.

05 · Rejected alternatives

Reason about the tempting shortcuts.

  • A universal black-box API that hides every model-specific need.
  • A model registry without reproducible data and feature lineage.
06 · Monitoring after the fix

Make recurrence visible early.

01

Feature freshness and parity

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

02

Prediction latency and volume

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

03

Model outcome quality by version

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

REUSABLE PRODUCTION PATTERN

A useful ML platform is a connected lifecycle, not a pile of independent tools.

Carry this pattern into assignments as a design constraint and into incident reviews as a hypothesis—not as proof about an unpublished system.