Ten crates,
one lifecycle.

The four traits

Object-safe so a Pipeline can hold a heterogeneous Vec<Box<dyn …>>. Everything composes because everything speaks the same contract.

• Estimator — fit(&Dataset) → Fitted
• Transformer — transform(&Frame) → Frame
• Predictor — predict(&Frame) → Array
• ProbaPredictor — predict_proba(&Frame) → Frame

Params by path

Pipeline steps are addressable by name, so a search can tune any parameter anywhere in the chain — the scikit-learn "step__param" convention.

// tune the forest inside a 4-step pipeline
grid! {
  "scale__with_mean" => [true, false],
  "rf__max_depth"    => [4, 8, 16],
  "rf__n_trees"      => [100, 300],
}

What it returns

Typed fields you can branch on in code — the HTML report is just one renderer over them.

struct Profile {
  overview:     Overview,        // shape · dtypes · dups · missing
  columns:      Vec<ColumnProfile>, // Numeric|Categorical|Datetime
  missingness:  Missingness,      // nulls + co-missing map
  correlations: CorrMatrix,        // Pearson+Spearman, flagged
  target:       Option<TargetProfile>,
  alerts:       Vec<Alert>,       // the actionable summary
}

Renderers: .to_html(path) · .summary() (text) · .alerts(). Scales past memory — Profile::of also accepts a lazy/streaming frame via polars.

Alerts that map to steps

Because Millwright owns EDA and the pipeline, every data-quality alert names the preprocessing that answers it.

Composition, not configuration

// soft-vote across three different model families → one Predictor
let vote = Voting::soft()
    .add("lr",  LogisticRegression::new())
    .add("rf",  RandomForest::new())
    .add("svc", Svc::rbf());

// stack: a meta-learner on leak-free out-of-fold base predictions
let stack = Stacking::meta(LogisticRegression::new())
    .base("rf",  RandomForest::new())
    .base("knn", Knn::k(15))
    .cv(StratifiedKFold::new(5));       // model-selection-rs

// bag any estimator, fanned out over rayon
let bag = Bagging::of(Svc::rbf()).n_estimators(50).parallel();

// an ensemble IS an estimator — tune a member straight through it
let model = GridSearch::new(stack, grid! { "rf__max_depth" => [8, 16] })
    .cv(StratifiedKFold::new(5)).fit(&train)?;

Free by construction

• No new crate. Voting, stacking, and bagging are pure composition over the four traits — they live in the core and are always on.
• Cross-backend. The unified Predictor is what lets a linfa, a smartcore, and a chronos-ts model vote together — the one thing scikit-learn structurally cannot do.
• Leak-free stacking. Out-of-fold predictions come from the same model-selection-rs CV engine, so the meta-learner never sees a base model's own training rows.
• Still just a model. Ensembles are Estimators — pipeline-able, searchable per member, ONNX-exportable, SHAP-explainable.

Native ensembles — RandomForest, ExtraTrees, GradientBoosting — arrive from the backends as ordinary estimators, tunable and pipeline-able like anything else.

Point it at data, get a pipeline

let result = AutoML::classifier()
    .budget(Budget::trials(200))          // or Budget::minutes(10)
    .metric(Metric::F1)
    .cv(StratifiedKFold::new(5))
    .parallel()                           // search fans out over rayon
    .fit(&train)?;

println!("{}", result.leaderboard());     // ranked pipelines + scores
let best = result.best();                 // a normal, fitted Pipeline

// …and it flows straight into the rest of the lifecycle
best.explain(Explainer::kernel(), &test)?;
best.export_onnx("model.onnx")?;          // deployable — unlike a TPOT object

More than a wrapper

• Seeded, not blind. The search starts from Profile::suggest_pipeline() — EDA's findings prune the space before a single model is fit.
• A deployable artifact. auto-sklearn and TPOT hand you a Python object; Millwright's winner is an ONNX-exportable, servable, monitorable pipeline.
• Its own parts. No separate AutoML crate to trust — it reuses model-selection-rs, hyperopt-rs, and the ensemble core you already use by hand.
• Budgeted & parallel. Cap it by trials or wall-clock; candidates evaluate across cores and the leaderboard fills in live.

The same pipeline, from Python

import millwright as mw

train = mw.Frame.from_pandas(df)          # or from_polars / from_numpy

mw.Profile.of(train).to_html("eda.html")  # same EDA, Rust speed

pipe = (mw.Pipeline()
    .step("impute", mw.SimpleImputer.median())
    .step("scale",  mw.StandardScaler())
    .estimator("rf", mw.RandomForest()))

model = (mw.GridSearch(pipe, {"rf__max_depth": [4, 8, 16]})
    .cv(mw.StratifiedKFold(5))
    .fit(train))

model.explain(mw.Explainer.kernel(), test)  # shap-rs
model.export_onnx("churn.onnx")             # serve anywhere

How it fits

• pyo3 + numpy bindings. pip install millwright; the Frame maps to numpy / pandas / polars, zero-copy where the layout already agrees.
• ONNX both directions. Consume scikit-learn or PyTorch models (exported to ONNX, run through tract) as pipeline steps — and export Millwright pipelines to ONNX for any Python serving stack.
• One codebase, not a fork. The Python API is a thin binding over the same Rust traits — no duplicated logic, no drift. It lives behind the python feature.
• Notebook-native both ways. Usable from Jupyter (Python) for the data-science mainstream, while the guide's evcxr notebooks stay the Rust reference.

Register, serve, roll back

// version a trained pipeline — artifact + ONNX + metrics + lineage
let v = Registry::local("./models")
    .register("churn", &model)?
    .tag("prod");                        // a movable pointer

// serve straight from the registry; the monitor uses the stored reference
Server::from_registry("churn", "prod")
    .with_monitor(DriftMonitor::from_registry(&v))
    .serve("0.0.0.0:8080").await?;

// when drift fires: retrain on the recorded lineage — or revert in one line
Registry::local("./models").rollback("churn", "prod")?;

Closing the loop

• Content-addressed. A version is the hash of its artifact; a tag like prod is just a pointer you can move or revert without copying anything.
• Reproducible. Data hash + config + seed + commit is enough to rebuild the exact model — the thing "it worked yesterday" usually can't.
• Monitored against truth. Drift compares live traffic to the version's own stored training distribution, so alerts mean something.
• The retrain loop. When drift fires, the lineage is right there to retrain on fresh data — and the previous version is one rollback away. That's the loop scikit-learn leaves as homework.

Design commitments

• Thin facade. The core is Frame + four traits. Every engine is an adapter; the god-crate temptation is resisted by construction.
• ONNX is the artifact. The trained thing is portable and backend-agnostic — the training engine is an implementation detail by Phase 4.
• The contract is stable; backends churn. Commit to the traits in 0.1; let young crates evolve behind them. The framework becomes their stability layer.

Non-goals & risks

• Not a numerics kernel. No new linear algebra — it orchestrates proven implementations.
• Not GPU/distributed in v1. CPU + rayon parallelism; scale-out is a later story, flagged not faked.
• Dependency maturity. Ten young single-author crates underneath — mitigated by exact-version pins and a feature-matrix CI, but it is the real risk to own.
• Conversion cost. The two-ndarray bridge copies; measured, with zero-copy fast paths where layout allows.