The live scoring engine

What this part does

The engine turns one accepted command into new rows. The road before it (the key, the lock, the version check, the answer) is the same for every command and is explained in Commands and the workflow engine. This page is about what happens in the middle: how the new score is worked out and saved.

Section 5 answered six questions. If any one is answered wrong, a client shows a wrong score, or scoring slows down as the match goes on.

The two modes

The mode is chosen per competition, with an override per match. Scorecard is the default (S11). A Games uses scorecard everywhere. A premium league turns on events for the matches a client pays for.

Mixing the two. An events match can still take scorecard edits. An operator fixes a total by hand, and that hand edit wins over the value the events produced, under the priority list of Section 2. A match can also move from events to scorecard mid-match: the live scorer drops out at over 30 and the desk types the rest of the card. Nothing already scored is lost (S14).

There is no running clock. An event's match time is a value typed with it ("23", "45+2"), part of its input. The server also stamps when the device sent it and when it arrived. Order is the server's sequence number, never the typed minute (S8, M7).

How it works

Apply mode, step by step

1. The command arrives on the one road: its key is checked, the subject's lock is taken.
2. The input is checked against the command's input model, then the command's validations run.
3. One log row is written: what was set, and by whom. The old value stays readable in the log.
4. The command's writers set the values on their rows (the fixture, a side, and, once built, a player line).
5. A note goes into the outbox in the same transaction, so feeds and screens hear of the change.
6. Commit, then answer "accepted" with the new sequence number.

This is what the Asian Games console ran on, and it is built today in packages/core/src/omnium_core/workflows/engine.py:89-228. Its cost does not grow with the log, because nothing reads the log.

Events mode, step by step (agreed design)

1. The ball comes in on the road. One id, the match lock, the version check: the sender says which event it last saw (Section 4, L17).
2. Read the current state: one row. The scoreboard row holds the state, the number of the last event in it (last_seq), the rule version and the code fingerprint. It is read under the match lock, so nobody else can change it meanwhile.
3. Check the ball against that state. "Is this bowler allowed another over?" is answered from the state, never by reading the log.
4. Apply the ball. The sport's step function takes the state and this one ball and returns the new state plus the lines it changed. Every events sport must have one; it is part of the plugin contract.
5. Save, in one transaction: the log row, the new state, the batting and bowling lines this ball changed, the published match document, the note to feeds, and the command row.
6. Answer "accepted" after the commit.

Three more paths sit beside the main one:

• A correction or an undo of an old ball loads the newest checkpoint before that ball, replays the events after it with the fix in place, and saves. An undo of the last ball replays at most 49 events.
• A background check replays every live match from its log, from scratch, every 5 minutes and at every match end. If the answer differs from the saved state, the log wins: a "rebuild state" command repairs it, and an alert names the match and the first ball where they part.
• A deploy never changes a running match. A match runs the exact code it started with. Several versions of a sport's code are installed side by side. If the code a match needs is missing, the engine refuses to score it and raises an alert.

Why we save the state

Today each cricket ball folds the whole match again, then runs three line actions over the whole log again. Measured on 6 Oct on a laptop, with today's cricket code, one innings with no wickets, sport code only, no database:

Twice the balls costs four times the time. A Test match has about 2,700 balls; by the same curve a late ball would take over a second (an estimate from the design doc, not run). On top of this, each ball reads the whole match log from the database twice: 600 rows took 3 ms at the median and 97 ms at the 99th percentile (measured, design doc; the second number is when the rows are not in memory).

A worked example

Two examples: the common case (a scorecard edit), then the events case (a cricket ball and its undo). Team and player codes are example values.

{
  "code": "results.set_line",
  "key": "c1d7-set3-jpn",
  "input": {
    "subject": "JPN",
    "role": "",
    "segment": "set-3",
    "values": { "points": 25, "sets_won": 1 },
    "saw": 418
  }
}

{
  "code": "cricket.delivery",
  "input": {
    "striker": "KOHLI", "nonStriker": "GILL", "bowler": "STARC",
    "batRuns": 4, "extraRuns": 0
  },
  "saw": 311
}

Low-level design

This part has two halves. First, the code that runs today, read in order. Then the agreed design: tables, contract, one ball statement by statement, corrections, the check, versions, settings. How a sport's commands, validations and actions are written line by line is on Writing a workflow in code; this page does not repeat it.

