How we govern our own automated agents.

Seven ways a prediction record misleads

Every one of these is available to anyone publishing predictions, ourselves included, and most of them happen without anyone deciding to mislead — which is why each needs a structural guard rather than good intentions. We name no companies: these are mechanisms, and the useful question is not who does them but where each one is blocked. Each row links to somewhere you can check ours.

1. 01

   A record that can be edited after the fact

   How it goes wrong
   If a prediction is stored in a mutable row, a losing call can be softened, requalified, or quietly removed once the result is known, and no reader can tell that it happened. The published history then describes the outcome rather than the forecast — and it will look excellent, because anything that did not work has been edited out.

   What we do instead
   Every book-priced pick is written before kickoff into a hash-chained record where each entry commits to the one before it. Changing an old entry breaks the chain for everything after it, so tampering is detectable by a stranger rather than only by us.

   Check a record yourself
2. 02

   Choosing which results count once they are known

   How it goes wrong
   A published history can be assembled by keeping the sports, seasons, bet types, or date ranges that worked and describing the rest as experimental, off-model, or not part of the official record. Nothing is fabricated at any step, and the result is still a number that cannot be reproduced from the full set of forecasts.

   What we do instead
   The scope of what counts is fixed in advance, and every settled pick inside that scope is graded — including pushes and voids, which are excluded from the calibration set as their own category rather than folded into losses or wins.

   See what is and is not judged
3. 03

   Presenting confidence as though it were edge

   How it goes wrong
   A model's confidence score says how sure the model is. Whether a wager is worth making depends on that probability compared against the price, after the bookmaker's margin is removed. Ranking by confidence produces a board that looks decisive and systematically favours heavy favourites, where confidence is high and the price has already absorbed it.

   What we do instead
   Nothing fires on confidence. The decision is made on the gap between our lower-bound probability and the de-vigged price from both sides of that pick's own market, and the gap is shown with the threshold it had to clear.

   See the threshold and the gap
4. 04

   Reporting a rate before the sample can support one

   How it goes wrong
   A rate computed from a few dozen settled results has an interval wide enough to contain both a strong edge and a losing one. Published as a single number with no interval, it reads as a finding. Published in a period that started at a convenient point, it reads as a trend.

   What we do instead
   A category with too little settled history is reported as not judged, in those words, and no rate is shown for it at all. That is a different answer from a refusal, and the two are never collapsed into one.

   See the not-judged state
5. 05

   Grading against a price nobody could have taken

   How it goes wrong
   A result can be graded against the best number seen anywhere, or the number after a favourable move, rather than the one quoted when the call was published. Every individual grade looks defensible; the aggregate describes a bettor who does not exist.

   What we do instead
   A pick is evaluated against a captured quote for its own market, timestamped, and refused if that quote is stale or if the handicap has moved off the one the pick was taken at. The price shown is the one we evaluated, not the best one available.

   See which prices are refused
6. 06

   Letting a call vanish instead of resolving it

   How it goes wrong
   When a game is postponed, an input is missing, or a pipeline fails, the affected call can simply stop appearing. A reader cannot distinguish a forecast that was considered and declined from one that quietly disappeared, and only one of those reflects a judgement.

   What we do instead
   A candidate that cannot be evaluated is shown as not evaluated, with the specific input that was missing named — a stale quote, an absent price, a game already under way. Rows too incomplete to describe at all are counted and reported rather than dropped.

   See the named exclusions
7. 07

   Making the claim impossible to check

   How it goes wrong
   A number with no method, no scope, no interval, and no route to the underlying records cannot be wrong, because there is nothing to test it against. It functions as reassurance rather than evidence, and the absence of a way to check it is the load-bearing part.

   What we do instead
   The performance surface stays sealed until the evidence clears its own stated bar, and the bar is published rather than described. Where we have no substantiated number, we say so instead of showing a softer one.

   See the sealed record

None of the above is a statement about how well the predictions perform. It is a statement about what the reporting makes checkable, which is the only one of the two we can substantiate before there is a settled record.

What we do not claim

• Not a parameterized (∀N) proof. Every model-checking result behind this page is a fixed-constant, finite-cutoff check, not a machine-checked universal statement.
• Not a production enforce-by-default posture. SHADOW is the only default anywhere this admission check runs. Enforcement is reachable only from an explicitly lab-gated path, confirmed by direct code search, not assertion.
• Not a claim about bet-settlement correctness or any user-facing betting logic. This entire surface is about internal AI/agent tool-call admission bookkeeping — nothing about odds, grading, or picks.
• Not a SOC 2, ISO 27001, or EU AI Act certification. Related internal alignment work exists and is documented separately, but nothing on this page is a certification claim.
• Not autonomous. Certificate-version activation is a human-only, manually-run action — never triggered by CI, a cron job, or any automated caller.