Technical report
How it works, and what we don't know yet
The design is settled; several measurements are not. Anything not yet measured is listed as an open item rather than filled in with a number that would read well — there are 20 of them on this page.
01
Problem
Given an MP4 from a fixed road camera, produce a list of traffic events as time segments — a start second, an end second and one of 14 class labels — and, separately, a per-frame score between 0 and 1 for the probability that an accident begins within the next 5 seconds.
The two outputs are scored independently, and they pull in different directions. Event detection rewards precise boundaries on things that have already happened. Anticipation rewards a causal signal that rises before anything has happened at all. Treating them as one problem produces a system that is late on both.
02
Data
The organiser sample clips from a single fixed camera, plus the annotations released with them. Because every clip comes from the same viewpoint, scene geometry can be calibrated once and treated as known for all of them.
Class balance is the dominant property of this data: ordinary violations are common, collisions are rare, and fire or smoke may not appear at all. Any metric that averages over classes has to be read with that in mind.
Open items
- Record the exact clip count, total duration and per-class annotation counts once the final data pull is fixed.
- State which clips were used for development and which were held out, and confirm no held-out clip informed a threshold.
03
Exploratory analysis
Trajectories collapse onto two carriageway corridors plus a pedestrian crossing; motion density concentrates in a small fraction of the frame. Both findings argue for spending effort on scene calibration rather than on generic whole-frame modelling.
Lighting varies across the sample set from midday to night. The night clip carries noticeably fewer tracks at a comparable apparent density, which is the signature of a detector dropping small, poorly-lit road users rather than of a quieter road.
The full analysis, with the decision each chart led to, is on the EDA page of this site.
04
System architecture
Decode at a fixed stride, detect road users, track them into trajectories. After tracking the pipeline forks: one branch applies scene geometry and traffic rules to produce event segments, the other computes interaction features between track pairs to produce the risk curve.
The fork matters for debugging. A missed event and an under-confident risk curve have different causes and are fixed in different places, and keeping the branches separate keeps that distinction visible.
05
Object detection
A single-stage detector proposes boxes for six classes: car, truck, bus, motorcycle, bicycle and pedestrian. Input resolution is chosen by the smallest pedestrian that has to survive, which in practice is set by the night clip rather than by any daytime footage.
Open items
- Name the detector architecture and weights actually shipped, and whether they were fine-tuned or used as released.
- Record input resolution, confidence threshold and NMS settings.
06
Tracking
Detections are associated across frames so each road user keeps one identity for as long as it is visible. Short occlusions are bridged rather than allowed to split a track, because a split track breaks every rule that reads trajectory history.
Identity stability, not raw detection accuracy, is the property most rules actually depend on.
Open items
- Name the tracker and its association parameters.
- Report identity switches per clip, the number that predicts rule failures best.
07
Scene geometry
The road polygon, lane polygons with expected directions, stop lines, crosswalk, intersection box, solid markings and the signal region are calibrated once for the camera and reused across clips.
This is the cheapest accuracy available in the whole system. It converts several classes from open vision problems into geometry tests, and it makes failures inspectable: a wrong-way false positive usually means a lane vector is wrong, not that a model is confused.
Open items
- Replace the placeholder calibration in config/scene.ts with the measured one, and state the tool it was produced with.
08
Event detection rules
Where the traffic code has a crisp definition, the definition is encoded rather than learned: wrong-way driving as a sustained heading opposite the lane vector, stopped vehicle as displacement under a threshold for at least ten seconds inside the road polygon, jaywalking as a pedestrian centroid inside the road and outside every crossing, solid-line crossing as a trajectory intersecting a calibrated line.
Rules are deterministic, cheap and inspectable, and each one names the geometry it depends on. That is what makes a false positive traceable to a specific polygon.
Open items
- Publish the final threshold table — durations, distances and hysteresis margins — and how each value was chosen.
09
Accident and near-miss logic
Collisions and near misses resist a clean geometric definition, so they are decided from interaction features over track pairs: relative motion, path intersection, time-to-collision, and the deceleration and heading changes around the moment of conflict.
The distinction between the two classes is what happens after the conflict. A near miss is a low time-to-collision where both tracks survive and never overlap; a collision is where they do.
Open items
- State whether the interaction model is learned or threshold-based in the shipped system, and what it was fitted on.
10
Accident anticipation
The risk head answers one question per frame: what is the probability that an accident starts within the next 5 seconds. It is causal by construction — it may only read frames up to the current one.
Time-to-collision is the strongest available signal, but it over-fires in dense traffic where everything is already slowing. Deceleration, heading change, lane context and local density are combined with it so that ordinary congestion does not read as imminent collision.
The property to check is lead time, not peak height: a curve that spikes after impact has detected a crash rather than anticipated one, and would be worthless in operation even if it scored well.
Open items
- Report measured lead time — how far ahead of annotated impacts the curve crosses the alarm threshold.
- Report the false-alarm rate on clips with no collision, which is what determines whether an operator would keep the alarm switched on.
11
Temporal post-processing
Per-frame decisions are noisy, and the evaluation reads segments. Fragments of one class are merged across short gaps, segments below a minimum duration are dropped, boundaries are snapped to where evidence actually begins and ends, and two segments of the same class are never allowed to overlap.
This stage changes scores more than most model choices do, because it is what converts a correct-but-flickering signal into a segment that matches an annotation.
Open items
- Record the merge gap and minimum-duration values per class, and the score change each contributed.
12
Experiments
The ablation table below is the intended experimental frame: measure the contribution of tracking, scene rules and temporal smoothing separately, so the score can be attributed rather than guessed at.
Open items
- Run each ablation and fill in content/ablations.ts. Rows without measurements render as pending and are never presented as results.
Ablations
What each stage is worth. The plan is fixed; the numbers arrive with the evaluation run.
No ablation has been run yet. Rows below describe the planned configurations — none of them carries a score.
| Configuration | Adds | Score A | Score B | Runtime |
|---|---|---|---|---|
| Detector only | Per-frame boxes, no identity and no history. | not measured | not measured | not measured |
| + Tracking | Persistent IDs, which makes trajectory-based rules possible at all. | not measured | not measured | not measured |
| + Scene rules | Calibrated lanes, stop lines and crossings driving the rule engine. | not measured | not measured | not measured |
| + Temporal smoothing | Fragment merging, noise removal and boundary refinement. | not measured | not measured | not measured |
| + Conflict features for risk | Deceleration, heading change and density gating on top of time-to-collision. | not measured | not measured | not measured |
Headline metrics
Filled in from the official evaluation, and from nowhere else.
- Score A
- not measured
- Event-detection score from the official metric.
- Score B
- not measured
- Accident-anticipation score from the official metric.
- Throughput
- not measured
- Frames per second on the evaluation machine.
- Runtime ratio
- not measured
- Wall-clock processing time divided by clip duration.
13
Runtime and optimisation
Inference runs offline on the evaluation machine with no hosted AI service. Frame stride is the main runtime control: detection dominates cost, and the stride sets how often it runs.
No real-time claim is made anywhere on this site, because no runtime measurement has been taken yet.
Open items
- Measure throughput in FPS and the ratio of processing time to clip duration, on the stated hardware.
- State the hardware the measurement was taken on.
14
Failure cases
The categories below are the ones this design is structurally vulnerable to, listed before measurement rather than after, so they can be checked rather than rationalised.
Limitations
Where the system struggles
Showing the edges of a system is part of engineering it. These are the failure modes this design is structurally exposed to, written down before measurement so they can be tested rather than explained away.
None of these has been confirmed in output yet, so every card is marked predicted. As real examples are found, each will carry the clip and timestamp it was observed in.
- predicted
Heavy occlusion
A vehicle hidden behind a bus loses its track, and a track that restarts with a new identity breaks every rule that reads history.
Hits these classes first
Near missCollisionStopped vehicleWhat we do about it
Bridge short occlusions in the tracker rather than starting a new identity, and require rules to tolerate a gap.
- predicted
Dense traffic
Time-to-collision is low for everyone in slow, packed traffic, so a naive risk head reads a jam as a stream of imminent collisions.
Hits these classes first
Near missCongestionWhat we do about it
Gate time-to-collision with deceleration and local density, so risk only rises when something is behaving unusually for the conditions.
- predicted
Small distant pedestrians
Pedestrians far from the camera occupy a handful of pixels. Miss them and jaywalking and failure-to-yield never fire at all.
Hits these classes first
Pedestrian on roadwayNot yielding to pedestrianWhat we do about it
Set input resolution by the smallest pedestrian that must survive, not by the fastest configuration that runs.
- predicted
Poor lighting
At night, contrast collapses and headlights bloom. Recall drops for every class, and drops most for the classes that were already small.
Hits these classes first
Pedestrian on roadwayObstacle on roadCollisionWhat we do about it
Keep a night clip in the development set so the failure is visible during tuning rather than at evaluation.
- predicted
Ambiguous signal colour
Reading light colour from a fixed region fails on glare, a partly occluded head, or a lamp that saturates the sensor — and red-light detection depends entirely on it.
Hits these classes first
Red-light runningStop-line violationWhat we do about it
Prefer temporal consistency over per-frame colour, and decline to fire rather than guess when the region is unreadable.
- predicted
Vehicles entering and leaving frame
A manoeuvre that starts off-camera has no history. Boundary timestamps at the edges of the clip are systematically unreliable.
Hits these classes first
Illegal turnWrong-way drivingIllegal U-turnWhat we do about it
Require a minimum observed history before a rule may fire, and accept the recall cost at the frame edges.
- predicted
Unusual manoeuvres
Three-point turns, reversing and service vehicles working in a lane look like violations to rules written for ordinary traffic.
Hits these classes first
Illegal U-turnWrong-way drivingStopped vehicleWhat we do about it
Keep rules narrow and let the class stay unfired, rather than widening a rule until it catches legitimate behaviour.
- predicted
Partially visible collisions
If the impact itself happens behind an obstruction, the only evidence is the aftermath — which arrives too late for anticipation to be scored well.
Hits these classes first
CollisionNear missWhat we do about it
Weight pre-impact conflict features rather than post-impact appearance, so the signal does not depend on seeing contact.
15
What worked
Calibrating the scene once and treating geometry as known — it removed whole classes of ambiguity and made rule failures traceable.
Keeping detection of events and anticipation of accidents as separate branches over shared tracking, instead of one model asked to do both.
Building the visualisation before tuning thresholds. Seeing a risk curve next to its clip makes a bad threshold obvious in seconds, where a metric only says the number moved.
16
What did not work
Open items
- Record the approaches that were tried and dropped, with the reason each was dropped. This section is deliberately empty rather than filled with plausible-sounding failures.
17
What we would build next
Multi-camera calibration, so the same geometry approach extends to a network rather than one view.
Explicit signal-state estimation rather than reading colour from a fixed region, which is the most fragile input in the current design.
An operator feedback loop: let a human confirm or dismiss an alarm, and use those decisions to retune thresholds per camera.
18
External models and datasets
Any pretrained weights, external datasets and third-party libraries used are listed here with their licences, so the submission can be reproduced and audited.
Open items
- List every pretrained checkpoint and dataset with source and licence.
- Confirm each licence permits the use made of it in this submission.
19
Reproducibility
The intended path is: clone the repository, install pinned dependencies, download weights, run inference on a clip, and get the same predictions file that produced the results on this site.
Open items
- Publish the repository, the weights and predictions_samples.json, then fill in config/site.ts so the links on this site go live.
- Pin random seeds and dependency versions, and state the hardware the results were produced on.
Artefacts
Everything the submission publishes outside this site. Links go live as each artefact is released.
Published artefacts
An entry without a URL is shown as unavailable rather than linked somewhere that does not exist.
- not published yet
Repository
Training code, inference service and this website.
- not published yet
Model weights
Detector and interaction-model checkpoints.
- not published yet
predictions_samples.json
Raw event predictions for the organiser sample clips.
- not published yet
Technical report
The written submission, also readable on this site.