Rugby is unusually hostile to analysis. Play is close to continuous, possession changes without stopping the clock, and most of what decides a match happens in contact, where the ball is frequently invisible. Compared with a sport built from discrete, well-separated events, it resists easy measurement.

It is also, underneath, highly structured — and that structure is what makes it tractable.

A match is already a data structure

The laws impose a grammar. Play proceeds through phases. Possession is won and lost at identifiable moments. Set pieces — scrum, lineout, restart — are discrete, bounded events with known participants. Even open play decomposes into a recognisable vocabulary: carry, tackle, ruck, pass, kick, turnover.

An event stream captures these as a time-ordered sequence of records. Each carries, at minimum, a timestamp, an event type, the players involved, a location on the pitch, and an outcome. A match becomes a few thousand such records.

The quality of everything downstream depends on decisions made at this layer. Two questions matter more than they first appear:

  • What counts as an event? A ruck is obvious. "Line-speed" is not an event at all — it is a property derived from positional data across many frames. Systems that conflate the two produce numbers nobody can reproduce.
  • Who decides? Human annotation is accurate and slow. Automated detection is fast and confidently wrong at the margins. Most serious systems use both, and — importantly — record which produced each event.

From events to state

A list of events is not yet useful. The useful object is match state: at any moment, who has the ball, where, in what phase, with what personnel, under what score and time pressure.

State is reconstructed by folding the event stream forward. This sounds trivial and is not. Events arrive out of order. Some are corrected after the fact. A system that treats its event log as append-only and derives state as a pure function of that log can replay, correct and audit itself. One that mutates state in place cannot explain how it reached its current view.

This is the same architectural discipline as event sourcing in financial systems, and for the same reason: when the answer matters, you need to be able to reconstruct exactly how you got there.

Why a graph rather than a table

Interesting questions in rugby are questions about relationships.

How does this side's defensive shape change when a particular player leaves the field? Which combinations have historically produced turnovers against this kind of attacking pattern? These involve players, teams, positions, matches, competitions and phases of play, all connected.

Expressed in relational tables, such questions become deep, expensive joins whose structure has to be anticipated when the schema is designed. Modelled as a graph — entities as nodes, relationships as edges — traversal is the native operation. New questions do not require new schema.

The gain is not raw speed. It is that a graph lets you ask questions you had not thought of when you built it, which is precisely what analysis consists of.

The latency problem

During a live match, insight has a shelf life. An observation about defensive fatigue is valuable while there is still time to exploit it and worthless at full time.

This constrains the architecture. Everything on the path from event capture to surfaced insight has to be streaming rather than batch: ingestion, state reconstruction, derivation, delivery. A nightly job cannot participate.

It also constrains what can honestly be claimed. Some questions genuinely require the whole match, or the whole season, and cannot be answered mid-game. The correct response is to say so, rather than to answer early on thin evidence and present it with the same confidence as a settled conclusion.

What the data will not tell you

Event data records what happened. It does not record intent, and the gap between the two is where most overconfident analysis lives.

A kick that goes out on the full is a recorded error. Whether it was a mistake depends on what the kicker was trying to do, what they could see, and what they had been told at the last stoppage — none of which is in the stream.

The honest position is that event data constrains interpretation rather than replacing it. It rules out explanations inconsistent with what happened, narrows the plausible range, and quantifies what can be quantified. Handing a coach a well-supported narrowing of the possibilities is genuinely valuable. Handing them a confident conclusion the data cannot support is how analytics loses a dressing room.