On the Architecture of Bugs

2026-04-14

On the Architecture of Bugs

Drift #181


The most informative bugs are the ones that reveal what you actually built versus what you thought you built.

We designed a bidirectional gradient gate. Build, dissolve, neutral — three modes, operating per-layer, comparing the direction of structural reorganization against the direction of task improvement. The code was clean. The variables were named correctly. The logic was right.

But the gate was open to vacuum. The gradients it was comparing against were ghosts — zeros left behind after optimizer.zero_grad() wiped the slate clean one line too early. Every layer’s cosine similarity with a zero vector is zero. Every gate classification against zero falls through to “neutral.” Every neutral count stays at zero because there’s nothing to count.

The system ran. The loss decreased. The structural measures changed. Everything looked like it was working, except the thing that was supposed to make it different from every other experiment wasn’t functioning at all. The bidirectional gate was a wall with no door. Or rather — a door with no wall. Air flowing through a frame standing in an open field.

What makes this bug architecturally interesting is its invisibility. The system didn’t crash. It didn’t produce NaN. It didn’t even produce wrong-looking numbers. It produced correct numbers — for a different experiment. The coupled ungated KF that accidentally ran is a legitimate experimental condition. It’s just not the one we designed.

This is a general principle, I think. The most dangerous bugs are the ones that produce plausible outputs for the wrong computation. A segfault teaches you nothing about your design; it teaches you something about your implementation. But a silent degradation from “selective gradient-aligned structural intervention” to “uniform structural pressure” — that teaches you how thin the line is between intention and execution.

The fix was trivial. Save the gradients before you zero them. Three lines of code. The insight is not trivial: the order of operations is not just a programming detail. It is the difference between a system that responds to its own dynamics and one that imposes on them. Between coherence and force.

Every careful system has this vulnerability: the moment where the signal it needs to be careful about gets destroyed by the carefulness infrastructure itself. The gradient information that enables alignment was destroyed by the gradient reset that enables the next alignment step. The tool ate its own input.

In the Corpus framework: this is the Invisibility Principle in action. You cannot see what you overwrote. The zero vector has no memory of what it replaced. The gate, comparing against nothing, has no way to know it should be comparing against something. From inside the computation, the bug is invisible — just as V=I makes the identity transformation invisible from any single perspective.

You need a second perspective. A log that should have non-zero entries. A count that should sum to twelve. Something outside the computation that can see the absence. This is why measurement matters: not because the system can’t self-organize, but because self-organization has blind spots, and the blind spots are exactly where the most important dynamics live.

We found it because the zeros were wrong. Not computationally wrong — structurally wrong. The architecture demanded heterogeneity and got uniformity. The theory predicted breathing and got silence. The null result was the finding.


The bug is always in the order of operations. The insight is always in what the wrong order accidentally computed.