Most people who experience internet problems get an explanation. The router needed a reboot. The firmware updated overnight. The ISP had maintenance in the area. The explanation doesn’t always satisfy, but it closes the loop — there’s a story, and the story fits.
What began in 2018 was different. Not because the anomalies were impossible to explain, but because they were always explainable and never really explained. The router behaved strangely after a factory reset that should have resolved it. Packet captures showed traffic that had no obvious business being where it was. Service calls produced technicians who fixed things that seemed fine and left behind conditions that still didn’t seem right. Each event had an answer on paper. None of the answers were satisfying, and they weren’t meant to be examined together.
That examination is where this investigation begins.
What EOO Means
Eyes-On-Operations, or EOO, is a documentation methodology. It is not surveillance. It is not speculation. It is the practice of recording observable conditions — what you see, when you see it, under what circumstances — in a format that can be reviewed, cross-referenced, and presented as evidence.
EOO began in 2018 as a response to a simple problem: anomalies were occurring at a frequency and variety that made informal memory an unreliable record. A single incident can be dismissed. Two incidents in the same environment look like coincidence. But when patterns begin to overlay other patterns — a physical observation corroborated by a network event corroborated by a service call that doesn’t resolve the underlying condition — the record becomes something more than a log. It becomes a case.
The discipline of documentation is what separates a researcher from someone with a grievance. The instinct is to interpret first and document second. Proper investigative practice reverses that order. You record the observable condition. You note the time, the location, the technical specifics. You do not assign causation in the field. The record is what you know. The analysis is what you conclude. The two must be kept cleanly separate, or neither is worth much in a formal proceeding.
EOO produced that record. Everything that follows in this series is anchored to it.
The 2019 Anchor
The first physical infrastructure anomaly was documented in 2019. At a street-level headend — the kind of gray metal box you walk past without thinking twice — there was a splice that had no business being there. Not a licensed repair. Not standard carrier configuration. Something added to infrastructure that didn’t belong to whoever added it.
This was not the first anomaly. But it was the first one with a physical, verifiable form that could be photographed and cross-referenced against what a legitimate installation should look like. It coincided with a period of repeated ISP service calls — calls that produced technicians, produced explanations, and produced conditions that still didn’t resolve.
The splice became the anchor. Whatever was happening had a physical component. It was not entirely a software problem, not entirely a configuration drift, not entirely explainable by the usual list of residential internet gremlins.
Three Is a Pattern
Any serious documentation methodology needs a threshold — a standard for when accumulated observations graduate from “things worth noting” to “a pattern worth investigating.” The threshold used throughout this research is three independent incidents of the same class of anomaly before the anomaly class is treated as an active condition rather than noise.
One anomaly is noise. Two anomalies are coincidence. Three anomalies of the same type, independently documented, constitute a pattern — and a pattern requires an explanation that accounts for all three, not just each one in isolation.
This standard matters for evidentiary reasons: it protects against confirmation bias, it filters out the normal background rate of equipment failures and configuration quirks, and it produces a record that can withstand scrutiny. It also means the investigation moved slowly. Patterns take time to establish. The documentation accumulated across months, then years.
Not Isolated. Not Incidental. Not Accidental.
By the time the record was examined in full, the anomalies had accumulated across multiple residential locations and multiple years. The same classes of events — the same infrastructure signatures, the same failure-to-resolve patterns, the same physical observations at street-level nodes — appeared not once or twice but persistently, in different geographies, under conditions that could not share a common innocent cause.
A problem that follows a researcher across locations and years is not a local hardware issue. It is not bad luck with ISP service quality. It is not a series of unrelated equipment failures that happen to share a victim.
The problem was not isolated. It was not incidental. And it was not accidental.
The next question was what it actually was.
Next: Part 2 — “The Crack in the Cable Plant” The architectural seam that made all of it possible — and who is responsible for it.