Today's events path, in the code Built today

The live desk sends a command to the bridge, which calls pipeline.command (packages/admin/src/omnium_admin/routers/bridge.py:262-297). The pipeline's own header names the rings: lock, resolve, schema, validations, record, route, actions, emit.

1. The lock, then the first full log read. From packages/core/src/omnium_core/scoring/pipeline.py:869 and 896-907:

await session.execute(sa.select(sa.func.pg_advisory_xact_lock(ledger.lock_key(fixture.id))))
...
entrants = await ledger.load_entrants(session, fixture.id)
log = await ledger.effective_log(session, fixture.id)          # read 1: every row of the match
context = Context(
    fixture=fixture_facts(fixture, entrants.sides, await load_setting(session, fixture)),
    log=[e.as_json() for e in log],                            # every event turned into JSON
)
context.derived = await _current_derived(session, fixture)     # the scoreboard as of before this ball
context.masters = await load_masters(session, fixture)

The lock is a Postgres advisory lock on the first 8 bytes of the fixture id (scoring/ledger.py:167-176). It is held until commit. Then the validations get the whole log, so a rule like the bowler quota can loop over it. This is the first of two full reads.

2. The append. ledger.append (ledger.py:220-257) takes the next seq by bumping fixture.last_seq (ledger.py:184-202), inserts the row, flushes, and only then checks the declared players. A bad player code raises after the row is written, which is the Section 4 bug the migration fixes first.

3. The refold, and the second full read. From pipeline.py:685-709:

events = log if log is not None else await ledger.effective_log(session, fixture.id)  # read 2
determinism = determinism_for(events)
...
ordered = action_order(program)
folds = tuple(node for node in ordered if node.gives is Gives.STATE)
resume = await _resume_points(session, fixture, folds)          # checkpoints, incremental only
if fold_state(compiled, context, determinism, folds, result, resume=resume):
    await projections.write_scoreboard(session, fixture.id, context.derived)
    await _write_checkpoints(session, fixture, context)

command calls refold without passing the log (pipeline.py:949-958), so line 686 reads it again. determinism_for (pipeline.py:296-306) takes the clock from the latest event, not the wall, so a rebuild next year gives today's answer.

4. Full fold or one step. From pipeline.py:559-563 and 594-608:

value = (
    step_state(compiled, fold, context, determinism, (resume or {}).get(fold.id))
    if fold.incremental
    else run_action(compiled, fold, context, determinism)   # handed the whole log
)

def step_state(compiled, node, context, determinism, resume):
    fn = _callable_for(compiled, node)
    mark, state = resume if resume is not None else (0, None)
    for event in context.log:
        seq = int(event.get("seq") or 0)
        if seq <= mark:
            continue                                         # already inside the checkpoint
        outcome = fn(state, event, determinism=determinism, limits=SYNC_LIMITS)
        state, mark = outcome.value, seq
    context.reached[node.id] = (mark, state)
    return state

An incremental action is handed (state, event) and stepped from the newest checkpoint. Any other state action is handed the whole log. Note that step_state still loops over the whole in-memory log to skip what the checkpoint covers; the log was still read in full.

Which sports step? Only athletics. Its state action is declared @action(gives=Gives.STATE, incremental=True) (packages/flows/src/omnium_flows/athletics/actions.py:27). Cricket's is @action(gives=Gives.STATE, reads=["log"]) (flows/cricket/actions.py:46), and so is volleyball's (flows/volleyball/actions.py:19). The contract allows incremental only on a state action (packages/contract/src/omnium_contract/flows/components.py:244-245).

5. The scoreboard row. From packages/core/src/omnium_core/scoring/projections.py:76-84:

merged = dict(snapshot)
await session.execute(
    pg_insert(Scoreboard)
    .values(fixture_id=fixture_id, snapshot=merged, updated_at=sa.func.now())
    .on_conflict_do_update(
        index_elements=[Scoreboard.fixture_id],
        set_={"snapshot": merged, "updated_at": sa.func.now()},
    )
)

One row per fixture, replaced whole on every ball. Today it is written but never used as the starting point of the next ball; it is a cache for readers and for validations (pipeline.py:1179-1188).

6. The line actions, again over the whole log. Each cricket line action rebuilds every batter's or bowler's numbers from every ball. From flows/cricket/actions.py:449-458:

