This was a pilot-stage platform for processing and managing traffic-violation data produced by multiple AI-camera sources at monitored traffic points. Rather than working directly with raw video or computer-vision models, the system focused on the downstream layer: receiving detection events, processing asynchronous data, correlating related results, and converting them into operational vehicle and violation records.
At a monitored point, the same vehicle could be detected by multiple cameras and at different moments in time. Results did not arrive simultaneously; cameras on the same side could produce detections at slightly different times, while detections from opposite sides of the tracking point could arrive further apart depending on vehicle speed and direction.
Because of this, the backend could not simply persist each detection independently. A dedicated correlation and aggregation step was required to identify detections that likely belonged to the same vehicle, group related results, combine violation signals, and produce a unified instance for downstream review and enforcement workflows.
Role & Scope of Contribution
My direct ownership focused on NestJS backend processing after detection events had already been forwarded into the system through a message queue.
My main contributions included:
consuming and processing asynchronous detection events;
implementing multi-stage license-plate matching, using exact matching first and a similarity heuristic for partially mismatched OCR results;
handling incomplete states when data from both sides had not yet arrived and retrying correlation in subsequent processing cycles;
aggregating multiple detections into a unified vehicle/violation instance while deduplicating repeated violation types in the final result;
persisting completed instances in MSSQL;
publishing WebSocket events from the backend when new instances were created to support near-real-time operational updates;
directly implementing business-facing interfaces for violation lookup, violation/penalty configuration, issuing violation notices, and editing records before final processing.
Pilot-Stage Processing Approach
During the pilot phase, the system used a short aggregation window to balance two competing goals:
allowing enough time for related detections from multiple cameras to arrive;
keeping the operator experience close to real time.
If an instance did not yet contain enough data in one processing cycle, it could remain in a temporary state and be correlated again in the next cycle. Cases that still could not be matched were routed into a separate handling path rather than being forced into a normal instance.
During manual pilot checks over short observation windows, the pipeline achieved approximately 95% observed aggregation coverage during daytime and around 80% at night. Lower nighttime coverage was mainly associated with upstream recognition conditions such as poor lighting, higher vehicle speed, large vehicles blocking one another, or unreadable/obscured license plates.
These figures represent observed pilot aggregation coverage, not AI model accuracy.