braket.gg BETA
EN

AI referee

Not every game can integrate the game-client protocol: you may not control the source, or the title may be old, or you may be running a cross-game "any-game" tournament. For those cases the AI referee steps in directly: a result source (ai_video) that is the evidence-based twin of the dual-attestation game protocol. Both sides attach a recording or stream of the match; an AI referee reviews both; and the result confirms only when the two videos independently conclude the same outcome above a confidence threshold. Anything less falls back to the human dispute queue with the clips attached. This chapter is accurate to src/ai/referee.ts, src/services/tournamentService.ts (submitVideoEvidence), and the video_evidence table.

Where video sits in the referee picture. For games that do integrate, Braket's AI referee is event-first: it learns from and adjudicates on structured gameplay data — braket.gameplay.v1 traces, which the server derives automatically from finalized match recordings (or accepts as direct submissions from older clients). Visual capture (braket.capture.v1) is an optional, consent-gated backstop that may complement the event data later — it is not the primary mechanism. The video verification described in this chapter is for the non-integrated case: whole-match videos supplied by the players themselves.

Why two videos

The trust argument is identical to the game-client protocol. One video, judged by an AI, could be a doctored recording. Two independent recordings, one from each side, are far harder to fake in agreement: the referee confirms a result only when both videos point to the same winner. A single doctored clip, or two clips that disagree, never auto-confirms; it escalates to an admin. So an automated verifier can never record a wrong result, at worst it forces the match into the dispute queue, exactly like a game-client hash mismatch.

The flow

  1. Each side attaches its video. A participant submits an HTTPS URL to their stream VOD or recording. The URL is validated: it must match ^https://[^\s"'<>]{10,300}$ (HTTPS only, 10 to 300 characters). Evidence is stored one row per side in video_evidence (matchId, sideUserId, submittedByUserId, url). Resubmitting a side's evidence replaces the previous row and clears any prior verdict. The match must have started (startedAt set) and must not already be resolved.
  2. Wait for both sides. If only one side has attached evidence, the outcome is pending and nothing is decided yet.
  3. The referee reviews. Once both sides' evidence is present, the AI referee is invoked with both video URLs and the two side names, and returns a three-way verdict plus a confidence score.
  4. Confirm or dispute. If the verdict is not inconclusive and the confidence is at least the floor (REFEREE_MIN_CONFIDENCE = 80), the match confirms with resultSource: 'ai_video', taking the winning side. Otherwise the match goes to disputed and surfaces to the admin dispute queue with the clips attached. In all cases the referee's verdict, confidence, and notes are written back onto the evidence rows.

For team battles the evidence attaches to the side (the captain id), so the same two-row agreement check applies as in 1v1.

The referee verdict

The referee returns a RefereeVerdict:

Field Type Meaning
verdict 'side1' | 'side2' | 'inconclusive' Which side the videos show winning, or that they do not agree/are unreadable
confidence number (0 to 100) How confident the referee is. Callers treat anything below the threshold as inconclusive
notes string Human-readable rationale, stored for the admin

The confidence floor is a hard gate: confidence below 80 never auto-confirms, no matter the verdict. Humans decide those.

The evidence row stores the outcome as verdict (side1, side2, or inconclusive), confidence (0 to 100), and notes.

Configuration and the fail-safe default

The referee is mock-first, like the rest of Braket:

Variable Meaning
AI_REFEREE_API_KEY When set, the real video pipeline is used. When unset, the mock referee runs

The real implementation is a video pipeline: fetch the VOD, sample frames, score the end screens / score overlays from both videos with a vision model, and cross-check that the two agree. Its contract is pinned so it can land without touching callers: same input, same three-way verdict, same 0 to 100 confidence.

Crucially, the default is fail-safe: an unconfigured real deployment (or the mock referee when it has no clear signal) returns inconclusive with confidence 0, which routes the match to the human dispute queue rather than guessing. The mock referee is deterministic for dev and tests: it reads ai-verdict-side1 / ai-verdict-side2 markers from the two URLs and confirms only when both markers agree; disagreeing or missing markers yield inconclusive. This means you can exercise the entire flow locally with no AI key by putting the markers in your test URLs.

How it fits the resultSource model

ai_video is one of the five values of matches.resultSource (see Result verification: the resultSource model). It plugs into the same match states as everything else: pending while waiting for the second video, confirmed (as ai_video) on confident agreement, and disputed when the referee is not confident or the videos disagree. From the bracket, ladder, and trophy perspective an ai_video result is indistinguishable from any other confirmed result, which is the point: it is another way to reach a trustworthy confirmed, not a separate pipeline.