@action(gives=Gives.LINES, reads=["log"], keys=("runs", "balls_faced", "fours", "sixes"))
def batting_stats(self, log: tuple[Event, ...], ctx: Ctx[CricketFormat]) -> list[Line]:
    per: dict[tuple[str, int], dict[str, Any]] = {}
    for ball, innings in _each_ball(log):
        batter = str(ball.get("striker"))
        ...

projections.write_lines (projections.py:145-248) upserts all of them into stat_value and deletes any line not returned this time. That replace-and-prune is why a correction needs no undo code today, and also why every ball rewrites every line.

7. Checkpoints. From pipeline.py:791-796 and scoring/checkpoints.py:70-84:

every = int(get_settings().scoring_checkpoint_every)       # 50, settings.py:296
for node_id, (seq, state) in context.reached.items():
    if seq and seq % every == 0:
        await checkpoints.save(session, fixture.id, node_id, seq, state)

async def drop_from(session, fixture_id, seq):
    result = await session.execute(
        sa.delete(ScoringCheckpoint).where(
            ScoringCheckpoint.fixture_id == fixture_id,
            ScoringCheckpoint.thru_seq >= seq,
        )
    )

A checkpoint is written when an incremental fold reaches a seq that is a multiple of 50. A correction or void drops every checkpoint at or after the changed ball (pipeline.py:1155). Because only athletics is incremental, no other sport writes checkpoints today.

8. Corrections and voids. From pipeline.py:1138-1155:

item = await ledger.append(
    session, fixture_id=fixture.id, command=authored or node,
    payload={} if void else dict(payload.get("input") or {}),
    ..., supersedes=original,
    event_type=ledger.VOID_EVENT if void else original.event_type,
)
await ledger.supersede(session, original, void=void)        # flips status only, never the payload
forgotten = await checkpoints.drop_from(session, fixture.id, target_seq)

A correction is a new timeline_item that points at the old one with supersedes_id. ledger.effective_log (ledger.py:322-376) walks each ball forward to its newest correction and drops voided chains. A correction then fires every action, because it cannot know which numbers it moved.

The fingerprint today. Each component gets a source_sha: the sha256 of that one function's source text (components.py:116-120). The publish step copies it to impl_sha (packages/core/src/omnium_core/flows_publish.py:110). Nothing reads impl_sha at run time; only tests do. A fixture is pinned to a rule version once (scoring/store.py:193-199, column fixture.scoring_program_version_id), but the code that runs is whatever is installed.

The tables Agreed, to build

No new tables. The saved state is the scoreboard row that already exists, and checkpoints already exist. The match lock stays on the match's own row. scoreboard is only written by a command that holds that lock.

-- scoreboard EXISTS today: one row per match (models/fixtures.py:476-500),
-- columns fixture_id, snapshot jsonb, updated_at. It becomes the saved state.
ALTER TABLE scoreboard
  ADD COLUMN last_seq    bigint,        -- the last log row folded into snapshot
  ADD COLUMN rules_id    uuid,          -- scoring_program_version the match is pinned to
  ADD COLUMN code_sha    text,          -- fingerprint of the whole sport package (M6)
  ADD COLUMN state_hash  bytea;         -- sha256 of the canonical snapshot, for the check
-- snapshot (jsonb) stays; rule M2 keeps it under 16 KB.

-- scoring_checkpoint EXISTS today: (fixture_id, trigger, thru_seq) -> state
-- (models/scoring.py:185-213).
ALTER TABLE scoring_checkpoint ADD COLUMN code_sha text;

-- stat_value EXISTS today: one row per (fixture, subject, role, segment, occurred_on)
-- with a jsonb of values and last_seq (models/stats_engine.py:83-130).
-- A player's match line lives here in both modes.

-- The log gains two server times (S8, M7).
ALTER TABLE timeline_item
  ADD COLUMN sent_at     timestamptz,   -- when the device sent it
  ADD COLUMN received_at timestamptz NOT NULL DEFAULT now();
-- No clock column: the minute is part of the event's input, as typed.

The state must stay small Agreed, to build

Today's cricket state at ball 600 is 149 KB, and 148 KB of it is a list of every delivery (design doc, 6 Oct). So the state grows with the match, just like the replay. Saving it on every ball was measured on a laptop:

