Most Systems Don't Hide Their Loops

Most systems do not hide their loops.

A distribution warehouse in the central valley of California, late on the last Friday of the quarter. The cycle-count report shows one hundred and two units of SKU-4412 on the shelf. The ERP says there should be one hundred. No deliveries since the last count. No outstanding picks. The cameras show an empty aisle. The manager writes a two-unit adjustment, closes out the week, and goes home. Monday morning, forty of the two hundred and ten SKUs on the cycle count come back off by one or two in one direction or the other. She opens a ticket.

In Why Systems That Make Sense Still Fail I wrote about why this kind of thing happens — about the shape of the problem, about holonomy, about how a state can travel around a loop in a system and not quite come home. That essay was about what it is. This one is about the work: how to find the loops in a system you actually operate, without a research budget or a simulation stack. A spreadsheet. A notebook. Some patience.

The uncomfortable part is that most systems are not hiding their loops. We just have not been in the habit of looking for them.

If a system has feedback, it has loops. If a system has reconciliation, retries, audits, corrections, reviews, quarterly anything — it has loops. You do not need to prove they exist. You need to surface them.

A loop is a simple object. Something leaves a place, goes through a sequence of transformations, and comes back. That is the whole definition. If you can write a chain like A → B → C → A and the arrows correspond to real steps in the real system, that is a loop, and it is the only kind of loop you need to find today.

The reflex here is to open a diagramming tool. Do not. The tool you want is a spreadsheet, because the one skill the exercise requires is the discipline of finishing a row before moving to the next one, and a diagram does not enforce that. A blank grid does.

Four columns are enough to start. The step, in order. The system or owner performing it. The thing being transported — not the message-body, the actual thing the step is about. And the transformation that happens there. For the SKU-4412 loop above, the rows come out looking like this.

Five rows. The loop is visible now. Nothing needed a whiteboard.

The reason most people get stuck at this step is that they stop after the second column. Listing the systems involved is the easy half. The useful half is the third column: naming the thing in motion.

Every loop carries something. Money. A data record. A decision. A forecast. A commitment. Authority. An assumption. An expectation of what will be true next quarter. If you cannot name what a loop is transporting, you cannot see it drift, and you will probably end up debugging the last step in the chain when the problem is a reinterpretation four steps upstream.

In the inventory loop, the thing in motion is not “data.” It is a belief about the current stock. Along the way that belief picks up attachments: accounting's valuation, reporting's rolling average, reorder's forecast of next week's demand. Those attachments travel as part of the state. They compose. And each one of them is a chance for the state that comes back to your warehouse on Monday to be a slightly different belief than the one that left on Friday.

With the table in front of you, there is one question.

If I go around this loop once, do I get back exactly what I started with?

You do not need math to answer it. You need to name, honestly, the places where the transformations are lossy or ambiguous. The common sources are boring:

• Delays, which let the state evolve between reads and writes.
• Rounding, batching, and bucketing, which erase information you may have wanted later.
• Reinterpretation, when a downstream system assigns different meaning to the same field than the upstream one did.
• Caches and denormalizations that re-derive from stale inputs, quietly freezing a version of the past into the future.

If you can answer “no” to any of those, the loop does not close cleanly. You have found drift. The question is now whether it matters.

Concrete is better than theoretical here. Start at one hundred units. Walk once around the SKU-4412 loop: sales decrements five, accounting revalues the remaining ninety-five against a month-old cost average, reporting rolls the revalued number into a category aggregate that rounds, reorder's forecast sees the smoothed aggregate and issues a buy order, the warehouse receives seven units against it. End of loop: one hundred and two units. No one added inventory. The loop did.

Two units on one SKU over a week is invisible. Two units per week across ten thousand SKUs, drifting in one direction because the rounding is not symmetric, is a slow disaster that shows up as margin compression six quarters later and an auditor's question the next. The number you want is not whether the loop drifts, which it always does; it is the rate and direction and whether the system's corrections find it before the accumulation becomes expensive.

Once the first loop is visible, the practiced move is to look for siblings. Three angles work, in roughly this order of accessibility.

The first is to ask what feeds back. For every output the system produces, trace where it eventually influences itself. Write the chain as far as you can — A → B → C → A, or the longer A → D → E → B → A. Partial chains are fine; you are surveying, not proving.

The second is to ask what gets corrected. Corrections imply loops. Reconciliation batches, retries, audit trails, monitoring alerts, cycle counts, end-of-day reviews. If something in your system has a job of fixing things, there is a loop somewhere producing the things that need fixing. Do not just fix them faster; trace the shape that produces them.

The third, and most uncomfortable, is to ask what is eventually re-decided. Forecasts reconcile against actuals, which shape the next forecast. Strategy sets priorities, which shape execution, which shape metrics, which rewrite strategy. Compensation targets meet compensation, which meet next year's target. These are the loops most organizations run without noticing they are loops. Organizations, as it turns out, are mostly loops.

The re-decision loop deserves its own concrete example, because it is the one that shows up in almost every company and almost every government, and because it has the best-documented failure mode in recent memory. In September 2016 the Consumer Financial Protection Bureau announced that Wells Fargo had opened approximately two million checking and credit-card accounts without customer authorization. The number was later revised upward past three million. The metric under which this happened was cross-sell — products per household, an average the bank had publicized for years as its defining edge — and the loop that produced the failure is legible in the consent order. Set a cross-sell target. Measure the number of accounts opened. Compensate employees directly on the measurement. Baseline the next quarter's target off this quarter's result. Each step was rational. The measurement was accurate. The compensation was legal. The target was reasonable given the previous target. And the state the loop was supposed to preserve — the bank's actual relationship with its actual customers — did not come back unchanged. Wells Fargo paid an initial hundred and eighty-five million dollars to settle the federal charges, fired over five thousand employees over the next year, and spent five years under an asset cap imposed by the Federal Reserve in 2018.

What you are practicing, across all of this, is a reframe. The default engineering question is what is broken? You are learning to ask what does not compose? That is a different class of question, and it pays attention to a different class of artifact — the shape of the graph, not the health of the nodes.

Once the question changes, a lot of ambient weirdness stops looking weird. A report that never reconciles. A service that sometimes double-counts in ways that cannot be traced to any one request. A team whose priorities appear to rotate between planning cycles without anyone deciding to rotate them. A forecast that is consistently off by a small fraction, in one direction, for reasons nobody can quite name. These are not anomalies. They are the loops of your system finally being traversed in front of you.

Do not try to map the whole system. That is a project, and it will take all the oxygen out of the room before producing anything actionable. Pick one loop. A report that will not reconcile. A process that has felt off since the reorganization. A decision pattern that keeps drifting in a direction nobody is advocating for. Build the four-column table. Name the thing in motion. Ask if the loop closes. Measure the drift.

Find the loops. Name what they transport. Ask if they close. That is the whole method. The first one takes an afternoon. The next few go faster, because you have started seeing the shape.

Not all holonomy matters. Some systems tolerate drift. Some damp it. A few amplify it, and those are the ones that produce the Knight Capital mornings and the Wells Fargo decades. The next piece will be about measuring drift more carefully: how to tell accumulation from oscillation, which loops to actually worry about, and when intervention is cheaper than tolerance.

In the meantime: most debugging starts by isolating components. This is different. You are looking for something that only exists when everything is connected — a fact about how the parts compose, not about any one part. That is why it has been hard to see.

Once you start looking this way, systems get simpler. Not because they are simpler. Because you are finally looking at the thing that has been producing the behavior all along.