One team can ship a model by hand. Thirty cannot. Rollback on a shared serving tier is either one command for every team on it or an afternoon of archaeology for one, and which of those you have is a property of the platform rather than of any model.
This reference sets out twenty-eight numbered controls across seven families: reproducible training, registry mechanics, the pinned release unit, serving capacity, routing, observability and tenancy. Each names what the platform has to provide and the artefact that proves it does.
Each family names what the platform owns and the failure it prevents. These three produce the arguments we are called into most often, and in each case the fix is an object somebody can be shown rather than a policy.
The object evaluated and the object serving are usually assembled separately, so a runtime image moves on its own schedule and behaviour changes with no release to attribute it to. Make the release unit one pinned bundle: registry entry, image digest, inference server version, tokeniser, decoding defaults and resource profile. Rollback is then one command, and the retention window gets drilled rather than assumed.
Teams size against a p50 measured on an idle cluster, the first busy hour arrives, and the figure that moved was queue wait rather than compute. Publish the two separately at p50, p95 and p99 against a stated concurrency. Publish a cold start budget broken into image pull, weights load and cache warm, so a scale-to-zero policy states what the first request after a quiet hour costs.
A platform funded by whichever use case went first and metered by nobody afterwards cannot settle its own arguments. Attribute every request to a tenant at admission and carry it through to accelerator seconds. Enforce quotas per serving class with a declared behaviour on breach, and exercise the isolation bound with a scheduled load test rather than asserting it in a design document.
Entries are written by the pipeline, and the registry refuses an artefact carrying no originating run record. That one rule closes the hand-upload route for every team at the same moment.
Keep previous bundles loadable for a stated period and time a real rollback against it. A window nobody has exercised is a number in a document, not a property of the platform.
Fallback order, timeout and retry budget become declared policy per logical name. A provider deprecation then becomes one platform migration instead of thirty application changes and thirty post-mortems.
Utilisation says something is saturated and never says who saturated it. One trace id from the gateway through admission, queueing, batching and inference resolves a latency complaint to a stage.
MLO-3 and MLO-4, in that order. The release unit decides how long a rollback takes, and the capacity profile decides whether every team on the platform is sizing against a number that means nothing. The registry families are cheaper to fix once those two stop generating incidents.
Possibly, and the test is how many teams rather than how many models. One team shipping two models can hold the lineage in its head. The controls here start paying when a second team depends on a path the first team built, which is the point at which favours stop working.
Most of them, with MLO-5 doing more work. Provider-hosted models sit behind the same gateway and the same registry contract, so a logical name resolves to a pinned bundle whoever runs the weights. Without that, a provider deprecation lands as thirty separate application changes.
Scope. A production catalogue asks whether one system has a rollback artefact, an evaluation suite, a guardrail. This one asks what the platform underneath thirty such systems owes them, so a row only survived if a single team could not satisfy it alone. The two are meant to be read together.
No, deliberately. MLOps and Model Serving Under Regulation maps Article 12 logging, Article 11 documentation, post-market monitoring and the substantial-modification question onto the same pipeline and says what each duty needs it to emit.
This reference is the build. Take the duty map first if your driver is a supervisory deadline.
Platform engineers and the people who fund them. It assumes you own a shared path to production and have to answer for what happens on it, and that your arguments are about rollback windows, latency percentiles and whose batch job moved whose p99 rather than about whether to build a platform.
Drop your details and we'll send MLOps and Model Serving: An Engineering Reference straight to your inbox - no spam, unsubscribe anytime.
Point a two-week engagement at MLO-3 or MLO-4 and you end with a pinned release bundle, a timed rollback drill and capacity profiles measured at the concurrency you actually run. SECTION 7 - FAQ - 5 to 8 questions
Book a serving review