Horizon Signal Remotely Manages Hundreds of Traffic Signals With Absolute Security

We built Horizon Signal Plus, a web-based portal for monitoring, managing, and remotely programming Horizon Signal’s IoT traffic signal controllers, treating AI as a development accelerant, never as a decision-maker in the safety-critical logic itself.

What We Delivered

Three access tiers — Basic Monitoring, Advanced Monitoring, and Comprehensive Monitoring — all available at launch, covering device management and live view, mapping and visualization, an alert system, remote programming, and history and logging. Live video and camera feeds followed six to eight weeks after go-live.

Key Technical Achievements

• Deterministic alerting — every alert fires on a regex match against a device log line or a threshold crossing on a specific value, never a model’s inference
• A live hardware test fleet — real test controllers reporting continuously alongside production devices, letting the team validate against actual hardware behavior throughout the build rather than after launch
• Hardware identity that survives physical swaps — serial-number reassignment preserves a device’s full history when a controller is physically replaced in the field

Where AI Did the Work

Claude Code accelerated the build itself, never the product’s behavior. The team specified business logic, database structure, and infrastructure precisely by hand first, and only then had AI help execute against that spec. On the front end, once a strong foundation, library choices, and file conventions were established, the team was comfortable letting AI handle follow-up work against that base. This included generating several design directions for a few lower-stakes features, like log and metrics export. Claude also wrote a large share of the unit tests, particularly around program parsing in both directions.

Where Humans Did the Work

Everything where a wrong formula would change what a real intersection does. AI accelerated the work around signal behavior; it never decided signal behavior. Program parsing correctness, including the timing formulas behind states like “resting red,” was worked out by hand. Program rewriting, where keywords have to move between sections and the result still has to execute correctly on the device, was done manually. Green time metrics, which turned out to be genuinely tricky to calculate correctly, were decided by people, not delegated.

How We Verified It Was Correct, Secure, and Safe to Ship

The client installed a live fleet of real test controllers that report continuously, exactly like production devices. This was the single most valuable verification asset on the project, since it surfaced how real hardware actually behaves while the platform was still being built, not after launch. A device allow list keeps that test fleet running alongside real production traffic without ever touching it. Staging and production run in fully separate AWS regions, with independent IoT endpoints, device sets, and databases. Roughly 1,280 integration tests run real backend handler code against an actual Postgres instance, not mocks, with program parsing heavily covered in both directions. And every commit to the main branch came through a peer-reviewed pull request.

How Remote Access to Physical Devices Is Secured

Every command to a physical controller is issued by the backend after authorization, never directly from a user’s session. Live video and telemetry connections are re-authorized every time a client connects, rather than trusting a previously issued token. Viewing or editing a device’s record doesn’t grant the ability to command it. Commanding requires an explicit permission that no other permission implies, and even an organization’s own administrator can’t exceed what that organization’s tier allows; remote programming requires Advanced access or above. Sending a stop command requires a six-character device code and an explicit confirmation step; activating a program requires the device password, checked both in the interface and again on the server. Every command is logged with who sent it, the system won’t resend a command while one is still pending, and it waits for the controller to confirm before telling the user whether it worked.

Real hardware didn’t always behave the way its own specification said it would. Controllers occasionally sent unexpected data, or the compiler produced a program format slightly different than what was documented, breaking assumptions the team had built around the spec. That gap is exactly what the live test fleet was built to catch early, rather than discover in a real-world deployment.

Two problems only showed up once devices were reporting continuously at scale. Updates arriving every few seconds surfaced a deadlock in group cleanup, which required decomposing transactions on the ingest path to fix properly. And because controllers get physically swapped out in work zones, the platform needed a way to reassign a device’s serial number to new hardware while preserving its full history and identity across the swap. That’s the kind of real-world detail that doesn’t show up until you’re managing hardware that actually lives in the field.

211 Devices, 41 Organizations, Live in Production

Horizon Signal Plus is live today with 41 customer organizations and 211 connected traffic signal controllers.

Visibility Without a Site Visit

Operators can see and control geographically distributed signals from one place, with alerts arriving proactively instead of being discovered on site. 

All Three Tiers, Live From Day One

The full access-tier structure — Basic, Advanced, and Comprehensive Monitoring — launched together, with live video and camera feeds following within two months.

Still Actively Developed

Nearly 900 pull requests to date since development began. This is a living platform, not a one-time delivery.

Constraints First, Then Acceleration

AI was useful here, but the reason it was safe to use was deciding where it was allowed to operate before ever turning it loose. Business logic, database structure, and infrastructure were specified precisely by hand; only then did the team let AI help to execute against that spec. The product’s actual safety logic never touched AI at all.

Test Against Real Hardware From Day One

The specification said controllers would send one thing; real controllers sent another, and the team only found out because a live fleet of test hardware was reporting from early in the build, not after launch. That single decision was, in the team’s own words, the most valuable verification asset on the project.

Deterministic Where It Counts

Every alert in the system fires on a specific, auditable rule (a threshold crossed, a log line matched), never a model’s inference. When a wrong answer could affect a real intersection, the system doesn’t guess.

Speed Isn’t Always the Point

Not every project we ship is measured in days or weeks. This one took roughly nine months from first commit to production launch. That’s the right amount of time for a system that remotely controls real intersections, verified against real hardware and secured in layers.

Want to see how Aboard could work for a project like this? Get in touch