0 %
Overview

A public-safety
intelligence console.

Built By:
Arvish Pandey
Mikhail Nikolaenko

Most people do not need more data. They need clarity. That was the starting point behind Project HORIZN - our flagship initiative.

Cities already live inside a flood of fragmented signals: forecasts, environmental conditions, emergency calls, incident reports, camera feeds, operational updates, and human judgment moving in parallel. The problem is not that information does not exist. The problem is that it rarely arrives in one place, in one language, or at the right level of urgency.

HORIZN was shaped around that gap. It was designed as a hazard intelligence platform that could gather different kinds of urban risk signals, interpret them together, and present them through one operational interface built for action rather than passive monitoring.

The platform was shaped around the logic of Cincinnati 311 and 911, where environmental stress, public safety pressure, and local decision-making do not exist in neat academic categories. A weather spike can become an infrastructure problem. A street-level anomaly can become a public safety problem. A weak interface can make both harder to interpret. HORIZN was designed to sit in the middle of that tension and turn it into one decision-support surface. Instead of forcing an operator to bounce between raw camera footage, weather readings, static maps, and fragmented alerts, the system pulls those signals into one visual environment that can be read quickly and acted on faster.

5+ Billion

Environmental & Video Signals Handled

Pure E2E

From Data Management to Full-Stack Deployment

Real-Time

Custom API-driven risk interface

Challenge

Streamlining
Command-Gen

HORIZN challenge

On the weather side, the challenge was never just forecasting. It was scale, structure, and trust. The backbone came from NOAA data, especially long-horizon station observations and storm-event records, because the goal was to build on sources that reflect real environmental behavior over time rather than one-off synthetic examples. GHCN mattered because it gave the project a historical weather spine, station by station, day by day, across years of temperature, precipitation, snowfall, wind, and related environmental variation. In plain terms, that meant the model was not being trained on a few dramatic weather clips or a thin spreadsheet. It was being forced to learn from a national-scale history of conditions, patterns, and edge cases.

That is where the size of the pipeline starts to matter. Once those historical weather inputs were cleaned, aligned, and transformed into lagged and rolling features, the weather branch was dealing with more than 5 billion feature values. That number matters because it changes the entire character of the system. It means HORIZN was not making claims off a lightweight demo dataset. It was compressing years of distributed environmental behavior into a trainable structure, then pushing that structure through a machine-learning workflow that had to survive missingness, imbalance, noisy labels, and the very real messiness of public weather data. The scale was not there for decoration. It was there because city-facing intelligence systems do not get to pretend the real world is tidy.

HORIZN challenge

On the public-safety side, the design problem was different but just as serious. Static object recognition was not enough. The question was how to detect behavior or scenes that deserve attention without drowning the system in noise. That is why the vision pipeline leaned on YOLO and ResNet in different roles rather than asking one model to do everything. YOLO made sense because it is fast, spatially sharp, and well-suited for locating people in crowded or messy camera frames. It does the first hard job well, which is finding where to look. Once that person-focused view exists, ResNet becomes useful for the second job, which is classification under harder visual conditions. ResNet is not there as a trendy name drop. It is there because it is strong at extracting stable visual features from imperfect inputs, whether the system is judging a cropped person region or the broader scene around them.

That division of labor matters. A city camera feed is not a clean benchmark image. It has motion, glare, occlusion, inconsistent angles, crowd overlap, and all the other ugliness that makes real-world computer vision expensive. HORIZN addressed that by treating detection and interpretation as separate stages. Frames were sampled and preprocessed, YOLO localized human activity, and ResNet-based classifiers helped score either person-focused or scene-focused risk. Those outputs were then aggregated over time instead of being trusted frame by frame. That temporal aggregation is one of the reasons the platform feels more operational than theatrical. It is not reacting to every flicker in the feed. It is trying to stabilize judgment before surfacing a hazard decision.

Design

Data Management
& Artifact Generation

Direction

