Live is a product state
A sports model can be running continuously and still be unsuitable for use. Its process may be healthy while its market mapping is wrong, its inputs are stale or its latest candidate has never passed a promotion review. The interesting engineering begins when the system has to represent those distinctions clearly enough for an operator to act on them.
The WNBA work has developed into a production-oriented monorepo covering pregame moneyline collection, modelling, manual advisory output, partner delivery, data quality and operations. The advisory surface is read-only. It does not place real-money orders. That boundary is a deliberate part of the product: a model can supply a qualified recommendation without acquiring authority to execute it.
My contribution spans the research workflow and the operating system around it. The work includes chronological evaluation, model promotion, a Rust inference path, scheduled maintenance and the documentation needed to make the pieces operable together. The goal is to make a recommendation traceable to the data and model that produced it, and to make a missing recommendation understandable.
This article follows the earlier WNBA shadow-model case study. That piece records a historical portfolio of candidates and evaluation coverage. Here the focus is the newer operating architecture, including the August move of scheduled retuning and promotion into Rust. It is not an updated performance claim or a statement that every research candidate is ready for use.
Put everything on the same clock
Time is part of the model contract. A forecast made before a game must use information that existed at the chosen prediction point. Market quotes, fixtures and features all need to refer to that same point. Otherwise a pipeline can silently compare an early model with a later market, or train on information that would not have been available when the advice was needed.
The documented production recipe uses a fixed pregame cutoff and promoted heads associated with specific market lanes. It restricts the permitted features and retains identities for the model and input contract. The public lesson is the consistency of that arrangement: collection, training, evaluation and inference must agree on what the model was allowed to know.
Historical reconstructed data and executable live quotes serve different purposes. A reconstructed tape can support research, but it cannot establish that the same quote was available for a real transaction. The distinction needs to survive into evaluation and documentation. An impressive retrospective result is not enough if the live system encounters a different data product.
I also want the market comparator to remain visible. The model is not evaluated in an empty room. It has to justify its contribution relative to information already embedded in market prices, with proper scoring measures and calibration alongside operational coverage. That makes an unexciting result useful: it can tell us that a candidate has not earned promotion, even when its absolute accuracy looks respectable.
Build a repeatable operating cycle
The core loop starts with collection and integrity checks. Features are built under a defined time boundary, the promoted model produces its output and the advisory layer checks whether the result is usable. Outcomes arrive later and feed evaluation. Research can propose a successor, but the currently running model should not change simply because a training job finished.
The model card describes a frozen recipe before an evaluation cycle, followed by scoring after that cycle closes and refitting for the next round. That separation matters because changing a recipe after seeing its outcomes changes the meaning of the evidence. A successor can be promising without being treated as if it had already predicted the period that inspired it.
Scheduled retuning makes this a reliability problem as well as a statistical one. Jobs can fail, data can arrive late and artifacts can be inaccessible to a consumer even when training succeeded. The August changes included keeping model artifacts readable by cold synchronisation and documenting direct deployment. These are small details with large practical consequences: the next process needs the exact object the previous process intended to publish.
A repeatable loop therefore needs both scientific and operational receipts. Scientific receipts explain the training window, evaluation and candidate identity. Operational receipts explain whether the scheduled work actually ran, which artifact reached inference and whether the output remained fresh. Neither set replaces the other.
Make “no advice” a useful answer
The advisory layer can return NO_ADVICE when the data is stale, integrity checks fail or the model is not promoted. That state is part of the interface, not an exception that should be disguised as a missing cell. For an operator, an explicit reason is more useful than a probability with a small warning somewhere else on the page.
A public-safe interface extract below shows the distinctions the workflow needs to communicate. It is a schematic of the documented states, not a live screen or a current health report. Its purpose is to show how a compact interface can make authority and evidence visible without publishing private model outputs.
The same logic applies to monitoring. A running service, a recent data observation and an approved model are separate facts. Combining them into one green light removes the information the operator needs when something goes wrong. A useful surface lets someone see which layer is healthy and which condition is preventing output.
This is where the product and research responsibilities meet. The research team defines what evidence is sufficient. Engineering makes that evidence durable and accessible. The interface turns it into an understandable state. If those responsibilities are left implicit, the final user ends up making an undocumented interpretation of a technical status field.
Make the handover boring
The runtime uses Rust for collection and model writing, with CPU inference and a private read-only query API. Offline training remains a separate workflow, including bounded Python-based research where that tooling fits. The language boundary follows the job: a reliable runtime has different constraints from exploratory training. What matters is that the artifacts and contracts agree across it.
The repository also carries database modelling, operational runbooks, rollback procedures and model documentation. Those are part of the deliverable. A model whose author has to explain its state in a chat every morning has not really completed the handover. The operating system should retain enough context for another person to identify the active model, inspect its inputs and follow the recovery path.
Rust-native quarter-boundary backtesting extends the research surface, but it remains a separate research capability. Its replay rules and walk-forward evaluation do not automatically qualify it for the pregame advisory path. Keeping those identities distinct allows research to advance without quietly widening the authority of the existing product.
That separation is useful for prioritisation too. A new model experiment and a broken artifact handover are not interchangeable tasks. One may improve a future forecast; the other prevents the current system from operating as designed. A leader needs enough visibility to prioritise both kinds of work on their actual consequences, rather than on which one makes a more interesting demonstration.
The cross-sport control-plane work develops this further. Shared monitoring and documentation reduce repeated infrastructure work, while the WNBA repository retains responsibility for its own models, data contracts and release behaviour.
Judge the complete system
A useful evaluation combines several views. Proper scoring measures tell us about probability quality. Calibration asks whether stated confidence matches observed frequency. Coverage and timeliness tell us whether the system supplies an answer when required. Stability and operational incidents tell us how much intervention that answer costs. None is a substitute for all the others.
I would not turn that list into a single blended score. A high-quality model with stale input needs attention for a different reason from a dependable pipeline carrying a weak model. Keeping the dimensions distinct makes the next action clearer and preserves accountability for the right part of the system.
The next development work should be assessed through fresh, identified forward periods and the same market and data boundaries the product actually uses. New research branches need their own acceptance evidence. Operational improvements should show that schedules, artifacts and recovery behave as intended. Public performance claims would require a separately reviewed, dated result set; this article does not infer them from architecture or deployment.
The achievement here is a more complete path from research to usable advice. A prediction can be traced, withheld, evaluated and replaced deliberately. That is the difference between showing that a model runs and building something another person can responsibly operate.
It also changes how progress is communicated. A successful release can mean that a formerly manual task is now repeatable, that a failed job is visible, or that an operator can distinguish a missing quote from an unapproved head. Those improvements are not proxies for predictive skill. They are valuable product outcomes in their own right, and they create the conditions in which future research can be evaluated fairly.
Evidence: WNBA model card, architecture and operations documentation, plus the 25 August 2026 runtime and scheduling changes. These are dated implementation facts, not a live health probe or a claim of automated trading.