Football Match Statuses for Disputes, Appeals and Final Decisions
A contested score needs more than a “final” label. Design football app statuses that distinguish play completion, review, appeal and an authoritative decision.
A football match can be over on the pitch while its result remains contested off it. If an app collapses both facts into one “final” label, users may mistake a recorded score for an outcome that has survived review or appeal. Coverage around the CAN dispute, including reporting by RFI and 20 Minutes, makes this distinction a practical product-design question—not a reason to predict a ruling. The durable requirement is a status model that separates what happened during play, what the publisher currently reports, and whether a competent authority has issued a later decision. Here is a compact framework product teams can specify before choosing feeds, screens or notifications.
Separate the match from the result’s authority
Start with two related but distinct records. The match record describes the sporting event: scheduled, in progress, completed, abandoned or postponed. The result record describes the standing of a score or outcome: provisional, under review, appealed, decided or superseded. A completed match may therefore have a result under review; changing the result’s standing should not rewrite the historical fact that play ended. This separation prevents a single status field from carrying incompatible meanings and supports accurate fixture lists, tables, match pages and archives. For an MVP, these can be fields on one data model, but their meanings and transitions should still be independent and explicit.
Use plain labels with a short explanation wherever the distinction matters. “Match completed” answers whether play is over; “result under review” says the published outcome is not settled; “appeal pending” indicates a challenge is awaiting a decision; and “decision issued” means an identified authority has published an outcome. Avoid using “final” as a catch-all unless the product defines exactly what is final and for whom. A fan may read it as legally or administratively conclusive, while an upstream data provider may mean only that its live feed has closed. Define that contract with the provider and show the last verified update time.
- Keep match progress and result standing as separate concepts, even if they share a screen.
- Pair every non-routine status with a plain-language explanation and an update timestamp.
Specify transitions, ownership and evidence
A useful starting sequence is: scheduled → in progress → completed, with exceptional match paths such as postponed or abandoned. Separately, a result can move from provisional to confirmed, or from provisional or confirmed to under review, then to appeal pending and decision issued. A decision may uphold the published result, amend it, or leave another defined outcome; model those outcomes as decision results, not vague status labels. These are product-design options, not claims about a particular competition’s rules. Before implementation, confirm which states the competition and data source actually support. Do not create an appeal state if the available source cannot reliably tell you that an appeal exists.
Assign authority for each transition. A feed can report a score, but your product needs a rule for who may change its standing: an official competition source, an authorised editor, or a reviewed integration event. Store the source, received-at time, effective time if supplied, and a reference or explanation for a decision where available. Keep prior values for audit and display a concise change summary to users. A correction to a feed should not silently appear to be an appeal outcome. Engineering teams should also define idempotent updates, duplicate-event handling and a fallback when sources disagree, so a repeated message does not generate contradictory status changes or notifications.
- Document permitted transitions, transition authority and the evidence required for each one.
- Separate a data correction from a governing-body decision in both the model and user-facing copy.
Design the interface and MVP around uncertainty
On a match page, show the score and match-completion state separately from the result standing. For example, a clearly labelled hypothetical screen could read: “Match completed — 2–1. Result under review. Last updated 14:20; source: competition authority.” If a decision later changes the outcome, show the new decision and preserve a link to the previous published state where practical. Do not rely on colour alone: status text must remain understandable in a compact score list, a screen reader announcement and a notification preview. Explain what users can infer—and what they cannot. “Under review” should not imply that the result will change.
Scope the first release around dependable distinctions, not a complex legal case-management system. Include the two-part status model, source and freshness display, a reviewed update path, an audit record, and notification rules for meaningful changes. Test at least these scenarios: a match ends with an unsettled result; a review begins; an appeal is recorded; a decision confirms or changes the outcome; a source correction arrives; and a feed is unavailable. In each test, check the match page, list view, standings if applicable, cached content and push message. Suppress duplicate alerts and avoid sending a definitive-result notification while the result remains contested.
- MVP acceptance check: a user can tell whether play ended, whether the score is settled, who supplied the update and when it was checked.
- Treat standings and notifications as downstream views of the same result state, not independent sources of truth.
The right answer to “Which match statuses should a football app use when a result is contested?” is not one universal label. Separate match completion from result standing, define who can advance each state, and make the source and freshness visible. Then test the full path from a completed match through review and appeal to a later decision, including corrections and feed failures. This model gives product teams a clear MVP boundary and gives users a more honest account of what is known without implying that an unresolved status predicts the eventual outcome.