How result verification works

Most result-page errors are not invented numbers. They are stale dates, half-loaded lists and results attributed to the wrong provider. A gate model catches those failures by refusing to mark a draw as published until each specific condition is met, instead of trusting that a fetch succeeded.

In production, a draw must pass all of the following before it is treated as published:

• Draw date gate: the date attached to the data matches the draw being published, not a previous draw carried over.
• Top prize gate: all three top prizes are present and each is a complete four-digit value.
• Supporting list gate: where the provider publishes them, the Special or Starter list and the Consolation list are complete, normally ten numbers each.
• Provider gate: the data is attributed to the operator it actually came from.
• Confirmation gate: two fresh reads from that provider's approved source must normalize to an identical fingerprint before the set is marked final.

A draw that fails any gate is not published as final. The correct behaviour is to show the draw as unconfirmed or pending, or to show nothing at all, rather than to display a partial set that looks authoritative. Partial data presented confidently is worse than absent data, because a reader cannot tell it is partial.

This frontend has two explicit data states. Private Preview builds may use clearly labelled deterministic fixtures, while a future launch build is allowed only when the existing Verified-only public read configuration is present. The verification gates described above belong to the production result system; fixture data never claims to have passed them.