fit. predict.
serve. watch.

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 — bootstrap resamples fit in parallel, then aggregate
let bag = Bagging::of(Svc::rbf()).n_estimators(50);

// boost weak stumps — SAMME adaptive boosting
let boost = Boosting::of(RandomForest::new().max_depth(1)).n_estimators(100);

// 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_pipeline();         // the winning Pipeline (if not an ensemble)

// …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_numpy / from_rows / a mw.Table
mw.Profile.of(train).to_html("eda.html")     # automated EDA, in Rust

pipe = (mw.Pipeline()
    .step("scale", mw.StandardScaler())
    .estimator("rf", mw.RandomForest(n_trees=200, max_depth=8)))

pipe.fit(train, y_train)
pipe.evaluate(test, y_test)                  # {"accuracy": ..., "f1": ...}
pipe.explain(test)                           # SHAP feature ranking (shap-rs)
pipe.export_onnx("churn.onnx")               # one portable ONNX artifact

How it fits

• pyo3 bindings. pip install millwright — a Pythonic pipeline over the Rust core, shipped as an abi3 wheel. Reads numpy arrays and pandas DataFrames directly.
• The whole lifecycle. Dtype-aware EDA (mw.Table / mw.Profile), grid + stratified-CV search (mw.GridSearch), SHAP (explain) and ONNX export — the same engines as Rust, in one wheel.
• ONNX both directions. Export a Millwright pipeline to ONNX for any serving stack — and consume a scikit-learn / PyTorch model (exported to ONNX, run through tract) as a pipeline step via mw.OnnxModel.
• One codebase, not a fork. The Python API is a thin binding over the same Rust types — no duplicated logic, no drift. It lives behind the python feature.

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.