Verification methodology

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.

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.

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.

Verified result ingestion already exists as production capability in a separate backend and is not rebuilt here. The intended architecture is one trusted verified result store and read model, with this site as an independent consumer-facing frontend reading only verified data from it. This preview is not connected to that read model yet and uses local typed demonstration fixtures instead.

No internal operator details, credentials, endpoints or scheduling internals are published on this site, and none are needed to understand the gates above.

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.

This site does not publish exact draw days or cut-off times for any operator, because those have not been confirmed and an unconfirmed schedule is worse than none. Provider pages mark this as production verification needed rather than filling the gap with a plausible guess.

None of the gates above have been applied to anything currently on this site. The data here is demonstration data and is labelled as such throughout. The methodology is published now because the structure it implies — complete sets, explicit labelling, no silent truncation — is what the interface is being built around.