When you're building a model in Pecan, you don't have to wait until the very end to see if you're on the right track. Draft models let you train a fast, lightweight version of your model as soon as your core set and at least one attribute are in place - so you can catch problems and get a feel for how things are going long before you commit to a full production run.
What a Draft Model Is
A draft model is a quick training run on your current core set and attributes. It uses the same modeling approach under the hood, but it's built to be fast, not final - it skips some of the deeper processing a production model goes through, so you get results back in a fraction of the time.
Before you can train one, you'll need your core set queries set up and at least one attribute table added - draft models train on whatever setup you have at the time.
Since draft models are so fast, it's worth taking advantage of that speed by making small changes and seeing their impact - for example, adding one attribute table at a time and training a draft after each, rather than adding several at once. That way, if something like leakage shows up, it's much easier to tell which change caused it.
You can start a draft training run in two ways:
Click Train Model in the top right corner and choose Draft Model from the dropdown.
Or just ask Pecan's AI Assistant to train a draft for you - it can kick off draft training directly in the conversation. (Production/final model training is different - it always has to be started from the Train Model button, the assistant can't initiate it for you.)
Either way, by default Pecan requires your dataset validations to have passed before training. If they haven't, the assistant will run them for you or point you to fix what's flagged. The one exception: if you explicitly ask to train a draft anyway, despite a failed validation, Pecan will let you - a draft can still be useful for exploration even with an open issue - but it won't do this unless you ask for it directly.
Why Draft Models Are Useful
Draft models exist to shorten the feedback loop while you're building. Instead of setting up your core set and attributes, waiting for a full training run, and only then discovering something's off, you can check your work as you go:
Catch structural issues early - things like data leakage, an attribute table that's too thin, or a label that behaves suspiciously across time are much cheaper to fix before a full production run than after.
See the effect of changes quickly - added a new attribute table? Changed how you're filtering your core set? A draft model shows you the impact in minutes, not in a long training cycle.
Build confidence before you commit - by the time you're ready for a production model, you've already worked out most of the kinks.
How to Use Draft Models Well
The best way to work with draft models is iteratively:
Set up your core set and add your first attribute.
Train a draft model (via the Train Model button, or by asking the assistant).
Review the results - fix anything the health checks flag, then add the next attribute based on what you learn.
Train another draft. Repeat, one attribute at a time, until things look healthy and stable.
Each draft gets a version number, so as you iterate you're building a track record you can look back on or return to. You can also rename any version (via the three-dot menu) - handy for labeling what changed, like "added purchase history attribute," so you can tell your versions apart at a glance later.
A note on accuracy: the accuracy number you see on a draft won't match what your final production model achieves - the two are built differently, so treat the specific score as a rough indicator, not a prediction. That said, watching the trend across your iterations is meaningful: if your accuracy is climbing as you refine your attributes, that's a genuine sign you're moving in the right direction. The mistake to avoid is fixating on a single draft's score as if it tells you exactly what your production model will hit.
Health Checks on Draft Models
Every draft model comes with its own set of health checks - built specifically for draft training, and separate from the checks you'll see later on a production model's evaluation dashboard. These checks look for things like:
Signs of data leakage (a column giving away the answer it shouldn't have access to)
Whether you have enough data - too few entities or too few attributes to work with
Whether your model is relying too heavily on one single feature
Overfitting - the model performing much better on training data than on new data
Signs that your label behaves inconsistently across time (label drift)
If a check flags something, don't ignore it - these are exactly the kinds of issues that are cheap to fix now and expensive to discover after a full production train.
Where to Find Your Draft Models
Next to the Notebook tab, you'll find a Draft Models tab listing every version you've trained (V1, V2, V3...), each with its execution time and headline metrics (like precision, recall, and test set label distribution), plus a summary of how many health checks it passed - a colored indicator next to the summary gives you an at-a-glance signal of whether everything looks good.
Click into a version to see the full picture: detailed explanations for each health check (including suggested fixes, like a recommended start date if label drift is detected), a classification overview chart, your top AI-generated features and their impact, how your target behaves over time, and a breakdown of the train/test data split.
Each version also has a three-dot menu where you can:
Restore that version (see below)
View queries - see the exact setup that produced that version
Rename the version for your own reference
Restoring a Previous Version
Since every draft you train gets saved as a version, you can go back to an earlier one if a later change didn't work out the way you hoped - for example, if you added an attribute and your results got worse, or you want to compare two different approaches side by side.
You can restore a version two ways: ask the assistant directly (it won't suggest this on its own, so say so explicitly if that's what you want), or use the three-dot menu on that version in the Draft Models tab and select Restore.
Restoring brings your queries and setup back to match that version. From there, it's the same as any other setup change: rerun your queries and validations before training again - the assistant can handle rerunning the queries for you if you ask.
Common Pitfalls to Avoid
Treating draft accuracy as your final number. It's a signal for direction and issue detection, not a preview of your production model's performance.
Ignoring failed health checks because the draft "looks fine otherwise." These checks exist because a model can look healthy on the surface while having a real underlying problem.
Training against a dataset that's far too large. Draft models are built for fast iteration - if your dataset is very large, you may hit a size limit and see an error. If that happens, try narrowing your core set or attribute scope for the draft stage.
When You're Ready for Full Training
Once your draft models are coming back healthy - checks are passing, your setup feels stable, and you've iterated enough that further attribute changes aren't moving the needle much - that's your signal to move on to a full Production Model training run.
Related article: