Source Confidence Labels
How official, verified, observer, fallback, manual, and unknown source-confidence labels should be interpreted.
Section
14 / 27
Live API examples
Jump from the docs to real public pages that use the same read models.
Why source confidence exists
Lottery Feed API separates stored winning numbers from the evidence role behind those numbers. Public responses expose compact source-confidence labels while private collection diagnostics and review notes remain outside the customer contract.
Levels returned by the API
The same labels can appear in latest results, history rows, lottery catalog rows, statistics summaries, and result-check responses. Treat the level as an evidence role, not as a legal endorsement or lottery-operator partnership claim. Unknown-level rows can display Published source when a source name is recorded but the public confidence role is not classified yet.
{
"source_confidence_levels": [
{
"level": "official",
"label": "Official source",
"policy": "The result is linked to a source that has been classified as the official lottery operator.",
"public_meaning": "The source classification is supported by reviewed evidence for this source."
},
{
"level": "verified",
"label": "Verified source",
"policy": "The result is linked to a reviewed independent source and carries an explicit verified classification.",
"public_meaning": "The result has reviewed independent evidence but is not labelled as official."
},
{
"level": "observer",
"label": "Cross-checked source",
"policy": "The result was observed through an independent comparison source.",
"public_meaning": "Comparison evidence is informative and does not imply official-source confirmation."
},
{
"level": "fallback",
"label": "Fallback source",
"policy": "The result was supplied by a reviewed fallback source.",
"public_meaning": "Fallback evidence is identified separately from official-source confirmation."
},
{
"level": "manual",
"label": "Operator reviewed",
"policy": "The stored result was reviewed or corrected by an authorized service operator.",
"public_meaning": "A human review or correction is recorded for this result."
},
{
"level": "unknown",
"label": "Source verification pending",
"label_variants": [
"Source pending",
"Published source"
],
"policy": "The result is stored, but its source does not have sufficient customer-visible classification evidence.",
"public_meaning": "Do not describe this result as official or verified."
}
]
}Recommended customer display
Show the human label near the draw date and numbers. For official and verified rows, a compact trust badge is appropriate. For observer, fallback, manual, or unknown rows, keep the label visible and avoid wording that implies the result came directly from the official lottery website unless your own downstream checks confirm that.
Customer decision table
Use this table when mapping source-confidence labels into a customer product. It keeps the public UI direct while preserving the operational distinction between official, verified, observer, fallback, manual, and unclassified rows. The table is generated from the same policy rows used by the public API code, so every visible label has a documented display decision and integration action.
{
"source_confidence_display_decisions": [
{
"level": "official",
"label": "Official source",
"recommended_display": "Show as official-source data near the draw date and numbers.",
"integration_action": "Accept for official-first integrations and still upsert by game_code plus draw_date.",
"public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
},
{
"level": "verified",
"label": "Verified source",
"recommended_display": "Show as verified feed data with the source-confidence label visible.",
"integration_action": "Accept for most integrations that allow verified feed rows.",
"public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
},
{
"level": "observer",
"label": "Cross-checked source",
"recommended_display": "Show as observer evidence and avoid official-source wording.",
"integration_action": "Use for comparison, speed checks, or customer display only when your policy allows observer rows.",
"public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
},
{
"level": "fallback",
"label": "Fallback source",
"recommended_display": "Show as approved fallback data and keep the fallback label visible.",
"integration_action": "Accept only if your policy allows approved fallback rows while official access is unavailable.",
"public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
},
{
"level": "manual",
"label": "Operator reviewed",
"recommended_display": "Show as operator-reviewed or corrected data with correction context when present.",
"integration_action": "Treat as a correction/update path and reconcile against previously stored numbers.",
"public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
},
{
"level": "unknown",
"label": "Source verification pending",
"recommended_display": "Show as published data with source review pending; do not imply official verification.",
"integration_action": "Store the row if visible, but keep review pending in your own UI until confidence is upgraded.",
"public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
}
]
}Provenance boundary
Public API responses include a compact provenance object next to source_confidence when a draw row is visible. It contains a customer-safe label, role, optional source display fields, and a short display sentence. Add include=trust when a customer UI needs the bounded public timeline with source role, observation time, and storage time.
{
"source_confidence": {
"level": "observer",
"label": "Observer source",
"policy": "Numbers came from an observer source used for speed, comparison, or mismatch detection."
},
"provenance": {
"label": "Magayo",
"role": "observer",
"source": "magayo",
"provider": "Magayo",
"display": "Magayo observed this result for comparison."
},
"trust_evidence": {
"summary": {
"label": "Observer provenance",
"headline": "Observer result for comparison"
},
"timeline": [
{
"label": "Source role",
"value": "Observer source",
"caption": "Numbers came from an observer source used for speed, comparison, or mismatch detection.",
"status": "ready"
},
{
"label": "Source observed",
"value": "Jun 21, 2026, 12:00 PM UTC",
"caption": "Magayo is the public source name in the compact feed.",
"status": "ready"
},
{
"label": "Result stored",
"value": "Jun 21, 2026, 12:01 PM UTC",
"caption": "Timestamp when Lottery Feed API stored this draw in the customer-visible feed.",
"status": "ready"
}
]
}
}Mismatch and correction behavior
When numbers are corrected, manually approved, or stored through observer or fallback evidence, the public confidence label can become Operator reviewed, Observer source, or Fallback source. Public detail pages and draw APIs can show compact correction evidence by default. Add include=mismatch_timeline only for reconciliation screens that need a bounded source-comparison timeline. Customer systems should store draw_date, game_code, numbers_string, source_confidence.level, provenance.role, correction.version_count, mismatch_timeline.summary.class, mismatch_timeline.review_state.state when requested, and inserted_at so they can detect and audit changes.
GET https://api.lotteryfeedapi.com/v1/results/latest/md-pick3-midday?include=trust,mismatch_timeline
{
"game_code": "md-pick3-midday",
"numbers_formatted": "2-3-6",
"source_confidence": { "level": "verified", "label": "Verified source" },
"mismatch_timeline": {
"available": true,
"stored_numbers_formatted": "2-3-6",
"summary": {
"class": "observer_disagreement",
"label": "Observer disagreement",
"decision": "Stored result kept after public review evidence"
},
"review_state": {
"state": "operator_reviewed",
"label": "Operator review completed",
"public_note": "A reviewed correction or approval path is recorded for this result."
},
"events": [
{ "type": "stored_result", "label": "Stored public result", "source_role": "verified", "numbers_formatted": "2-3-6" },
{ "type": "observer_disagreed", "label": "Observer reported different numbers", "source_role": "observer", "numbers_formatted": "8-1-2" }
]
}
}Next: Status monitoring