Model Design
A Model Design captures every decision about what a model learns, separately from the run that trains it: which datasets feed it, how they are split in time, what it predicts, and how it will be scored.
The rule that makes this section load-bearing:
A Pre-training or Fine-tuning run cannot be created without a Published Model Design. There is no path that configures a model inline at run time.
The payoff is reproducibility. Because the design is a versioned object, two runs from the same design are comparable, and a run always points back to the exact design it was built from.
Input and Output designs
The Model Design list has two tabs, because a design describes two different things:
- Input — the data side. Which datasets, over which period, split how.
- Output — the prediction side. Which targets, organized into which tasks, scored with which metrics.
Lifecycle
| Status | Meaning |
|---|---|
| Draft | Editable, not yet usable by a run. |
| Published | Frozen and available to Pre-training and Fine-tuning. |
| Archived | Hidden from new runs; existing runs that used it stay intact. |
Once a design has been used by a training run it becomes immutable — editing it would change what that run was based on. The application will not let you delete it either; Archive it to keep it out of new runs, or Create a copy to carry your changes forward into a new design while the original stays untouched.
Designing the input
Datasets
Only datasets in Ready status are selectable. The picker shows, per dataset, its row count, size, feature count, structure and event-date range, and previews the combined date range and profile coverage of your selection.
Watch for two problems the picker surfaces directly:
- Different date ranges across datasets. If the selected datasets do not cover the same period, some stretches of the timeline have no data in any dataset. If a training or test window lands there, the run fails.
- Coverage gaps. Uncovered periods inside an otherwise valid range may produce no training batches at all.
Data split
Three decisions, each with its own card:
- Training window — the period the model learns from.
- Train / test proportion — how that period divides into training and evaluation.
- Training audience files — the population the run is built over, with a separate audience file for the out-of-sample test window.
The section reports covered period and volume by split as you adjust, and blocks you if a window crosses a data gap.
Designing the output
Facts, targets and tokens
- Model Facts — the feature columns the model reads as context.
- Primary Target — the one thing the model is principally optimized for.
- Auxiliary Targets — additional targets learned alongside it.
- Global output tokens — columns exposed as tokens in the model's output.
Targets are picked with an explicit shift, so a target is always defined relative to the moment of prediction rather than assumed.
Model tasks
Targets are grouped into tasks, in one of two modes:
- Parallel — each target is its own task, learned side by side. Every target needs at least one metric.
- Pipeline — tasks are arranged on a canvas, so one task's output feeds the next.
Metrics
Each task carries the metrics its results are reported against — the built-in set, plus any custom metric you define. A design with no metric enabled anywhere is flagged as an issue: evaluation reports would be meaningless.
Where enhancement fits
Model enhancement is configured here, in the output side of a design, rather than in a separate area of the product. Enhanced predictions appear alongside the design's targets in the Model Output workspace.
Next steps
- Pre-training — train a foundation model from a published design.
- Fine-tuning — adapt an existing model to a task.
- Datasets — get a dataset to Ready so it becomes selectable.