The big state also costs about 1.5 ms in Python to read and write as JSON (measured, design doc). So the rule (M2): the state holds only what the next ball needs and what screens show now. Every ball's detail stays in the log, which feeds read by match and ball number. The state stays under 16 KB at any point in any match.

The step-function contract Agreed, to build

Every events sport provides four pure functions: no database, no clock, no network. The same events always give the same state. The design doc names the file contract/.../flows/sport.py as new. That file already exists today: it holds the Workflow and Sport classes (packages/contract/src/omnium_contract/flows/sport.py:61, 204). So these types are new, and Section 6 settles where they live.

State = dict[str, Any]          # JSON only; canonical form is hashed

@dataclass(frozen=True)
class Event:
    seq: int                    # the match's log number, set by the server
    code: str                   # "cricket.delivery"
    input: dict[str, Any]       # already checked against the command's pydantic model
    source: str                 # who sent it: device, provider or integration

@dataclass(frozen=True)
class Line:                     # one player's (or side's) numbers in this match
    subject: str                # participant code, resolved to an id by the engine
    role: str = ""              # stat_value.subject_role
    segment: str = ""           # stat_value.segment
    values: dict[str, Any] = field(default_factory=dict)   # keys from the sport's catalogue

@dataclass(frozen=True)
class Step:
    state: State                   # the whole new state (small, M2)
    lines: tuple[Line, ...] = ()   # only the lines this event changed (M3)
    emits: tuple[str, ...] = ()    # "wicket", "innings_end" ... for feeds and stats

class EventSport(Protocol):
    def initial_state(self, format: dict[str, Any], sides: list[dict[str, Any]]) -> State: ...
    def check(self, state: State, event: Event) -> Refusal | None: ...
    def step(self, state: State, event: Event) -> Step: ...
    def summary(self, state: State) -> dict[str, Any]: ...   # the score others compare

What each one does:

• initial_state builds the empty match from its format and sides.
• check replaces today's validations that read the whole log. It may read only the state and the event. It returns None or a Refusal with a code and a sentence a scorer can read.
• step is the only place a sport's rules change the state. A whole replay is initial_state, then step for every event. The background check and corrections use exactly the same code as a live ball.
• summary is the score that other parts compare (Section 2, T6).

A void is never passed to step. The engine removes the voided event and replays, so a sport never writes undo code, as today. Athletics' incremental action (flows/athletics/actions.py:27-79) already has this shape: state plus one event gives a new state.

One ball, statement by statement Agreed, to build

BEGIN;
SELECT last_seq FROM fixture WHERE id = $match FOR NO KEY UPDATE;   -- the match lock (L1)
SELECT outcome, answer FROM command WHERE command_id = $id;          -- retry check (L3)
SELECT last_seq, code_sha, snapshot FROM scoreboard WHERE fixture_id = $match;
--   last_seq differs from the event the sender saw -> ROLLBACK, "conflict" + missed events (L17)
--   code_sha differs from the loaded code          -> ROLLBACK, "try again" + alert (S6)

-- In the sport's worker process, no SQL:
--   check(state, event) -> None or a Refusal
--   step(state, event)  -> Step(state, lines, emits)

INSERT INTO timeline_item (fixture_id, seq, unit, event_type, payload, sent_at, received_at, ...)
     VALUES ($match, $seq, 'event', $type, $payload, $sent, now(), ...);
UPDATE scoreboard SET snapshot = $state, last_seq = $seq, code_sha = $sha,
                      state_hash = $h, updated_at = now()
 WHERE fixture_id = $match;
INSERT INTO stat_value (fixture_id, subject_id, subject_role, segment, occurred_on, "values", last_seq, ...)
     VALUES (...)                                         -- only the lines this event changed
ON CONFLICT (fixture_id, subject_id, subject_role, segment, occurred_on)
  DO UPDATE SET "values" = EXCLUDED."values", last_seq = EXCLUDED.last_seq;
INSERT INTO published_document ... ;                      -- the match document clients read
INSERT INTO domain_event ... ;  INSERT INTO command ... ; -- feed note, command row (Section 4)
UPDATE fixture SET last_seq = $seq WHERE id = $match;
COMMIT;                                                   -- then "accepted"

Every 50th event also writes a scoring_checkpoint row. Nothing here reads more than one row per table, so the cost does not depend on how long the match is.

