How the Data Stays Correct

Every model on this site is only as trustworthy as the data underneath it. The least glamorous and most important system at Oraca is the one that keeps that data correct: a single ordered job that, every night, ingests the day's football, recomputes every derived number in the right order, and refuses to finish if a correctness check fails. A broken night is loud, not silent.

In one line: ratings, forecasts, fits and recommendations are all rebuilt from the raw data on a fixed nightly schedule, in a verified dependency order, and the run ends by checking its own output — it exits in failure on a duplicate, a broken reference, or a drop in coverage, so wrong data sets off an alarm instead of quietly reaching a screen.

Why one ordered job

The surfaces in this section depend on each other: a player's rating feeds his projection; his projection and forecast feed his fit; his fit and your network feed the recommendation. If those pieces were recomputed on independent timers, a small change in timing could leave one step running on yesterday's inputs — computing today's recommendation from a rating that hadn't been refreshed yet. So the order is encoded, not timed: one master sequence runs ingest, then recomputes the dozens of derived models in a dependency order that is itself verified to be valid — every input is guaranteed to be rebuilt before anything that reads it.

Fatal core, tolerant edges

Not every data source matters equally on a given night, so the run distinguishes them. The core match data is fatal: if it fails to ingest, the run stops before recomputing anything, because rebuilding derived numbers on a broken core is worse than serving yesterday's. The supplementary feeds are tolerant: a hiccup in one of them logs a failure and lets the recompute proceed on the otherwise-fresh data — while still marking the whole run as failed, so it can't pass unnoticed.

It checks its own output

The run doesn't end "successfully" just because every step returned — it ends by verifying the result. Three checks run last and fail the run on any violation:

• No duplicates — no two records may describe one player after the nightly identity merge.
• No broken references — nothing durable may point at a record that was removed.
• No lost coverage — no player who was covered yesterday may silently fall out of coverage today.

This is the load-bearing idea: the platform's safety rests on failing closed — surfacing a correctness regression as an alarm — rather than on hoping nothing went wrong.

Fresh by the day

• Nightly — the fast-moving surfaces (form, club strength, the discovery flags, the recommendation and fit caches, the network) are rebuilt each night from the day's results, so most of what you see is a day fresh.
• Weekly — the heaviest, slowest-moving computations (the similarity and projection engines, longer-horizon recomputes) run on a weekly cycle.

Freshness is therefore bounded by the schedule: a mid-day transfer or a new flag is reflected at the next run, not the instant it happens. We'd rather be predictably fresh and checked than instantaneous and unverified.

How we keep it honest

The principles are deliberately conservative, and they are the reason you can trust a number on a screen without re-deriving it yourself:

• One source of truth for the schedule — the order is the sequence, defined in one place, so steps can't quietly drift out of sync.
• Idempotent, independently re-runnable steps — any single computation can be re-run on its own and safely, which is what makes recovery and spot-fixes cheap.
• Verified ordering — the dependency order is asserted to be valid, so a reordering mistake is caught rather than silently serving a day-stale number.
• Fail-closed over fail-quiet — the run verifies its own output and stops on a broken invariant; correctness regressions show up as alerts, not as wrong data.

What it can't do

• It's scheduled, not instantaneous. Freshness is bounded by the nightly (and, for the heaviest pieces, weekly) cycle — by design, in exchange for everything being recomputed in a consistent, verified order.
• A tolerant source can serve slightly stale data for itself until its next successful run — the trade for letting the rest of the night proceed on fresh data.
• The checks catch, they don't pre-empt. The nightly invariants are a net that makes a bad night loud; they're the safety layer, working alongside the upstream care that tries to stop problems arising in the first place.