NotifYC

Inspiration

Cities already have thousands of traffic and security cameras watching our roads every day. But we kept coming back to one problem: most of those cameras are passive. They can capture an incident, but someone still has to be watching the right camera at exactly the right time to notice it.

Then we started thinking about an even harder situation: what happens when multiple incidents happen around the same time, but there aren't enough response resources for all of them?

At that point, simply detecting an incident isn't enough. An operator needs to understand what happened, which incidents may need attention first, why they were prioritized, and which available responder could actually get there.

That's what inspired NotifYC - a traffic incident awareness and prioritization system that turns existing camera footage into structured, actionable information.

What it does

NotifYC monitors multiple traffic-camera feeds and uses computer vision to follow vehicles over time.

Instead of looking at a single frame and trying to decide whether a crash happened, we analyze how vehicles actually move and interact. We look at things like their trajectories, whether they're moving toward each other, changes in separation, projected path convergence, proximity, and how their movement changes around an interaction.

When the system finds enough evidence to surface a possible traffic incident, it creates an incident with the relevant visual and motion evidence.

But that's where we think the more interesting part of NotifYC begins.

If several incidents happen at once, NotifYC assigns each one an operational response priority - P1, P2, or P3 - based on the observable evidence from the camera.

We were very intentional about calling this operational priority rather than trying to predict injuries or medical severity. A traffic camera can't reliably tell us everything happening inside a vehicle.

Instead, our goal is to help an operator answer a more realistic question:

Which incident appears to need attention first based on what we can actually observe?

From there, NotifYC looks at responder availability and location and can assign an appropriate available simulated response unit.

How we built it

We built the computer-vision pipeline in Python using Ultralytics YOLO11, ByteTrack, and OpenCV.

YOLO11 detects vehicles in each frame, ByteTrack helps us maintain vehicle identities over time, and our custom motion-analysis pipeline examines trajectories and interactions between tracked vehicles.

For the command center, we used React, TypeScript, and Vite. It gives an operator one place to view camera feeds, incidents, operational priorities, evidence, and simulated response units.

We also wanted NotifYC to go beyond simply putting an alert on a dashboard, so we connected several technologies into one end-to-end workflow:

DeepSpace powers our real-time incident and responder infrastructure, connecting cameras, incidents, responders, and assignments.
xAI Grok takes the structured evidence generated by our system and turns it into a concise, human-readable responder briefing. Grok doesn't decide whether a collision happened or determine the priority it explains the evidence our system already produced.
ElevenLabs turns that briefing into audio, making the information easier to consume without having to read raw technical metrics.
Photon's Spectrum SDK provides our prototype communication layer for delivering responder information to an authorized test device.
Cursor helped us move quickly throughout the hackathon as we iterated on the computer-vision pipeline, integrations, backend, and frontend.

The easiest way to describe the whole system is:

Detect → Track → Analyze → Prioritize → Route → Brief → Respond

Challenges we faced

One of the biggest things we learned this weekend was that detecting a vehicle is much easier than understanding what two vehicles are actually doing.

Early on, it was tempting to treat things like overlapping bounding boxes as evidence of a collision. We quickly realized that wasn't reliable enough.

Vehicles can become occluded. Tracking IDs can change. A vehicle can temporarily disappear from detection. Camera perspective can make two vehicles look much closer than they actually are. And sometimes the most important interaction happens within just a handful of frames.

That pushed us away from relying on a single detection or confidence score and toward looking at movement over time.

Prioritization created another interesting challenge. We didn't want to build a system that looked at CCTV footage and confidently claimed someone was injured or that one crash was medically more severe than another. The footage simply doesn't give us enough information to make those claims responsibly.

Instead, we focused on what the system can observe and built an operational-priority system around that evidence while keeping a human operator in the loop.

Finally, getting everything to work together was a challenge of its own. We weren't just connecting a frontend to a model - we were connecting computer vision, incident management, prioritization, responder assignment, generative AI, text-to-speech, and messaging into one workflow.

What we learned

Our biggest takeaway from building NotifYC was that a useful AI product is about much more than the accuracy of a single model.

The model is only one part of the system.

Computer vision can help us surface evidence. Deterministic logic can organize and prioritize it. A language model can make technical information easier to understand. A real-time backend can coordinate incidents and resources. And communication tools can get that information to the person who actually needs it.

We also learned how important it is to be honest about uncertainty.

Rather than pretending the AI always knows exactly what happened, we designed NotifYC to surface a possible incident, show the evidence behind it, and support the person making the final decision.

That shift in thinking ended up shaping a lot of the project.

What's next

NotifYC is currently a hackathon prototype built around a controlled demo camera network and simulated response units, but there are a lot of directions we'd love to explore next.

We'd like to improve tracking through occlusions, add better camera and road geometry calibration, evaluate the system across a much larger and more diverse set of traffic footage, explore cross-camera incident understanding, and build a stronger human-in-the-loop review experience.

Longer term, we'd also like to explore how the system could work with existing authorized camera infrastructure rather than requiring cities or organizations to replace the cameras they already have.

At its core, the idea behind NotifYC is pretty simple:

The cameras are already watching. We want to help turn what they see into information people can actually act on.