Verification methodology

The publication gates a draw must pass before it can be treated as a published result.

The principle

A result is either complete and confirmed, or it is not published as final. There is no middle state where a partial set is displayed as though it were authoritative, because a reader has no way to tell a partial set from a complete one.

Publication gates

A draw must pass every gate below before it is treated as published:

  • Intended target draw date: the draw matches the intended target date evaluated in the Asia/Singapore timezone, so a previous draw cannot be carried over silently.
  • Allowlisted provider and source identity: the data comes from the approved source for that provider and is matched to that provider, never inferred from page position or ordering.
  • Valid draw number: the draw identifier is present and valid for that provider.
  • Exact four-digit top prizes: 1st, 2nd and 3rd prizes are each present as exact four-digit values.
  • Exact supporting lists: where the provider publishes them, exactly ten Special or Starter values and exactly ten Consolation values.
  • Leading zeros preserved: values are handled as four-character strings end to end, so 0472 can never be stored or displayed as 472.
  • Placeholder filtering only when a complete set survives: placeholder entries may be filtered only if exactly ten valid values remain; otherwise the draw is not published.
  • Two matching snapshots: a first normalised snapshot and a second fresh normalised snapshot must produce an identical fingerprint.
  • Existing verified data protected: an already verified draw is never overwritten or downgraded by a conflicting later read.
  • No fallback and no guessing: there is no previous-draw fallback, no inferred value and no partial publication.
  • Repeated values preserved exactly: if the approved source genuinely contains the same winning number more than once and both snapshots agree, the repetition is kept. Result lists are never de-duplicated.

Provider-independent publication

Providers are gated independently. If six providers pass every gate and one has not published yet, the six are released and the seventh stays pending, rather than the whole day waiting on the slowest operator. That keeps the published set both current and complete, instead of trading one for the other.

Relationship to the production Verified system

Verified result ingestion runs as a separate production capability. This consumer-facing site reads the resulting Verified rows rather than re-running source ingestion in the browser. That separation keeps publication checks upstream of the public presentation layer.

No internal credentials, private endpoints or secret material are published on this site, and none are needed to understand the public verification rules above.

What happens when a gate fails

A failed gate means the draw is shown as unconfirmed or pending, or not shown at all. It is never presented as a final result with the missing part quietly omitted. A visible gap prompts a reader to check the operator; an invisible one does not.

Scheduling claims

The site does not force every provider into one shared draw calendar. Where a provider cadence has been confirmed it may be stated explicitly; otherwise the site avoids presenting an unverified schedule as fact.

Application to production results

The result rows displayed as Verified on this site have passed the publication gates applicable to the current production pipeline. A candidate that is incomplete, inconsistent between confirmation snapshots or otherwise fails its checks is not presented as a final result.

Historical and provider pages therefore describe what has already been published and verified; they do not infer missing results or use past draws to predict future numbers.

Results are for reference and personal record keeping only. We do not accept or place bets. See also methodology, data sources and responsible use.

This page is registered as publisher content.