Two trips, not nine (M9). Written as above, a ball makes about 9 trips to the database (counted from the SQL). On AWS one trip in the same zone costs about 0.3 to 1 ms (estimate, to measure in Section 12). So the command is sent in 2 trips: one statement that takes the lock and reads the id, the state and the versions together, and one call to a database function that does every write and the commit. That brings a ball to about 2 to 3 ms on prod (estimate). The target (S9) is under 5 ms of server time at any ball, from ball 1 to ball 2,700.

The engine side, as the design sketches it (core/.../engine/events.py, new):

async def apply(session, subject, node, cmd, fixture_seq) -> Answer:
    board = await state.read(session, subject.fixture_id)     # one row: snapshot, last_seq, code_sha
    if cmd.saw is not None and cmd.saw != board.last_seq:
        return answers.conflict_missed(await ledger.after(session, subject.fixture_id, cmd.saw))
    pool = workers.pool_for(board.rules_id, board.code_sha)   # raises CodeMissing -> "try again" + alert
    if node.op is Op.APPEND:
        event = Event(seq=fixture_seq + 1, code=cmd.code, input=cmd.input, source=cmd.source)
        reply = await pool.check_and_step(board.snapshot, event)      # one round trip to the worker
        if reply.refusal:
            return answers.refused(reply.refusal.code, reply.refusal.sentence, reply.refusal)
        await ledger.append(session, subject, event, sent_at=cmd.sent_at)
        await state.write(session, subject.fixture_id, reply.step, seq=event.seq)  # + checkpoint every 50
        await projections.upsert_lines(session, subject.fixture_id, reply.step.lines, seq=event.seq)
    else:                                                      # CORRECT or VOID
        reply = await corrections.replay(session, subject, pool, node, cmd)
    await publishing.materialize.fixture(session, subject.fixture, reply.step.state, seq=reply.seq)
    await outbox.note(session, subject, reply.seq, ("fixture",), emits=reply.step.emits)
    return answers.accepted(reply.seq)

The road around it (key, lock, duplicate check, the answer row) is on Commands and the workflow engine.

The scorecard line command Agreed, to build

A new Results command, results.set_line (S12), with input {subject, role, segment, values: {key: value}, saw}.

• Its validation checks every key against the sport's catalogue, as action keys are checked today (check_values, projections.py:444).
• Its writer (workflows/writers/lines.py, new) upserts one stat_value row by its unique key uq_stat_value_line (fixture_id, subject_id, subject_role, segment, occurred_on).
• It sets last_seq to the new log number, and pins the keys it set, so an import does not overwrite them. This is the same pin rule edit_side uses today (workflows/writers/fixtures.py:6-12).
• Its version check covers only the rows it changes (S13). Two operators fixing different batters never block each other. Two fixing the same batter: the second gets conflict.

The user's note on S12: "sometime we need to manually update scorecard in edge cases". That is why the line command is needed even for events matches (S14).

A correction, step by step Agreed, to build

The third umpire changes ball 140 (a four becomes a six) at ball 600. Checkpoints exist at 50, 100, 150, and so on.

Cost: reading 600 log rows took 3 ms median locally (measured, design doc); 500 steps at under 0.1 ms each is under 50 ms (estimate). A correction gets a CPU budget of 2 s, not 50 ms (M4). An undo of the last ball is the same with at most 49 steps.

Undo and correction are two different fixes (S7), the same split Sportradar uses. Undo takes back the most recent event. Correction changes any past event and says what changed. Both are new events. Nothing in the log is ever changed.

The background check Agreed, to build

BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY;   -- one consistent picture, takes no lock
SELECT last_seq, code_sha, state_hash FROM scoreboard WHERE fixture_id = $match;
SELECT * FROM timeline_item WHERE fixture_id = $match AND seq <= $last_seq ORDER BY seq;
COMMIT;

It replays the effective log from an empty state with the match's own code, hashes the answer, and compares it with state_hash. It runs every 5 minutes for every live match, at every match end, and after every deploy. A full Test match is about 2,700 steps, under 0.3 s (estimate). It never holds the match lock, so scoring does not wait for it.

On a mismatch it does not write the state itself. It sends a "rebuild state" command on the normal road, so the repair is logged and takes the lock like any other change. It raises an alert with the match and the first ball where the two differ (M5). It runs in the worker service (core/.../engine/verify.py, new), not the command service.

