end field

Chapter 12: Errors

Errors don't come with a red bell.

They come in silent numbers, in a series of small deviations that no one can piece together immediately.

A week after Huy left the team, we noted a small fluctuation in the recycled water treatment line. A sensor valve reported a 0.7% deviation from the normal threshold—below the automatic alert level—but higher than the weekly average. The algorithm quickly analyzed: *not exceeding the threshold*, *no impact on the main supply*, *expected risk 0.5% or when the residential area’s vulnerability exceeds the threshold. Currently, neither condition is met.*

A moment of silence. The data-driven answer was already embedded in the chart, no words needed.

“I’ll transfer a team immediately,” I said, but in my head I knew one thing: transferring a team immediately meant rescheduling another task, increasing downtime on the production line; that would affect the output metric everyone uses as proof of operational ethics.

I signed the request. The team departed at 10:12. They arrived at 6:37 PM. En route, their vehicle was delayed due to a route change for supplies priority. When they opened the inspection valve, a section of the filter membrane had ruptured—a minor damage, but enough to allow foreign microorganisms to enter the sub-network. The storage tank in the adjacent area was contaminated.

Result: In the past 36 hours, 26 mild cases, 4 moderate cases requiring IV fluids, and one elderly patient admitted to the intensive care unit due to hypotension. No deaths. No cataclysm. But in the log, the system recorded: *event exceeded expected threshold; cause: maintenance delay; impact: increased loss by 0.12% compared to prediction; action: proposed patch V1.2.*

The council met immediately afterward. The figures were presented: response time, transport route, old priority weighting. The chief engineer said, “The underlying cause is the delay. The delay is a consequence of prioritizing the route. The algorithm traded repair time for maintaining output.”

“And why isn’t human-in-the-loop activated?” the medical representative asked.

“Medical parameters are currently only updated based on live samples; some micro-clusters haven’t been populated with data yet,” Linh said. “V1.1 assumes that medical data is evenly distributed. Here we have a cluster—but the cluster isn’t automatically identified.”

“V1.1 has improved overall,” logistics said. “But it doesn’t account for every cluster.”

Their language was scientific: *cluster*, *bias sampling*, *false negative*. No one used the word *error*. Everyone used milder terminology.

I asked, “Who is responsible for this?”

No one answered directly. There were suggestions: compensate for lost output with overtime, compensate for temporary medical expenses, update the algorithm to add a cluster detection parameter. All options were reasonable—because they reduced the expected risk on paper. All options were costly—because they reduced today's output.

Ultimately, the decision was condensed into a single order: *Deploy V1.2—add micro-cluster detection; reduce the optimal weight for route A in case of related water tickets; human-in-the-loop activation if cluster detected*. The order came with a milestone: monitor 30 cycles.

Work began. The software team mapped the detection. Medical uploaded additional data. Logistics refined the backup route. Another patch, a dotted line in the log.

That night, as I was alone in the dispatch room, the screen displayed the numbers: *actual loss: 0.12% increase; output lost for the day: 1.8% due to maintenance team relocation; Temporary cost: X units; forecast a 0.9% decrease next week due to shift compensation.* I typed a few lines into the log: *Error: result of a preference series — data not yet Covering every micro-zone — the system responds according to the existing parameters.*

I think of Huy and people like him — people who add a few lines, a few notes about people. They can't save the filter valve. They only increase one line of data, but that data isn't enough to change the decision in time.

The error here is the problem of imperfection: the system processes according to expectations; people behave according to the table. When both match, everything runs smoothly. But when a small variable deviates from the expected distribution, slow and tedious consequences appear: patients are admitted to the hospital, production schedules are disrupted, a family stares at each other in the waiting room.

On the screen, the **Point of no return** is still empty. The *touched* line hasn't appeared yet. Perhaps it's not time yet. Or perhaps the system, at its current level, can still patch further.

I turn off the screen.

Outside, the base continues to operate. The system has learned another case. We've patched it up a bit. And someone, tomorrow morning, will open a log file, see the 0.12% increase, record it, and that's it.

Errors aren't a tragedy. They're like a small brush that wears down the surface. And when the surface wears down enough, it reveals what's underneath.

*End of Chapter 12.*