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 lifecycle, one stage at a time
Six stages, in the order a model actually walks them. Each is a capability the hub dispatches to; the hub carries no engine of its own.
01
Data contract
pandera checks the dataset against a schema before anything trains on it. A missing column or a bad type stops the run here.
02
Tests
pytest runs the project's suite. Red tests are a red pipeline, not a broken engine; the run stops before it trains on untested code.
03
Train
the DVC DAG trains the model and records its outputs. Reproducible by construction: same inputs, same model.
04
Drift
evidently compares the current data against the reference. When the share of drifted columns crosses the limit you set, the model is training on a world that changed.
05
Model quality
the trained run's metrics are checked against the bar you set: a threshold such as accuracy ≥ 0.8, the current champion, or a per-slice regression.
06
Promote
a passing model can move an alias, such as champion, in the registry. It is risk: high, so it waits for a person and records who moved it.
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.
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
a run packages into an evidence bundle: the calls, the verdicts, the approvals. One artifact that answers who trained this model and who signed off.
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 builds and runs the same pipeline over MCP, with every write still held for a person and every call still on the trail.
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.