MLOps

Author a gated training pipeline, run it locally, and see exactly which gate stopped it.

Between "the notebook trained something" and "this model is in production" there are questions nothing else in the workspace answers: did the data schema break, did the tests pass, can this run be reproduced, and which of those failed. This hub turns those checks into a run with a verdict, because a gate that cannot stop the pipeline is only a comment.

What you can do

• Lay out a training pipeline as cards in the order the work is done, and run the whole thing on this machine
• Put gates between the stages, such as a schema check, a drift check or a test suite, and have a red one stop the run
• See exactly which gate stopped a run and why, instead of reading back through a log
• Add engines as you need them: DVC for reproduction, pandera for data contracts, Evidently for drift, pytest for tests
• Re-run the pipeline when your data moves, with drift able to trigger the retrain
• Score a model from the predictions it left behind and compare it with the deployed champion on the same rows, without a tracking server
• Deploy a model that passed, only after a person says yes

Getting started

Open MLOps from the activity bar. It opens the pipeline designer: a palette of the steps your installed extensions provide on the left, and the pipeline as cards beside it.

1. Follow NEXT STEP. It reads the workspace and names the one thing that is missing, such as an engine to install, a training script to scaffold, or a gate the pipeline does not have yet. Do the one thing it asks, and it moves on to the next.
2. Build the pipeline. Drag steps from the palette onto the canvas and save. The pipeline is a file in your workspace, so it stays in git and you can edit it by hand at any point. Every write to it waits for your yes.
3. Add a gate before training. For example, install MLOps Data Contracts and use Draft from a dataset… on data you already have. A check that runs after training has protected nothing.
4. Run it with the ▶ button. Every stage is recorded, including the ones that did not get to run.

The ? on the designer's toolbar walks through the whole loop on screen, from data and labels through training and its checks to a shipped model.

What a stopped run looks like

This is the part worth trying. Add a row to your data that breaks the contract, for example an empty value in a required column, and run again. The run stops at the contract, the card names the column and the check that failed, the stages after it are shown as skipped, and NEXT STEP says what to do about it. The record survives a restart, so a run that stopped last night can still be explained this morning.

Requirements

• The desktop app. Engines start local processes, so in a browser a stage is reported as unavailable rather than passed.
• A workspace folder and a Python environment the workspace can see.
• At least one engine or check extension. The hub carries no engine of its own, and when one is missing it tells you which extension to install by name.

A pipeline built from the engines above runs on this machine, and nothing is uploaded.

Good to know

• Only one run at a time. A second run over the same workspace is refused rather than queued, because the two would race on the same cache.
• Re-running on drift is off until you turn it on, so installing a drift check never gives a workspace a pipeline that starts itself.
• A run started by an AI assistant or an MCP client counts as a write, so it goes through the same approval rules as any other change to your workspace.