Live Game Video, Round Data and Results: Three Contracts
A live game interface may combine video, round-state data and results on one screen. That visual combination does not mean the three components share delivery timing, identifiers or recovery behavior.
Define their contracts independently, then specify how the application joins them. This helps the interface remain coherent when one component is delayed or unavailable.
Contract 1: the video
Document how the player obtains media, which table the stream represents and what happens when access expires or playback stops. Keep playback health separate from data freshness.
A moving picture does not prove that the structured round data is current. Likewise, a result message does not prove that the viewer has already seen the corresponding moment in the video.
Contract 2: the round state
Identify the table, round, phase and source ordering information available in the feed. Ask how a newly connected client obtains a complete current state.
The application needs a policy for unknown phases and missed updates. Guessing the state from a countdown or a visual animation creates an unreliable substitute for the source contract.
Contract 3: the result
Confirm how results reference their round and whether corrections or provisional states are possible. Specify how the current result and historical record are updated.
Keep the result identity distinct from the time it was received. A delayed result may arrive after the interface has moved to another round.
Test the joins
In a hypothetical test, video remains on table A while data switches to table B. The integration should detect the identity mismatch rather than presenting the combined screen as valid.
Another test delays a prior round's result until the next round is visible. The interface should place it in the correct history entry, not attach it to whichever round happens to be current.
Agree a disagreement policy
- Video unavailable, round data current: Proposed interface response – Show current structured data with a video-specific message
- Video playing, round data stale: Proposed interface response – Label the structured state as stale and reconcile it
- Result references an earlier round: Proposed interface response – Update that round's history, not the current round
- Table identities disagree: Proposed interface response – Withhold the inconsistent combined view and investigate
These are proposed product responses, not a supplier's guaranteed behavior. The project team should adapt them to the actual contract and the interface's purpose.
Choose a coordinator for the screen
One application component should decide whether the combined state is coherent enough to display. That coordinator need not control the supplier services; it needs a clear view of their identities, freshness and readiness.
Without this responsibility, the video player may recover independently while the data widget remains attached to an earlier table. Each component reports local success, yet the page as a whole is wrong.
Give the coordinator explicit transitions such as initializing, coherent, degraded and resynchronizing. Preserve the reason for a degraded state so support can distinguish playback failure from identity mismatch. Keep internal error details out of user-facing messages unless they help the person take a useful action.
Test the coordinator with controlled asynchronous sequences. Deliver the snapshot first, then video readiness, then a late previous-round result. Repeat with a different order. The visible outcome should follow the documented identity and state rules instead of depending on whichever callback happens to arrive first.
Assign ownership of recovery
Decide which component initiates resynchronization and how uncertain state is displayed. Avoid three independent retry loops that repeatedly reset each other.
The 7 Unicorn Gaming Casino API page introduces its game-data offering. Use the integration guidance to frame questions about the actual contracts. This architecture is a proposed design model, not a claim that the supplier exposes three separate endpoints. The important requirement is that your team can explain each stream of information and verify the relationships between them.