Where the project became more than two strong technical branches sitting next to each other was the fusion layer. The weather branch was producing risk structure from historical modeling and live conditions. The vision branch was producing anomaly evidence from the visual environment. Neither one, by itself, was enough to define the full situation. HORIZN became interesting when those streams were allowed to inform a common console. That is why the methods matter less as isolated buzzwords than as parts of a sequence: historical weather modeling, live signal refresh, camera-based anomaly scoring, backend fusion, and a frontend decision surface that makes all of it legible.

Execution

That backend layer did more work than it gets credit for. It was not just there to serve files. It had to load trained artifacts, ingest live official weather signals, manage refresh behavior, reconcile state changes, and expose all of that through an API that the console could actually use. On the frontend, the same principle held. A generic dashboard would have wasted the project. The interface had to do what the methods alone could not: make the system readable under pressure. That is why HORIZN evolved into a live console instead of a notebook with graphs. The map, hazard spectrum, scenario controls, tracked zones, official alerts, and visual overlays were all built to answer the same question: what should a human understand first, and what should they notice next?

HORIZN result screenshot
01 / Vision Intake

Frame sampling splits raw footage into person-focused and scene-focused analysis paths.

02 / Model Logic

YOLOv8 localizes human activity while ResNet18 classifiers score person and scene anomaly risk.

03 / Decision Layer

Temporal fusion stabilizes frame-level predictions before hazard decisions and clip extraction.

Result

The result is a platform that reads like an urban intelligence layer rather than a single-purpose classifier. Its purpose is not to impress with one isolated metric or one polished widget. Its purpose is to pull environmental sensing, predictive analytics, computer vision, and interface design into one working logic. The weather branch contributes modeled risk built from historical atmospheric behavior and live public-weather signals. The vision branch contributes scene and activity awareness from real video conditions. The backend fuses them. The frontend translates them into something that feels immediate rather than academic.

Build

Evolution
& Improvements

what changed, what got stabilized, what became stronger, and what the final system represents

01 / Live Inputs

Official alerts, live conditions, and model state are compressed into one readable operating view.

02 / Risk Fusion Engine

Scenario modes translate changing hazard conditions into confidence-backed risk scores and action cues.

03 / Console Surface

Maps, alert theater, tracked zones, and response cards prioritize what an operator reads first.

01 / City Layer

Predicted and recent incidents are pinned against the map instead of buried in separate logs.

02 / Evidence Layer

Each alert carries confidence, clip timing, location context, and recent event history.

03 / Action Loop

Verify, escalate, and publish controls turn detection output into an operator decision path.

That is also why the project’s evolution matters. Early versions proved that the idea had shape, but later iterations forced the team to ask sharper questions about what was truly reliable, what needed to be stabilized, and what kind of interface could carry that weight without becoming cluttered or hollow. Some improvements were deep in the pipeline, like feature engineering, model scoping, and signal fusion. Others were visible, like the operational console, national alert theater, tracked-risk views, and interactive hazard overlays. Together, those changes moved HORIZN away from being a class exercise in isolated modules and closer to something that feels designed for actual response environments.

To conclude, HORIZN is best understood as a city-facing hazard intelligence system built around one belief: if raw signals stay raw, they arrive too late to be useful. Weather patterns, anomaly detection, and public-safety context all matter, but they only become valuable when they are translated into a unified view that can guide attention. That is what this platform set out to build. Not a weather app. Not a camera demo. Not a stack of disconnected models. A system that takes complexity seriously, then turns it into something an operator can read.

01 / Visual Intake

Street-level footage is sampled into analyzable frames under motion, glare, occlusion, and noise.

02 / Threat Focus

Person-centered detection isolates activity worth reviewing without treating the whole frame as truth.

03 / Review Signal

Visual evidence and confidence scoring give the console something concrete to surface, not just a label.

Contact

Just say hello!

Want to know more about me, tell me about your project or just to say hello? Drop me a line and I'll get back as soon as possible.

Done!

Thanks for your message. I'll get back as soon as possible.
Template background image
Template background image