MLOPS
A pipeline you can read, gated by people
One file declares the stages. Every stage is a gate. Every write waits for a person, and the trail remembers who said yes.
MLOps is the path from data to a production model: validate, test, train, check for drift, measure quality, promote. IVYX makes that path one declarative file, run by the providers you have installed, and records every decision along the way.
Click any block to see what it does. Run the pipeline to watch the order become the flow.
# .punica/mlops.yaml: the whole pipeline, in one file.# Stages run top to bottom; a failing stop-gate ends the run.pipeline.provider: the engine slot
Names the engine that runs the training DAG, here dvc. The hub knows nothing about any one engine; any installed extension that fills the family slot can be named, and an empty value means no engine is bound yet.
The config decides what runs; the catalog decides what's offered
The pipeline is one file
.punica/mlops.yaml names this project's stages, in order, with your comments kept. The wizard and an agent write through the same writer, so the two can never disagree about what the pipeline is.
Every stage is a gate
A stage answers pass or fail, and a failing stop-gate ends the run. The verdict is the provider's word. An answer that cannot be read is a failure, never a quiet pass.
The loop, one step at a time
From the file to a shipped model and its proof. Each card is a step the hub dispatches to a capability; the hub carries no engine of its own. Hover to hold a step, or click a card to jump to it.
.punica/mlops.yaml · the loop
Describe, label, train, gate, ship, prove
Pipeline designer · palette and cards
Describe the pipeline
- A step dragged from the palette becomes a card, and Save writes it to .punica/mlops.yaml in the order the work is done.
- A model can build the pipeline card by card, and a policy rule can hold every write to that file for a person.
The pipeline
Gates are providers you install
The hub knows nothing about these by name; it finds them by shape in the catalog, so a provider shipped next year appears with no edit here.
pandera
the data-contract gate: a schema the dataset must satisfy.
pytest
the test gate: the project's own suite, read from pytest's reports, not its terminal output.
evidently
the drift gate: a statistical comparison of current data against the reference.
DVC
the pipeline engine: it runs the DAG and versions the artifacts.
MLflow
the experiments + registry backend: runs, metrics, model versions and aliases, on MLflow 3 with a managed local server the author starts before the first run.
GTO
the other registry engine: a passing model is promoted by moving a Git tag alias, through the same model-registry hub MLflow answers to.
Governed, not just automated
Every stage runs through the same gateway a person's clicks run through: policy decides, a write waits for approval, and the audit trail keeps the answer. The pipeline cannot do to your project what a person has not approved.
Approval
a require rule holds every write for a person. Run the pipeline and each writing stage asks once: approve, and the run continues; decline, and it stops with the decision on the record.
Audit trail
every run is durable: which stages ran, which passed, which were held for a person and then allowed. Readable months later, not lost when the window closes.
Evidence
from any run you build an evidence package answering five questions: which data, which code, which environment, which gates, who approved. Signed in Studio with a key that never leaves the machine; ivyx evidence verify checks it anywhere.
The trail an approved run leaves
test.pytest.run needs-person A person says yes before anything writes to disk.
test.pytest.run allowed approved once · args a77cf352
mlops.dvc.repro needs-person A person says yes before anything writes to disk.
mlops.dvc.repro allowed approved once · args 44136fa3
granted mlops.model.promote champion → churn v2 by sezginOne process, three surfaces
The same .punica/mlops.yaml, written and read three ways, never a second definition.
The Overview wizard
build the whole pipeline from an empty folder without opening the file: pick the engine, pick the checks, press Create.
The sidebar
run the pipeline, watch each stage pass or stop, and approve a held write in place.
ivyx serve --stdio
an agent over MCP writes the same pipeline file, asks policy explain what a call would get and reads the trail, with every write still held for a person. The run itself happens in Studio or in CI, because the CLI governs and does not execute.
The rules that do not drift
An unreadable verdict is a failure
a gate that answers something the hub cannot read stops the run. A broken gate never waves a bad model through.
The next step is named
ready is the last answer, not the first: the hub checks for a config, an engine, a DAG and a gate in order, and names the first thing that blocks a run.
Governs, not executes
the CLI records and governs; it does not run your training. The desktop runs. The boundary is deliberate.
One file, one writer, two callers
the wizard and the gateway write the pipeline through the same writer, so the GUI reads back exactly what an agent wrote.
The hub has no engine
it dispatches to the providers you installed. What runs is your choice, discovered from the catalog.
The order is the flow
stages run top to bottom as the file lists them. To change the flow, change the file.
Beyond the pipeline
sweeps run DVC's Hydra grid through its queue and the gates run once over the winner; lineage folds the trail and exports to OpenLineage; parameter importance measures which parameter moved a metric; a CI export assembles every installed engine's workflow with the workspace's Python pinned verbatim.
Deliberately outside
orchestration, serving, feature stores, distributed training and live inference monitoring. Your platform does those. IVYX records the part your platform cannot see.