No-code changes how a model is assembled. It does not change what makes the model honest. A polished canvas can still leak tomorrow into yesterday, grade against the wrong market, or hide an empty dataset behind a confident card. The right handbook therefore starts with the contract, not the drag handle.
No source-linked training run, timing telemetry, product inventory, price history, or performance ledger is attached, so no speed, availability, cover-rate, or profitability claim is published.
Write the decision before touching the builder
Name the sport, market, decision time, and target in one sentence. “Predict the home team’s final margin using only information available before the selected quote” is a usable contract. “Find winners” is not. The narrower sentence tells you what one row represents and what must be excluded.
Also define the public output. A margin model may produce a fair spread. A binary model may produce a win probability. A player model may produce a distribution for a stat. Do not let the interface switch targets halfway through because a different scoreboard looks better.
Demand real rows and an honest empty state
Every source block should name where the data came from, the fields it contributes, the event key, and the timestamp that makes the row eligible. A schedule row is not a result row. A final box score is not a pregame feature. A market quote captured after kickoff cannot grade a prediction supposedly made before it.
When a join produces no eligible rows, stop. The error should say what is missing and how to cure it: no matching event keys, no pregame quote, no completed target, or no rows inside the requested window. Placeholder games and synthetic prices make the canvas look alive while teaching the model nothing about the real market.
Make leakage difficult to express
The safest visual systems carry time through every connection. A feature should know when it became available. A target should know when it was settled. The training step should reject any feature timestamp that follows the declared decision cutoff.
Rolling features need the same discipline. Calculate them from events that ended before the predicted event. Sort by event time before taking windows. Shift the result so the current game never contributes to its own input. Keep late corrections versioned rather than silently rewriting what a historical bettor could know.
Use types to keep incompatible pieces apart
A schedule, a team feature table, a market quote, a label, and a prediction are different objects. The builder should not connect them merely because they all contain numbers. Typed ports make illegal wiring visibly impossible: event rows feed feature transforms, features feed a model, predictions meet a quote, and completed outcomes feed grading.
At external boundaries, errors should be values with cures. “Quote source unavailable; select another declared source or retry after refresh” is useful. An unhandled exception or a silently empty chart is not.
Start with a baseline you would actually use
A model earns attention by beating a sensible comparison on untouched data. The baseline may be the market, a simple historical mean, or a smaller model with fewer features. Name it before training. Comparing a complex build only with random guessing flatters the build and tells you little.
Keep the first model plain. A small feature set is easier to audit, less likely to memorize noise, and easier to repair when a source changes. Add a feature only when you can state why it should help, when it was known, and how its contribution will be tested.
Split time in the same direction the product runs
Sports arrive in order. Validation should respect that order. Train on earlier events, tune on a later block, and reserve the newest untouched block for the final test. Randomly mixing future and past rows can make season drift, roster changes, and revised data definitions disappear.
The untouched block is not a dashboard you monitor while experimenting. Every glance turns it into tuning data. Choose features and thresholds elsewhere, freeze the build, then open the test once. If the result disappoints, record it. Do not quietly redefine the window.
Grade the prediction the model actually made
A probability model needs probability scoring and calibration. A margin model needs margin error and a declared conversion to a betting decision. A spread record should be reported as ATS wins and losses, percentage, window, and sample size. Player-prop evaluation needs the actual market and settlement rule.
Keep the quote used for every decision. Without it, you can discuss predictive error but not whether a bet was available. Do not substitute a standard price, a closing quote, or a remembered line for the price captured at the decision cutoff.
Separate model quality from a betting rule
The model estimates an outcome. The betting rule decides whether the gap between that estimate and the market is large enough to act. Those layers should be visible separately. Changing a stake rule must not retrain the outcome model, and changing a feature must not quietly alter which quote is used for grading.
Pre-register the minimum edge, maximum staleness, eligible books, and pass conditions. “No bet” is a first-class output. A builder that always produces action is optimizing engagement, not evidence.
Read the result like an auditor
Ask whether every row was eligible, whether duplicates were removed by a declared key, whether missing values were handled consistently, whether the baseline used the same window, and whether the test was truly untouched. Then inspect errors by season, team, market state, and data quality—not to hunt a winning subgroup, but to find where the contract breaks.
Keep the complete record. A filter discovered after results were visible belongs in a new hypothesis and a new future test. It does not rewrite the original score.
Publish an artifact, not a boast
A publishable model needs a version, source manifest, feature list, cutoff rule, target definition, split dates, baseline, test result, failure modes, and a way to reproduce the run. Public picks should point back to that version. If the data later changes, publish a new run instead of mutating the old one.
Use Build to define a model, Workshop to compare controlled variants, and the model leaderboards to inspect records with declared windows and samples. The interfaces are useful only when the evidence survives outside the interface.
A practical first build
Pick one market with stable event keys and a trustworthy historical source. Define the target and cutoff. Add a small group of pregame features. Choose a plain baseline. Train on earlier events, tune without touching the final window, freeze the graph, and run the untouched test.
If the test clears the pre-declared bar, inspect calibration and data-quality slices. If it does not, keep the result and decide whether the hypothesis deserves a new version. Either way, the build produced knowledge. The failed run is more valuable than a synthetic winner.
What to watch before publishing
What to watch: the first clean run whose named sources produce eligible pregame rows, whose untouched window remains sealed, and whose artifact reproduces from the recorded version. Until that run exists, the builder has a workflow, not a betting result.
