Latency that lands inside the repricing window

"Low latency" is a marketing word until you say relative to what. For a sports-data buyer, the only clock that matters is the market's: how long after a score does the price move, and can you be there first?

The repricing window

When a team scores, the betting market reprices — but not instantly. There's a window between the event happening in the building and the line fully adjusting everywhere. Data that arrives inside that window is actionable. Data that arrives after it is just a record. Everything we build is aimed at landing inside that window.

Where the time goes

A relayed feed adds hops: the event happens, an operator keys it, it travels through one or more intermediaries, then reaches you. Each hop is latency you don't control. Collecting in the venue removes the relay — the first hop is a fan in the stands, and the second is our edge.

Speed vs certainty is a dial, not a fixed point

The fastest possible signal is a single report — but a single report can be wrong. Full consensus is trustworthy — but waiting for it costs milliseconds. So we expose both:

• provisional — the first credible report, tagged. Maximum speed; you accept a small revision risk.
• confirmed — consensus cleared. Slightly later; you trade on certainty.

You pick per stream. A market-making desk might take provisional for the initial nudge and confirmed to true up; a settlement system might only ever want confirmed.

Confidence travels with the data

Every event carries agreement, reporters, and latency_ms. That means you don't have to treat the feed as binary — you can build your own policy: act on provisional events above a confidence bar, wait for confirmed below it. The data gives you the inputs to make that call yourself.

Fast and right

The point isn't to be the fastest at the cost of being wrong, or the most accurate at the cost of being late. It's to put both knobs in your hands and ship the evidence to set them.