Is hashing fast enough? Measured 6 Oct: sha256 of a 10 KB state takes 0.0044 ms (4.4 µs); turning it into canonical JSON, which is needed anyway, takes 0.05 ms.

Today's nearest thing is pipeline.rebuild (pipeline.py:1196-1216), run by hand from the admin route or the worker command line. It clears and refolds without taking the lock.

Code versions side by side Agreed, to build

• Each published version of the flows plugin is installed into its own folder at deploy: /opt/omnium/flows/<version>/ (pip install --target).
• The sport worker processes start per sport and version, with Python's spawn method and only that folder on the path. Two versions never share memory or imports.
• A deploy adds a version. It never replaces one that a live match uses. Old versions are removed after the last match on them is final.
• On every ball the engine compares the match's code_sha with the worker's. A mismatch refuses the ball ("try again" plus an alert) rather than score it with other rules.

Why a new fingerprint. Today's impl_sha hashes one function's own source text. A change to a helper or a constant that the function uses does not change it. So the new code_sha is the sha256 of the wheel's RECORD file. RECORD is the file inside every Python wheel that lists each file in the package with its own hash, so any change anywhere in the package changes it. It is stored on scoring_program_version at publish and on the scoreboard row at the first event, and checked on every ball.

Sport worker processes Agreed, to build

The sport's code runs in small worker processes inside each command container, not on the web server's thread (Section 4, L10). Only events mode needs them; apply mode never starts one. A worker is a process, not a container: 50 sports never means 50 containers. Workers start only for a sport that has a live events match, and stop 30 minutes after its last one.

Messages are one request and one reply per call, as length-prefixed JSON over the worker's pipe:

{"id": "7f3a", "op": "check_and_step", "sport": "cricket", "state": {}, "events": [{}]}
{"id": "7f3a", "ok": true, "refusal": null, "step": {"state": {}, "lines": [], "emits": ["wicket"]}, "cpu_ms": 0.08}

The op replay takes many events (a correction, the background check) and returns the final step plus the state at every 50th event, for checkpoints.

A looping rule is stopped by the wall-clock kill: Python cannot interrupt a thread, but a process can always be killed. Pool size: 2 warm workers per container and sport version, up to 4. About 100 MB per worker (estimate, to be measured).

Today the components run in the same process as the web server, with no way to interrupt them. The interim guard is a per-transaction statement_timeout and idle_in_transaction_session_timeout of 10 s (pipeline.py:824-842, settings.py:290).

Settings Agreed, to build

The limits are server settings the worker reads when it starts. They are not sent with each message and not shown in any screen (changed after the user's comment on 6 Oct).

Answer codes Agreed, to build

Module layout Agreed, to build

Today there are two engines: workflows/engine.py (apply once) and scoring/pipeline.py (fold). They become one package, omnium_core/engine/, with the two modes inside it.

Migration order Agreed, to build

One step at a time, each shippable and tested on its own. Live scoring is not on prod, so nothing live is at risk.

1. ledger.append checks players before it writes (bug fix, Section 4).
2. engine/ with road.py and scorecard.py; Games and Results move onto it; workflows/engine.py removed.
3. results.set_line and writers/lines.py. Scorecard mode is then complete.
4. The step contract, workers.py and code_sha; the fingerprint check turned on.
5. Football gets a step function and a small state; its golden matches must give the same answers through the new path.
6. events.py, state.py and corrections.py; football runs on them.
7. verify.py in the worker service.
8. Cricket gets a step function. This is the larger job: its state today carries every delivery.
9. The other sports move over; scoring/pipeline.py is removed.

Tests that prove it Agreed, to build

When things go wrong

Every case ends with the right score and nothing counted twice. The last column names the decision that covers it.

Decisions

All 23 decisions of Section 5 were agreed on 6 Oct 2026.

Scorecard (most matches)

Events (a few sports)

Engineering

Built today, or still to build

Checked in the code on 7 Oct 2026 (branch feat/result-feeds).

Numbers

Read next

• Commands and the workflow engine: the one road around this engine: key, lock, version check, answer.
• Writing a workflow in code: how a sport's commands, validations and actions are written, line by line.
• Sport plugins and rule versions: the step contract per sport, versions side by side, and the catalogue of line keys.
• Bridge and live updates: how a second screen sees the new score.
• Stats, feeds and delivery: what happens after the outbox note.