Product

Everything between a training run and a model people rely on

Machine learning work has five stages: prepare training data, train, evaluate, deploy, and keep checking accuracy. maclnote covers all five in the notebook where you already work. Below is what each part does, with the churn model from the screenshots as the running example.

Notebooks

Train on real GPUs, in the notebook you already have

Open your existing .ipynb files unchanged. Attach a GPU when it is time to train and release it when the run finishes, so nobody pays for an idle GPU overnight. Two people can work in the same notebook at once, which is how a feature engineering idea and a model change get tried in the same afternoon rather than in two branches that never merge.

  • Any Python framework. PyTorch, TensorFlow, scikit-learn, XGBoost, LightGBM, Hugging Face and JAX all work unchanged; so do your Jupyter extensions.
  • GPUs by the minute. From a single T4 for a quick fit to multi-GPU nodes for fine-tuning a language model, with automatic shutdown when training stops.
  • Pinned environments. Each project pins its package versions, and every training run records the exact versions it used, so a result from March still runs in September.
  • Work together on one model. Live co-editing with comments on individual cells: point at the exact line where the leakage is.
experiments/churn-model-v3.ipynb · GPU A10 · 2 editors
# nothing to import for tracking; the notebook is already tracked
model = GradientBoostingClassifier(
    n_estimators=400, learning_rate=0.05, max_depth=4)
model.fit(X_train, y_train)

auc = roc_auc_score(y_val, model.predict_proba(X_val)[:, 1])
print(f"val_auc={auc:.4f}")

# → run #42 · val_auc 0.9127 · 38 s · dataset customers@v17
Experiment tracking

Every training run recorded, without changing your code

When a cell calls fit() or runs a training loop, maclnote records what a careful data scientist would write down and usually does not: every hyperparameter read from the model object, the training and validation metrics per epoch or per fold, the confusion matrix and ROC curve, feature importances, the random seed, the code as it was at that moment, and the version of the training data. Two hundred runs later, you can sort by validation AUC and see exactly what separated the top two.

  • Hyperparameters and metrics, automatically, for scikit-learn, PyTorch, TensorFlow, XGBoost, LightGBM, CatBoost and Hugging Face. Anything else through one call: mn.log(val_auc=0.91).
  • Learning curves as they train. Loss and metrics per epoch stream to the run page live, so you see overfitting start rather than discovering it after 200 epochs.
  • Compare any two runs on hyperparameters, metrics, the code diff and the training data version, side by side.
  • Hyperparameter sweeps launched from a cell: grid, random or Bayesian search, run in parallel on GPUs and recorded as one group.
runs · churn-model · sorted by val_auc
Runlrdepthtreesdataval_auc
#420.054400v170.9127
#410.056400v170.9081
#400.104200v170.9044
#390.104200v160.8962
#380.303100v160.8815
Data

Every model knows exactly what it was trained on

When a notebook reads a table, a bucket or a file to build a training set, maclnote fingerprints the rows and columns it read and stores a versioned snapshot or pointer. The training run records that version, along with the train, validation and test split. A year later you can retrain on the same rows, and when a deployed model makes a strange prediction you can walk back to the examples it learned from.

  • Snapshot or reference. Small training sets are copied; for large ones, the query and partition fingerprints are stored so the same rows can be fetched again.
  • Feature statistics per version. Means, distributions, null rates and category counts for every column, which is the baseline drift monitoring compares against later.
  • Split recorded. Which rows were train, validation and test, so a held-out score means the same thing to everyone.
  • Lineage on one page from the source table, to the training set version, to the run, to the approved model, to the prediction API.
lineage · endpoint churn-prod · v3
  • sourcewarehouse.crm.customers · partition 2026-09-01
  • datasetcustomers@v17 · 1,204,318 rows · 41 columns · schema hash 9f3a…
  • run#42 · notebook churn-model-v3.ipynb @ commit 4c1e7 · env py3.11-sklearn1.5
  • modelchurn-model v3 · registered by Data Science · approved by Risk
  • endpointchurn-prod · deployed 09:14 · 100% traffic · rollback target v2
