Train models on the tables you already have, or bring your own ONNX. Version them, activate them, score them inside any flow in milliseconds, watch them for drift, and explain every prediction — all under the same governance as everything else in FlowClick.
No notebooks, no separate ML platform, no data leaving the tenant. The model runtime is part of the workflow engine and the job queue you already run on.
A feature spec names the columns, aggregates, and time windows — or start from a template for churn, propensity, lifetime value, or next best offer.
model_train assembles a point-in-time-correct population, runs the leakage guard, trains on the job queue, and checkpoints so a restart resumes rather than restarts.
Metrics, calibration, and a feature schema are recorded on the candidate version. A person activates it — never the platform, never automatically.
The score step returns a prediction in-process in a few milliseconds; score_batch scores a whole population. Use the result in the very next step.
A Model lives inside an application like a table or a flow. Each ModelVersion is immutable once active and carries its artefact, checksum, metrics, feature schema, and calibration — and every state change writes an audit row with a from-state.
Most business ML fails quietly — a leaked feature, an uncalibrated score, a model that drifted six months ago. The runtime guards against each of these by construction.
Training assembles features as of the label time, never after, and rejects a feature that predicts the label too well to be real. A leaking fixture is refused; a clean one passes.
Classifier scores are Platt-calibrated on a held-out split and the Brier improvement is recorded. A survival risk score is not a probability, and the version says so rather than pretending.
Binary classifiers report AUC-ROC, PR-AUC, lift by decile, and positive rate. "Accuracy" appears on no user-facing surface, because on an imbalanced population it means nothing.
Feature drift, coverage drop, and score staleness are measured against the training-time baseline, not a rolling window, and alert edge-triggered — one notification per breach, then resolution.
Route a share of traffic to a challenger version and compare realised performance as outcomes arrive. Routing never changes which version is active — promotion stays a human decision.
explain_score returns per-feature attributions for any prediction, so a support rep, an auditor, or a customer can be told why — not just what.
Model templates bind a known problem to your schema: pick the customer table, the outcome column, and the horizon, and the template generates the feature spec and a candidate model — no weights, no assumptions about your data.
Bring a customer table and an outcome. We'll train a candidate from a template, walk through its metrics, and score it live inside a flow.