How a billion movement records, serialized asset histories, and a natural operational experiment gave rise to Capital Management Program and Alert–Prescribe–Comply.
The Capital Management Program did not begin as a capital management program. It began with a capability.
In 2007, the underlying systems and processes were already operating in the Los Angeles market, and word was spreading that we could do something unusual: stitch fragmented operational histories together and create a faithful digital twin of every serialized set-top box in the market.
The serial number became the organizing principle. Accounts changed. Customers changed. Locations changed. Work orders opened and closed. Technicians came and went. But the serialized asset persisted through all of them. By centering history on the equipment itself, we could intersect its movements with account numbers, work orders, trouble calls, repair activity, call-center interactions, geography, and eventually the physical network.
Then came the capability that changed everything: we could replay history. Approximately a billion historical equipment movements could be reconstructed and conditioned against information that had not been part of the original analysis. Two years of work-order history could be introduced. Trouble-call removals could be isolated. Call-center activity could be associated through customer accounts. Accounts could be bridged through ZIP codes into nodes and network topology. Repeaters and even optical devices that were effectively silent from a telemetry perspective could become part of the analytical map.
The past could be asked a question that nobody knew to ask when the events originally occurred.
That capability led from observation to operational failure, from operational failure to pre-failure, from pre-failure to intervention, and from intervention to a harder question: now that we know, how do we get another process to do something about it—and how do we know that it actually did?
That question gave birth to APC: Alert–Prescribe–Comply. What began as equipment analytics became a closed-loop operating discipline and a foundation later repurposed across human telemetry, agriculture, workforce management, financial technology (fintech), market exchanges, and now artificial intelligence.
Traditional operational systems were largely organized around transactions. A customer had an account. A technician received a work order. Equipment entered or left inventory. A set-top box was installed and later removed. Each system knew its piece of the story, but generally not the complete story of the physical asset.
Our approach changed the point of observation. Instead of treating the account or work order as the primary object, we centered history on the serialized piece of equipment itself. Every set-top box developed a longitudinal history—a digital twin describing what had happened to that particular physical unit over time.
Intersecting that history were customer accounts, work orders, installations and removals, trouble calls, repair and testing events, warehouse movements, call-center activity, geography, network relationships, and time. We were no longer simply studying transactions. We were studying behavior over time.
Historical replay was the decisive technical advantage. We could take approximately one billion equipment-movement records and introduce another historical dataset—perhaps two years of work orders—then isolate trouble-call removals, associate them with serialized assets, introduce call-center information through the account, establish a new condition, and replay the historical population.
This was fundamentally different from querying old records. If tomorrow we discovered that a combination of movement, work-order type, customer event, recurrence, network relationship, and time interval might indicate undesirable behavior, we did not have to wait another year to accumulate evidence. We could define the condition today and ask what it would have shown us if we had been watching all along.
The systems were written in low-level languages and were blazingly fast for their time. Analyses achievable in roughly a day could otherwise require weeks of database work and, under sufficiently demanding workloads, conventional approaches could fail. Speed changed the economics of discovery. A hypothesis that takes six weeks to test encourages caution. A hypothesis that can be tested tomorrow encourages experimentation.
Historical replay changed how we thought about missing information. Existing operational systems did not have to define the boundaries of the investigation.
When the answer was not present in the information we possessed, the philosophy became simple: make the data or go get the data. Then replay again.
Equipment movement could be combined with work orders. Work orders with accounts. Accounts with call-center interactions. Accounts could also be associated geographically and logically with the network serving them. Every new layer had the potential to change the interpretation of everything beneath it.
One early observation was deceptively simple: identify when a set-top box went onto an account and came off within a defined period. Interesting—but not a silver bullet. A rapid removal could have many explanations: defective equipment, customer disconnect, unnecessary swap, plant problem, signal problem, wiring, account condition, or something else.
This led to the concept of operational failure. An operational failure was not necessarily a declaration that something inside the box was physically broken. It was an event that could be safely and consistently observed.
Once operational failures could be defined consistently, we could study their accumulation, recurrence, timing, velocity, and relationship across roughly 120 dimensions. The question changed from “Can we prove this box is broken?” to “What is this box’s behavior telling us?”
Install-and-return analysis produced meaningful results, but exposed a serious problem. By the time the evidence reached the threshold where a meaningful percentage of equipment could be confirmed bad, an affected unit might already have cycled through four customer accounts.
Eventually being right was not good enough. Four customers had already paid the price. That was not prevention. It was confirmation after the damage. We needed to move upstream.
We began exploring qualitative analytical methods that were precursors to increasingly sophisticated machine-learning techniques. Instead of looking for one event, we looked for ranges of behavior. Time mattered. Sequence mattered. Recurrence mattered. Velocity mattered. Context mattered.
Eventually, we constructed a complex five-dimensional condition that changed our understanding of operational failure. One occurrence was operationally ugly but could still be nominal and explainable. Two was different. So was three. The second and third qualifying occurrences became the important ranges—the threshold of pre-failure.
We were no longer asking whether equipment had behaved badly enough that everyone would finally agree it was defective. We were asking whether its behavior had become sufficiently abnormal that allowing it to reach another customer was no longer an acceptable decision.
Finding the condition was exhilarating, but the apparent silver bullet still had to be tested. Equipment went under forensics. For small batches, testing could be exhaustive—effectively 100 percent. At larger scale, I was told that approximately 85 percent failure confirmation was achieved. Just as importantly, forensic investigation exposed new failure modes.
No Trouble Found—NTF—did not necessarily mean healthy. Sometimes it meant the repair process did not yet know what trouble to look for. Behavior identified the suspect. Forensics investigated the physical unit. Unknown failure modes became known. Those discoveries improved testing, intervention, and future evidence.
As our ability to characterize Customer Premises Equipment (CPE) improved, another benefit emerged: we became better at determining when the box probably was not the problem.
A service problem can occupy an enormous domain—CPE, wiring, plant, repeaters, optical devices, neighborhood degradation, and other causes. As long as CPE remained an uncontrolled variable, all possibilities competed for attention. When equipment could be cleared with reasonable confidence, an entire category of uncertainty could be removed.
Healthy equipment made the rest of the network easier to understand. We were improving the signal-to-noise ratio of the entire operation.
The customer account became a bridge. Accounts could be associated with physical locations; locations through ZIP codes and service areas; those areas with nodes; nodes with network segments, repeaters, and eventually optical network devices.
Some devices were effectively dead silent when it came to telemetry. That did not make them analytically invisible. If we understood topology, we understood relationships: what was upstream, what was downstream, which customers depended on a device or pathway, and what those customers were experiencing.
The chain became: Serial Number → Account → Geography → Node → Network Segment → Repeater/Optical Device → Customer Experience.
A device did not need to emit telemetry to become observable. Sometimes its surroundings could speak for it.
If multiple customers produced similar complaints, their CPE histories appeared healthy, technicians continued visiting, trouble calls accumulated, and the accounts shared a node, repeater, optical device, or upstream pathway, the collective pattern could become meaningful even when each individual event was only a micro signal.
In that sense, topology itself could become a form of telemetry.
Once accounts, complaints, equipment, geography, and topology could be associated, customer experience could be projected back onto the physical network. Complaints were no longer rows in a call-center report. Trouble calls were no longer isolated technician workloads. Repeat visits were signals.
Clusters mattered. Timing mattered. Velocity mattered. Shared infrastructure mattered. A pattern that looked random at the account level could become obvious across a node, service area, or pathway.
The discipline became: redraw the problem domain. Remove what is known. Measure what remains. Correlate the micro signals. If the answer is somewhere else, make the data or go get the data—then replay again.
As the program gained momentum, we began working with another Multiple System Operator (MSO) on the East Coast. The operator was particularly interested in reducing equipment swap rate. The toolset immediately isolated a substantial population meeting our criteria.
Then analytics collided with operations. The system was effectively saying: do not put these assets back into customers’ homes. But there was no established warehouse location for this population, no comfortable accounting story for sidelining substantial capital, and not every unit had a known physical root cause. The optics were difficult, and the early adopters were taking genuine organizational risk.
Then something happened: swap rate dropped drastically.
The targeted population had been isolated and swap rate had declined. The result could be placed on an Excel sheet as evidence of success. But was that enough? Was a count on a spreadsheet sufficient justification for continuing to sideline substantial capital?
Finding equipment was not the same as governing equipment. A lower aggregate swap rate did not prove what would happen if the intervention disappeared. We were about to find out.
More powerful organizational forces eventually concluded that the swap-rate improvement did not justify sidelining so many assets without a clear pathway to root causes and unknown failure modes. The assets had visible value; the avoided cost was harder to see. The equipment was released.
Within approximately three weeks, the market snapped. Trouble calls surged. Repeat service calls surged. Truck rolls surged. Combined service activity nearly doubled.
The cost was quantifiable. Every truck roll, repeat visit, unnecessary swap, and additional customer problem carried a cost. Prevention had made those costs invisible. Removing prevention made them visible again. The program was immediately reinstated.
In retrospect, the organization had unintentionally created an extraordinary natural experiment.
Intervention ON: suspect equipment was removed and swap rate dropped.
Intervention OFF: the population was released and, within roughly three weeks, trouble calls, repeat service calls, and truck rolls nearly doubled.
Intervention ON AGAIN: the program was reinstated, the market stabilized, and previously unknown failure modes continued to be identified.
The operation demonstrated the value of intervention by showing what happened when intervention disappeared. It also revealed a hard truth: the better prevention works, the easier it becomes to forget why it exists.
By now we knew how to observe, identify a behavioral population, validate it forensically, discover new failure modes, and isolate assets likely to hurt the operation. But how did we operationalize it?
Suppose the analysis told repair to do something different with a unit. How did we know whether repair actually did it? How did we know what happened afterward? How could one process ask another process to change state and then objectively determine whether that state change occurred?
We needed a closed-loop mechanism. The answer became inevitable: Alert → Prescribe → Comply. APC.
Alert was fundamentally observation. We could define an observable behavioral band containing the population likely to hurt us. Typically around 10 to 20 percent might fall into the wider condition; in practice the pre-failure population averaged around 12 percent.
That was far too large for indiscriminate intervention. The point was to become surgical. Inside the broad observable band, increasingly precise conditions could drive the actual intervention population below one percent.
Alert did not mean everything in the band had failed. It meant everything we cared about was observable inside the boundary.
Observation alone does not change an operation. Prescribe turned an alert into a defined action.
A prescription opened a predefined operational door. The system was no longer saying “Look at this.” It was saying “Do this.” If a unit needed a different repair process, forensic testing, quarantine, or another pathway, that action had to be defined.
A door that is opened must also have a known way to close. Before sending the prescription, we needed to agree on the observable signals that would demonstrate completion. The prescription and evidence of completion had to be connected before the action began.
Compliance was not someone checking a box. It had to be observable.
If we asked repair to do something different, we needed access to dispositioning. Was the unit repaired? Classified NTF? Was a new failure mode discovered? What happened when that exact serial number returned to circulation?
A repaired unit that subsequently stopped exhibiting operational failures supported the intended outcome. An NTF unit that returned to circulation and immediately exhibited operational failures told a different story.
The loop became: observe → prescribe → measure compliance → observe the resulting behavior.
We created the process, illustrations, and dashboarding necessary to quantify the closed loop. Every signal sent to repair could have a corresponding state: received, acted upon, dispositioned, returned, and subsequently observed.
The watch list was no longer merely a list of bad-looking equipment. It became a managed population moving through defined states.
Then compliance crossed 50 percent. For more than half of the signals sent to repair, the prescribed pathway was now being followed sufficiently for the closed loop to become observable. That threshold changed the system.
As repair compliance moved beyond approximately 50 percent, the pre-failure population began to contract. The average pre-failure band had been about 12 percent of units. Within roughly a year and a half, it fell to approximately 7 percent.
Watch-list equipment that was repaired went from roughly 15 percent on-account to approximately 65 percent on-account. Risky capital was becoming productive capital again.
At the same time, watch-list equipment that had not yet been repaired fell to approximately 3 percent on customer accounts. In practical terms, about 97 percent of the assets deemed potentially harmful were being kept away from customers.
That was closed-loop management: keep harmful equipment away from customers, learn what was wrong, repair what could be repaired, return healthy capital to productive use, and measure the outcome.
Eventually operational failures began to flatten and the program approached steady state. Additional methods were developed to quantify savings because the economics were no longer represented merely by equipment counts.
Avoided trouble calls mattered. Avoided repeat visits mattered. Avoided truck rolls mattered. Recovered productive capital mattered. Customer stability mattered.
What had once been a large watch-list population eventually contracted to roughly 20 percent of its former size. Within that residual population, only about 3 percent was touching customer homes, and harmful equipment that began churning again could be caught rapidly.
The program was no longer merely managing the problem. It had changed the shape of the problem.
A set-top box on a warehouse shelf is capital. A set-top box operating successfully in a customer’s home is productive capital. A set-top box repeatedly generating trouble calls, repeat visits, swaps, and truck rolls can become negative operational capital.
Its book value may not change. Its appearance may not change. It may even pass a conventional bench test. But its history changes its economic meaning.
The same principle applied to the network. A silent repeater or optical component could become observable through the equipment histories, accounts, complaints, geography, and network relationships surrounding it.
The physical asset and the knowledge surrounding the physical asset could no longer be separated.
The birth of CMP and APC produced principles that would influence everything that followed.
Looking backward, the progression appears almost inevitable. A billion movement records became histories. Histories became digital twins. Digital twins exposed behavior. Behavior became operational failure. Operational failure became pre-failure. Pre-failure became forensic investigation. Forensics exposed new failure modes.
Healthy CPE narrowed the problem domain. Accounts bridged equipment into geography. Geography bridged customers into nodes and topology. Topology allowed silent infrastructure to become observable through the behavior surrounding it. Customer complaints could be heat mapped against network performance. Every time the answer remained somewhere else, we could make the data, acquire the data, add another layer, and replay history again.
Then came the organizational lesson. Finding the answer was not enough. The East Coast experiment demonstrated that intervention mattered. But even intervention was not enough. We needed to know whether another process had actually done what we asked it to do.
That necessity gave birth to Alert–Prescribe–Comply: observe the condition, define the action, define how completion will be observed, measure compliance, and then return to the behavior to determine whether the outcome actually changed.
When compliance crossed the threshold necessary to influence the system, the population changed. The pre-failure band contracted. Harmful equipment stayed away from customers. Repaired equipment returned to productive service. Operational failures flattened. The watch list shrank. The system approached steady state.
CMP was no longer simply finding problems. It was governing movement toward a better state.
The Capital Management Program began with set-top boxes. It did not end there.
What we had actually built was a reusable discipline: observe something faithfully enough to understand its behavior; preserve enough history to replay what happened; identify the boundary separating acceptable behavior from harmful behavior; reduce the problem domain until weak signals become visible; acquire or create missing evidence; validate what you believe; prescribe a state change; observe compliance; measure the outcome; and learn from the result.
The underlying subject could change. Equipment could become human telemetry. The same discipline could move into agriculture and workforce management. It could be applied to financial technology—fintech—where transactions, risk signals, state changes, and compliance must be observed across complex financial processes. It could extend into market exchanges, where participants, inventory, orders, rules, eligibility, settlement, and changing market states create another environment in which observable behavior must be converted into governed action.
And now, with artificial intelligence, the ability to observe, correlate, prescribe, verify, and learn can operate across extraordinary volumes and varieties of evidence. AI changes the scale and speed. It does not change the underlying discipline.
Alert what can be observed. Prescribe what should change. Comply by proving that it did.
Sometimes you lose a battle so you can win the war. The equipment was released. The market snapped. The cost became visible. The program returned. The loop closed. Eventually, the problem population itself began to disappear.
What began as an extraordinary ability to replay the history of a set-top box became the foundation for an entirely different way of managing complex systems.
That was the birth of the Capital Management Program. And within it was the birth of Alert–Prescribe–Comply.
Follow Tallgrass on LinkedIn
Decision science, lifecycle economics, and agentic systems — published where engineering leaders read.
Knowing where an asset is tells you nothing about what it's worth. Economic visibility transforms asset management from inventory control to capital optimization—every asset becomes a real-time economic position.
Optimizing one asset at a time leaves value on the table. Portfolio-level intelligence reveals patterns, timing opportunities, and economic leverage that individual asset decisions can never capture.
An asset's physical condition directly determines its economic value—but most organizations can't make this translation. Condition intelligence bridges the gap between 'what state is this asset in?' and 'what is it worth?'