There's a pedestrian crossing near where Daniel lives in Jerusalem. Three lanes of highway. The light turns green for pedestrians for exactly four seconds. The crossing is twelve meters wide. A person walking at a comfortable pace — one point two meters per second — covers about five meters in four seconds. You're not even halfway across before the light changes. And this has been broken for months.
That math is brutal. You're essentially stranded in the middle of a three-lane highway with cars bearing down on you. And the thing is, that light isn't "broken" in the way most people would assume. The conflict monitor — the hardware failsafe — hasn't tripped. The light isn't flashing red. It's doing exactly what someone told it to do. Someone just told it the wrong thing.
And that's the puzzle Daniel sent us. He worked at an industrial IoT company, got exposed to the world of SCADA and operational technology, and started thinking about the systems we all take for granted. His question is basically: how do these systems actually work, what prevents the catastrophic sequencing errors, and when we see something like a four-second crossing, is that a computer getting the math wrong or a human somewhere orchestrating the whole thing?
The answer is genuinely fascinating because it's both — and neither — in ways that reveal this entire hidden architecture most people drive through every day without ever thinking about. Traffic lights are the most visible piece of operational technology we touch. But the layered safety architecture underneath — hardware failsafes, coordination protocols, maintenance backlogs — almost nobody understands it.
We're going to unpack that. How the system actually works. What those safeguards are. And why that four-second crossing in Jerusalem is not a computer error — it's a maintenance backlog with a street address.
The conflict monitor. I think the conflict monitor is one of the most elegant pieces of safety engineering most people have never heard of. It's a two-hundred-dollar device that cannot be overridden by any software bug, and it has probably saved thousands of lives. We're going to get into that.
Before we get into the conflict monitor — and I promise we will — we should probably define what kind of system we're even talking about. Traffic lights live in a world called operational technology. And it's fundamentally different from the IT most people work with.
This is the SCADA stuff Daniel was referencing from his industrial IoT days.
SCADA — supervisory control and data acquisition. It's the same architecture that runs power grids, water treatment plants, natural gas pipelines. And the defining difference from regular IT is what happens when things go wrong. In IT, a server crash means you reboot, maybe you lose some data, people are annoyed. In OT, a failure can cause physical harm in seconds. A valve opens that shouldn't. Two traffic lights go green simultaneously.
The stakes are categorically different. And that shapes everything about how these systems are designed.
Traffic lights are part of what's called Intelligent Transportation Systems — ITS — and they sit on a SCADA backbone. But here's what's counterintuitive: the design philosophy is almost the inverse of what you'd expect if you come from the software world. In software, we prize flexibility. Push an update, change the behavior, iterate fast. In traffic control, the priority is fail-safe hardware. You want the system to default to a safe state even if every line of code is corrupted.
Which is where that two-hundred-dollar device you mentioned comes in.
The conflict monitor. And I want to be precise about what this thing is because it's elegant. It's an independent hardware device that sits in the controller cabinet at the intersection. It's not running software in the conventional sense — it's monitoring actual voltage on each signal output channel. If it ever detects green voltage on both north-south and east-west simultaneously for more than about five hundred milliseconds, it physically drops a relay. Forces the entire intersection into flashing red. All-way stop.
The key word there is "independent." This isn't a software watchdog that the main controller could theoretically ignore or override. It's a hardwired failsafe.
Cannot be overridden. You could have the most sophisticated adaptive traffic algorithm in the world running on the main controller, and if it somehow produces conflicting greens — whether through a bug, a memory corruption, a cosmic ray flipping a bit — the conflict monitor doesn't care. It sees the voltage, it drops the relay, intersection goes to flashing red.
Which brings us back to Daniel's four-second crossing. Because that light hasn't tripped the conflict monitor. No conflicting greens. The sequencing is "correct" — it's just that someone programmed the pedestrian clearance interval to be four seconds on a twelve-meter crossing. That's not a hardware failsafe problem. That's something else entirely.
And that's the central question we need to trace through the rest of this. When you see a broken traffic light — from dangerously mistimed to just annoyingly wrong — is it a sensor failure? A coordination protocol bug? A configuration error? Or a human who simply hasn't gotten around to fixing it? Because the answer tells you how the whole system really works, and which parts are actually fragile versus which parts are nearly bulletproof.
The conflict monitor catches the catastrophic stuff. The two-directions-green-at-once nightmare. But it does nothing about a pedestrian phase that's too short, or a left-turn arrow that never seems to trigger, or an intersection where you sit for three minutes at 3 a.with no cross traffic. Those are different failure modes entirely.
They live in different layers of the stack. Which is what makes this architecture so interesting to pick apart. You've got hardware failsafes at the bottom, local controller logic in the middle, coordination protocols above that, and then humans — traffic engineers — sitting on top of the whole thing making judgment calls about timing plans and maintenance priorities.
Let's start with the most important question. What actually prevents two directions from getting green at the same time? Because that's the one that would kill people.
The answer is that three-tier architecture I mentioned. And the bottom tier — the one that actually prevents the catastrophe — is that conflict monitor. But the conflict monitor is only one piece. Let me walk through the whole stack.
Start at the intersection itself.
At the street corner, inside one of those beige metal cabinets you've walked past a thousand times, there's a local intersection controller. It's a ruggedized industrial computer — built to survive hundred-degree heat and minus-forty cold and vibration and power surges. It runs the phase sequencing logic. Green for north-south, then a yellow clearance, then red, then green for east-west. The controller is the brain of that single intersection, and it operates independently. It does not need to phone home to make decisions.
That's the first thing most people get wrong, isn't it? The assumption that there's some central computer downtown making all the decisions in real time.
Each intersection runs itself. The central system — which we'll get to — provides coordination parameters, timing offsets, things like that. But the actual switching of lights? That's local. The controller is making millisecond-level decisions right there in the cabinet. And that's by design, because if the network link to downtown goes down, you don't want the intersection to freeze.
The controller is the brain. Where does the conflict monitor sit in this?
But crucially, it's not part of the controller. It's a separate device, wired independently to the signal outputs. The controller sends voltage to the red, yellow, and green signals on each approach. The conflict monitor sits between the controller and the actual lights on the pole, watching every output channel. And it's looking for one specific thing: green voltage on conflicting movements at the same time.
"conflicting" means north-south and east-west simultaneously. Movements that cross each other.
The monitor is programmed with a conflict matrix — it knows which signal groups are allowed to be green together and which aren't. Permitted combinations like a northbound left turn arrow with the northbound through movement? But north-south through and east-west through at the same time? That's in the matrix as a conflict. If the monitor sees voltage on both of those channels for more than about five hundred milliseconds, it triggers.
Five hundred milliseconds. Half a second. That's the threshold.
That number matters. You don't want the monitor tripping on a transient voltage spike or a brief overlap during a normal phase transition. The five hundred millisecond window gives the controller enough room to do a clean switch from one phase to the next without false positives. But anything longer than that — anything that looks like an actual conflicting green — and the monitor drops the relay.
What does "dropping the relay" actually mean physically?
It opens a hardware circuit that cuts power to the normal signal outputs and forces the intersection into flashing red on all approaches. Every direction gets a flashing red. All-way stop. The monitor physically disconnects the controller from the lights. It doesn't send a message to the controller saying "please fix this." It doesn't log an error and hope someone notices. It takes control of the intersection electrically and forces the safe state.
Even if the controller is completely fried — memory corrupted, processor locked up, software gone haywire — the conflict monitor still works because it's not listening to the controller at all. It's watching the voltage. And if the voltage pattern is wrong, it pulls the plug.
And here's the part that I find beautiful: this is a two-hundred-dollar device. For a piece of hardware that has probably prevented thousands of fatal T-bone collisions over the decades it's been required in traffic cabinets. It's this tiny, unglamorous thing that just sits there for years doing nothing — until the one time it's needed, and then it acts in less than a second.
The engineering equivalent of a smoke detector that also grabs the fire extinguisher.
That's not bad. And the conflict monitor is mandatory. In the United States, the Manual on Uniform Traffic Control Devices requires a conflict monitor in every signalized intersection. You cannot install a traffic light without one.
That's the bottom tier. The failsafe that catches the unthinkable. What about the coordination between intersections? Because the conflict monitor doesn't help with that at all.
That's the third tier — the central management system. And this is where SCADA comes in. The central system is a server, or a cluster of servers, sitting in the city's traffic management center. It communicates with all the local controllers across the city using protocols like NTCIP twelve-oh-two and twelve-oh-three. Those are the standard communication protocols for traffic signal controllers in North America.
What's it actually doing? If the intersections run themselves, what does the central system add?
The central system tells controller A that when it starts its north-south green phase, controller B — half a mile down the road — should start its north-south green phase exactly twenty-three seconds later, so that a car traveling at the speed limit hits a wave of green lights. That's the "green wave" people talk about. The central system calculates those offsets based on traffic models, time of day, and sometimes real-time sensor data.
The central system is the conductor, but each intersection is still playing its own instrument.
And the communication is not real-time in the way people assume. The central system isn't sending a constant stream of "turn green now, turn red now" commands. It sends updated timing plans — maybe every few minutes, maybe once a day — and the local controllers execute them. The local controller is always the final authority on when the lights actually change.
Which means if the central system goes down, the intersections don't go dark. They just keep running their last timing plan.
And that's another deliberate design choice. The system degrades gracefully. Lose the network, you lose coordination, but every intersection still works. Lose a local controller, the conflict monitor still protects against catastrophic failure. Lose everything, the conflict monitor can still force flashing red. The layers are designed to fail independently.
Now, you mentioned earlier that most intersections don't actually use adaptive coordination. They're not all running on some AI-powered algorithm.
Most are not. The two big adaptive systems are SCOOT — developed in the UK — and SCATS, developed in Australia. These use inductive loop detectors or radar sensors embedded in the pavement to measure real-time traffic flow and adjust timing dynamically. But globally, the vast majority of signalized intersections still run on fixed-time plans or simple actuated control.
Actuated meaning what — it detects a car and changes?
A vehicle pulls up to the stop line, drives over an inductive loop, and the controller says "okay, someone's waiting, I'll give this approach a green in the next cycle." It's reactive but not coordinated across intersections.
The conflict monitor handles the catastrophic failures — the things that would kill people. But what about the annoying ones? Like that four-second crossing in Jerusalem. That's where we leave the hardware and step into the world of humans.
Because someone set that four seconds. Someone typed it into a configuration screen, probably during a firmware update or a controller replacement, and then moved on to the next ticket.
Here's the thing — that person is almost certainly a traffic engineer working for the city's transportation department. Despite all the automation we just described, traffic systems are fundamentally orchestrated by humans. They set the timing plans. They respond to complaints. They prioritize which intersections get re-timed and which ones wait.
When Daniel asks whether it's a computer that got the math wrong or a human orchestrating the system — it's a human who set the parameter. But the reason it hasn't been fixed is also human.
The maintenance backlog. There was a twenty twenty-three survey by the NTCIP group that found the average US city has a six to eighteen month backlog on signal timing updates. You report a mistimed light today, it might be a year and a half before anyone touches it.
The math behind that is almost absurdly simple. A city of five hundred thousand people has roughly a thousand signalized intersections. It employs maybe two or three traffic signal technicians. Each intersection needs re-timing every three to five years. You do the division and you realize those three people are never, ever caught up.
Jerusalem's municipal traffic department almost certainly has similar or worse numbers. So that four-second crossing? It's been triaged. And here's the uncomfortable truth about how triage works in these systems: the conflict monitor catches the safety-critical failures automatically. What's left for the humans to prioritize are usability failures. A pedestrian phase that's too short is dangerous, but it's not "conflicting greens" dangerous. So it sits in the queue.
Which means the system is working exactly as designed, and also failing exactly as designed. The design prevents the catastrophe brilliantly. The design does nothing to prevent the slow-rolling annoyance that strands pedestrians in the middle of a highway.
This gets us to something Daniel's background in industrial IoT probably made him think about immediately: cybersecurity. Because these systems are increasingly connected. Cities want remote monitoring, centralized dashboards, data. So they're putting traffic controllers on the network. But many of these controllers still communicate using legacy protocols — NTCIP over serial, unencrypted, no authentication.
Which means what, practically? Someone could get into the network and start changing timing plans?
It's happened. In twenty twenty-one, a ransomware attack hit the San Francisco Municipal Transportation Agency. The attackers encrypted their systems, including traffic signal management. Operators couldn't access the central management software. They had to go out and manually adjust timing plans at individual cabinets for weeks.
That's not theoretical. That's a major American city, manually tweaking traffic lights because someone clicked a phishing link.
The attack surface is growing. More intersections get networked every year. More cities deploy cloud-based traffic management platforms. But the security budgets don't scale with the connectivity. Most municipal traffic departments have no dedicated cybersecurity staff. The people managing the intersections are civil engineers, not infosec professionals.
You've got brilliant hardware failsafes at the bottom of the stack, and at the top of the stack you've got a network connection that some city IT department threw in so the mayor could see a dashboard, and nobody thought about authentication.
That's the tension. And it's the same tension playing out across all operational technology — power grids, water systems, gas pipelines. The physical safety layers are robust. The digital layers are being bolted on after the fact, often without the security model to match.
There's another layer to this I want to pull on. You mentioned the conflict monitor forces flashing red when it trips. All-way stop. And we've been talking about that as the safe failure pattern. But is an all-way stop actually safe in every context?
The answer is no — or at least, it's complicated. At a forty-five mile per hour intersection, a flashing red means every driver must stop and proceed with caution. But if a driver doesn't see the flashing red — sun glare, distraction, they're looking at their phone — they may treat it as a green. They sail through at speed. And then you get a T-bone collision, which is exactly what the conflict monitor was supposed to prevent.
The failure pattern that prevents one kind of catastrophe can create the conditions for a different one.
The safest failure pattern depends on context. At a low-speed urban intersection, flashing red works well — drivers are already moving slowly, they expect stops. At a high-speed arterial, a dark signal or a flashing yellow on the main road with flashing red on the side street might actually be safer. But the conflict monitor doesn't know the difference. It has one move: cut power, flash red everywhere.
Which is the tradeoff you make when you put a two-hundred-dollar hardware failsafe in a cabinet. It's dumb in the best and worst ways.
It can't be fooled, but it also can't be nuanced. And that brings us to the contrast with something Daniel also mentioned: street lighting. A twenty twenty-two study by the Insurance Institute for Highway Safety found that dark intersections increase accident risk by about thirty percent. But street lighting failures are gradual and predictable. A bulb dims before it dies. A circuit goes out and you lose a block, but the rest of the grid stays lit.
Whereas a traffic light failure is immediate and can cascade.
A single mis-timed intersection at the wrong time of day can cause gridlock that propagates for miles. One controller with a bad offset, and suddenly you've got a queue backing up through the previous intersection, which blocks the intersection behind that, and within twenty minutes you've paralyzed a square mile of downtown. Street lights don't cascade. Traffic lights absolutely do.
You've got a system where the catastrophic failures are brilliantly prevented by hardware, the annoying failures are stuck in a human backlog measured in years, the cybersecurity posture is a decade behind the connectivity, and the graceful failure pattern might itself be dangerous at speed. That's the actual state of the system we all drive through every day.
Yet, it works. Most of the time, for most people, it works. Which is either a testament to the engineering or a reminder that we're one understaffed maintenance department away from chaos.
All of this raises a practical question. What do you actually do when you encounter a broken traffic light? Because most people just complain to whoever's in the car with them and then forget about it.
And Daniel's four-second crossing has been broken for months. Someone must have noticed. Probably dozens of people have noticed. So why isn't it fixed? And what should you actually do if you want to be the person who gets it fixed?
The answer starts with understanding how cities triage these things. When you report a traffic signal problem, it goes into the same queue as every other signal complaint. And remember those numbers — a city of half a million people has maybe two or three technicians and a six to eighteen month backlog. Your report is competing with every mistimed left-turn arrow, every stuck pedestrian button, every intersection where the detection loop stopped working.
The way you report it actually matters. "The light at Oak and Third is broken" goes to the bottom of the pile.
The most effective reports include three things: the specific location — ideally the exact intersection and direction — the time of day when the problem occurs, and a clear description of the danger. Not "the light is annoying." Something like "pedestrians cannot physically cross the highway in the allotted four seconds." That language signals to the traffic engineer that this is a safety issue, not a convenience complaint.
"safety issue" is the magic phrase that bumps it up the triage list.
The conflict monitor catches the immediately lethal stuff automatically, but a pedestrian phase that strands people in moving traffic — that's a safety issue a human has to recognize and prioritize. The more precisely you describe the danger, the harder it is to deprioritize.
For Daniel's crossing, the report would be something like: south side of Highway One at the pedestrian crossing, all times of day, green phase lasts four seconds, crossing is twelve meters wide, pedestrians are stranded mid-crossing when the light changes.
That report gets attention. A vague "the light is too short" gets filed.
Which brings us to the second thing every listener should know, and it's honestly the thing I found most striking in this whole conversation. The next time you see a traffic light go to flashing red — all four directions, all-way stop — do not think "ugh, the light is broken." Think "the conflict monitor just saved someone's life.
Flashing red is not a failure. It's the system working exactly as designed. Somewhere in that cabinet, a two-hundred-dollar hardware device detected something unsafe — or thought it did — and forced the intersection into the safest possible state. It defaulted to all-way stop. That's the design succeeding.
The fact that it's annoying — that you have to stop and wait and figure out whose turn it is — that's the point. Annoyance is a safety feature. The system is saying "I cannot guarantee your safety at speed right now, so I'm making you slow down and negotiate this yourself.
I love that framing. The conflict monitor trades efficiency for certainty. It would rather inconvenience a thousand drivers than risk one T-bone collision. And that tradeoff is wired directly into the hardware. No software update can change it. No budget cut can disable it. It's a physical commitment to safety.
Which is a philosophy a lot of software systems could learn from, honestly.
That actually connects to the third thing I want to put in front of our listeners — especially the ones who work in tech. The operational technology world is enormous and it's under-served. Traffic signal controllers, as sophisticated as the failsafes are, are still largely running on legacy hardware with legacy protocols. NTCIP twelve-oh-two was designed in an era when nobody imagined these things would be on the internet.
There's a genuine engineering challenge here. Modernize the controllers with secure firmware, proper authentication, encrypted communication — without breaking the hardware failsafes that make the system safe.
That's harder than it sounds. You can't just slap a TLS layer on a serial protocol and call it secure. You have to think about what happens when the authentication server goes down — does the intersection still work? You have to think about over-the-air updates — if you can push firmware remotely, can an attacker push malicious firmware? Every new feature creates a new attack surface, and the safety stakes are real.
For someone in tech who's tired of optimizing ad delivery or building yet another SaaS dashboard, this is a field where the work actually matters. Systems where failure means something.
It's not just traffic lights. It's water treatment, power distribution, gas pipelines, railway signaling. The entire operational technology sector is going through a modernization wave right now, and there's a massive shortage of people who understand both the legacy OT world and modern security practices. If you can bridge that gap, you will never be unemployed.
Which is a career insight disguised as a traffic light discussion.
The best kind. And it ties back to the broader point I think this whole episode has been circling. The systems we take for granted are held together by this strange combination of brilliant hardware engineering and overworked humans. The conflict monitor is a triumph of safety design. The maintenance backlog is a failure of resource allocation. Both are true at the same time.
The next time you're sitting at a red light at an empty intersection at two in the morning, remember: someone tuned that timing. A traffic engineer sat down with traffic models and vehicle counts and decided exactly how long you'd wait. And they're probably already behind on the next intersection.
As we look ahead, there's a question I keep turning over. We're starting to see cities deploy connected vehicle infrastructure — V2X, vehicle-to-everything communication. Cars that talk to traffic lights directly. AI-driven adaptive control that adjusts timing based on real-time camera feeds and predictive models. And I wonder whether we're about to trade something valuable without realizing it.
The simplicity of the conflict monitor.
A two-hundred-dollar hardware device that does one thing and cannot be overridden. That's not elegant despite being simple. It's elegant because it's simple. You can reason about its behavior completely. You know exactly what it will do in every possible failure state. Software-based safety systems — especially machine learning systems — don't give you that guarantee.
The pitch for the new stuff is always flexibility. Fewer cars idling at empty intersections. But flexibility is the opposite of what you want in a safety system.
There's a genuine tension here that I don't think most cities are thinking about clearly. If you replace a hardware conflict monitor with a software-based safety layer running on the same processor as the adaptive algorithm — which some newer controller designs do — you've created a single point of failure. A memory corruption that takes out the algorithm can take out the safety layer too.
You're betting that your software is bug-free enough to be trusted with what a two-hundred-dollar relay used to guarantee.
The history of software suggests that's not a bet you should be eager to make. I'm not saying we shouldn't modernize. Adaptive control reduces congestion and emissions. V2X could prevent accidents by warning drivers about red-light runners before they enter the intersection. But we should be asking harder questions about whether the safety layers stay independent.
Which brings us back to that four-second crossing in Jerusalem. Because I think it's the perfect reminder of what this whole thing is actually about. Technology doesn't fail in the ways we expect. It fails in the ways we forgot to check. The conflict monitor catches the failure everyone imagined — conflicting greens. But nobody imagined someone would type "four" into a pedestrian clearance field on a twelve-meter crossing and then walk away.
That's the system. The brilliant hardware failsafe and the overworked human and the configuration parameter nobody double-checked. They're all part of the same thing. The conflict monitor is what keeps the catastrophic failure from killing someone. The maintenance backlog is what keeps the annoying failure from getting fixed. Both are true. Both are the system.
Now: Hilbert's daily fun fact.
Hilbert: In the nineteen-tens, a Russian expedition in Kamchatka used dried salmon skins as window coverings in their field huts, measuring light transmission at roughly the same opacity as modern frosted glass — about seventy percent diffusion.
I have so many questions about how they measured that.
I have so many questions about why Hilbert knows it.
This has been My Weird Prompts. If you enjoyed this episode, leave us a review wherever you listen — it helps other people find the show. You can also reach us at show at my weird prompts dot com, or visit the website at my weird prompts dot com. We're back next week.
