Semi-Automated Offside Is the Best Human-in-the-Loop AI Design I Have Seen This Year

The tournament is over. Spain beat Argentina 1-0 in extra time at MetLife on 19 July, Ferran Torres scored in the 106th minute, and somewhere in a windowless room a group of engineers exhaled for the first time in five weeks.

I want to talk about their system, because semi-automated offside technology at this World Cup is the cleanest production example of human-in-the-loop AI I have looked at all year — and most enterprise teams building AI implementation projects are getting the same problem wrong.

The problem is harder than “draw a line”#

Offside sounds like geometry. It is not. It is a question about a moment: at the instant the ball was played, was any part of the attacker’s body that can legally score ahead of the second-last defender?

That single sentence hides three genuinely difficult engineering problems.

You need the exact instant. Broadcast cameras run at roughly 50 frames per second. That gives you a 20 ms bucket. A foot can travel a meaningful distance in 20 ms at sprinting speed, and the touch that starts the passage of play is frequently ambiguous on video — a glancing deflection off a shin looks like nothing.

You need body geometry, not a dot. “Any part of the body that can legally score” means shoulders and knees count, hands do not. A centroid is useless. You need a pose.

You need it fast enough to matter. A decision that arrives four minutes later has already cost the sport more than the error it corrected.

How the system actually resolves each one#

The 2026 build attacks the three problems with three different sensors, which is the whole point.

The timing problem is solved in the ball. The adidas Trionda match ball carries an inertial measurement unit sampling at about 500 Hz — 500 readings per second, an order of magnitude finer than the video. That IMU does not know where the ball is. It knows when it got hit. A sharp acceleration spike is an unambiguous, precisely timestamped kick event.

The geometry problem is solved in the cameras. A calibrated array mounted around the stadium roof — reported at 12 to 15 units depending on the venue — does skeletal tracking on every player, producing limb positions rather than blobs. FIFA scanned all 1,248 players across the 48 squads before the tournament, so the system fits a known body model to each tracked player rather than guessing proportions from pixels. The reported precision threshold tightened to roughly 10 cm for 2026.

The speed problem is solved by not asking the model to be right. It only asks the model to be fast and to show its work.

The part everyone skips: it is semi-automated on purpose#

Here is the design decision I keep pointing at in client workshops. FIFA had every technical justification to close the loop. The sensor fusion is good. The margin is tight. They could have automated the call outright.

They did not. The system raises an alert, produces a 3D reconstruction, and hands it to a video match official who confirms or rejects it. A human owns the decision. The machine owns the evidence.

That is not timidity. It is a correct read of three things most AI implementation projects misjudge:

• The cost function is asymmetric. A wrongly disallowed goal is not twice as bad as a missed foul throw. It is categorically worse. When your error costs are lopsided, you do not optimise for average accuracy — you put a reviewer on the expensive branch.
• Edge cases are not rare here, they are the entire workload. The system only fires on close calls. By construction, every input it processes sits near the decision boundary. Your holdout accuracy on typical cases tells you nothing about performance on the distribution you actually run against.
• Legitimacy is a system requirement. The output has to be accepted, not merely correct. The 3D avatar rendering shown on the stadium screens exists for that reason. It is an explainability layer with a stadium-sized audience.

I have watched teams spend a quarter arguing about whether their model is accurate enough to remove the human reviewer, when the honest answer was that the reviewer was never the bottleneck. The bottleneck was that the reviewer had to gather evidence manually. Automate the evidence, keep the judgement, and you get most of the speed with none of the liability.

Where this maps onto work that is not football#

Swap the nouns and this is a pattern we deploy constantly.

In a Hospital Management System, sepsis and deterioration alerting has the same shape. Vitals stream at high frequency, notes and labs arrive at low frequency and irregular intervals, and the clinically interesting question is about a moment — when did this patient start turning? The cost function is brutally asymmetric in both directions: a missed deterioration kills someone, an alert storm gets the whole system muted by week three. The correct design is not an autonomous escalation bot. It is a high-recall detector that assembles the evidence — trend, contributing signals, comparable prior admissions — and puts a clinician in front of it with the review already done.

In a School ERP, the same architecture underpins at-risk-student flagging. Attendance, assessment scores, and fee status arrive on completely different clocks. The model’s job is to surface the child and show the pattern. A teacher makes the call, because the model does not know the student’s father lost his job in March.

The general rule: when your event timestamps come from a fast sensor and your semantics come from a slow one, fuse them rather than downsampling to the slower clock. Most data platforms quietly do the opposite. They bucket everything to the coarsest available granularity because it makes the join easy, and they throw away exactly the resolution that made the hard cases decidable.

What I would take into a design review tomorrow#

Three questions the offside system answers well and most production AI does not:

1. What is the finest clock in your pipeline, and are you preserving it? If a downstream aggregation rounds your 500 Hz signal into a one-second window, you have deleted the reason the sensor exists.
2. Who owns the decision, and do they have the evidence in one place? If your reviewer has to open four systems to validate a model output, you have not built human-in-the-loop. You have built human-in-the-way.
3. Can the output be explained to a hostile audience in under ten seconds? A visual reconstruction beat a confidence score, and it will beat one in your product too.

The tournament produced 104 matches of continuous, adversarial, globally scrutinised operation. That is a harsher eval harness than anything in your CI. The system that came through it was not the most autonomous one available. It was the one that knew which decisions to keep and which to hand back.

---

Most AI projects fail at the seams — the clocks, the joins, the handoff to whoever actually decides. That is where we spend our time. If you have a model that works in a notebook and stalls in production, tell us where it stalls.