Registry & deployment

Evaluate candidates, approve one, deploy it

When a run is good enough to consider for production, promote it to a candidate model. maclnote generates an evaluation report: held-out metrics, calibration, accuracy per customer segment, and how it compares with the model currently deployed. A reviewer sees the report, the training data version and the code on one page and approves it there. Then one click deploys it as a prediction API or a scheduled scoring job, with the previous version kept ready for rollback.

  • Evaluation reports generated from the run: metrics on the held-out split, calibration curve, per-segment accuracy, and a diff against the current production model.
  • Required reviewers per project or model stage, with sign-off recorded in the audit log.
  • Prediction APIs that scale with traffic, log every request and response, and report latency and throughput per model version.
  • Batch scoring jobs on a schedule, writing predictions back to your warehouse.
  • Shadow and canary deployments to compare a new model against the live one on real traffic before it takes over, and a rollback that takes seconds.
endpoint · churn-prod
StatusHealthy · v3
p95 latency42 ms
Requests / day1.8M
curl -X POST https://api.maclnote.com/v1/endpoints/churn-prod/predict \
  -H "Authorization: Bearer $MACLNOTE_TOKEN" \
  -d '{"tenure_months": 14, "plan": "pro", "tickets_90d": 3}'

→ {"churn_probability": 0.71, "model_version": "v3", "request_id": "r_8f2…"}
Monitoring

Know how accurate the model still is

A model is only as good as the data it sees today looks like the data it trained on. Every deployed model logs its inputs and predictions, and each night maclnote compares the last day's feature distributions with the training set version, feature by feature, using the population stability index and Kolmogorov–Smirnov statistics. It also tracks null rates and categories the model never saw in training. When the true labels arrive, days or weeks later, accuracy, precision, recall and AUC are computed automatically and plotted next to the drift history, so you can see whether the drift actually hurt.

  • Feature and prediction drift with alert thresholds calibrated on your own quiet weeks, not a textbook constant.
  • Data quality checks for nulls, out-of-range values, schema changes and categories unseen in training.
  • Accuracy from real labels, joined automatically when ground truth lands in your warehouse, and broken down by segment.
  • Retraining on a trigger that opens a recorded training run on the latest data version when drift or accuracy crosses a line you set.
monitoring · churn-prod · last 14 days
Top drifttickets_90dPSI 0.27
Null rate Δ+0.3%
Unseen categories2
AI assistant

An assistant that has read your experiments

The maclnote assistant answers from your notebooks, training runs, datasets and deployed models, not from the internet. Ask why run #42 beat run #41 and it diffs the hyperparameters and the code and reads the learning curves. Ask it to write the next cell and it uses your real column names and the libraries pinned in your project. Ask what changed in the churn model since last month and it answers from the run history, with links to every run it cites.

  • Answers that cite the runs, notebook cells and training data versions they came from.
  • Explains learning curves: why validation loss started climbing at epoch 12, and which earlier run avoided it.
  • Writes the next cell against your actual feature names, split variables and pinned library versions.
  • Your data trains nothing. Use our model keys or your own; turn the assistant off entirely if you prefer.
assistant · churn-model
Why did run #42 beat #41?
The only parameter that changed was max_depth, 6 → 4. Both runs used customers@v17 and the same code. Validation AUC rose from 0.9081 to 0.9127 while training AUC fell from 0.987 to 0.951, which points to reduced overfitting. Runs #36–#38 at depth 3 scored lower, so depth 4 looks like the sweet spot on this data version.
Sources: run #41, run #42, dataset customers@v17

See it on a model you are actually training

Bring a notebook to a 30-minute call. We will train it with the run recorded, compare two configurations, and deploy the better one as a prediction API, live.