Training and experiments
Serving somebody else's model is the common case. Building your own on data that cannot leave your boundary is the case that makes a sovereign platform worth having, and it is a different set of machinery.
Building the input
Before a model, a training set. The platform constructs it from catalog assets, which means the training data inherits everything a catalog read carries: workspace scope, classification, row filters, column masks, lineage and cost attribution.
That matters more for training than for a query. A model trained on rows a classification would have masked has absorbed them, and no downstream filter can un-absorb it. Building the training set through the governed read path rather than around it is the only point at which that is preventable.
| Element | What it is |
|---|---|
| Training-set builder | Assembles the input from catalog assets |
| Feature signatures | The declared shape of a feature |
| Feature groups | Reusable groupings of features |
| Materialisations | Feature groups realised for training and serving |
| Synthetic data | Generated data, where real data cannot be used |
Training backends, behind one interface
Training runs on pluggable backends behind a single interface, with scikit-learn, XGBoost and PyTorch trainers registered against it, driven by a training pipeline.
The consequence of the single interface is the governance: whichever backend runs, the work is admitted, metered, audited and placed the same way, so adding a framework does not add a second governance path.
AutoML search sits above them for the cases where the model choice is itself the question.
Experiments and evaluation
| Surface | What it does |
|---|---|
| Experiments | Runs tracked as first-class records |
| Evaluations | Scored outcomes against a model |
| An evaluation harness | For running evaluation systematically rather than ad hoc |
Evaluation being a platform surface rather than a notebook convention is what lets promotion be gated on it rather than on someone's assertion that the model is better.
The export gate
An export gate stands between a trained artifact and it leaving, alongside an artifact packer that produces the packaged form.
This is the same posture as the rest of the platform, applied to the one artifact people most often forget is exfiltration: a trained model is a lossy compression of its training data, and moving one out of a boundary is a data movement event, not a file copy. Gating it is the point.
From trained to served
A trained artifact does not become a served model by being written to a path. It enters the model supply chain: scanned, given provenance, signed, staged, and admitted at load time by a signed-manifest gate. Promotion between environments carries approval and a lease, plus artifact trust and reachability checks, and a column guard and a relocation guard so a model cannot quietly reach data or move to a cell that policy forbids.
Related
- Model operations, the SQL surface over all of this.
- Federated training, training where the data cannot move.
- The model supply chain, what happens to the artifact afterward.
- The compute substrate, the sandbox, metering and audit path training runs on.