Signs the Failure Is in the Seams, Not the Model

Mostafa Dhouib·September 6, 2026·7 min read

Signs the Failure Is in the Seams, Not the Model

The short answer. Five signs: every component passes in isolation, each team's investigation stops at their own boundary, the failure only appears assembled or under production conditions, nobody can name which layer is responsible, and adding specialists has not helped. A failure with those properties does not live inside a component, so buying more depth in any single component cannot reach it, however good the specialist is.

There is a specific kind of stuck that costs organisations quarters. It sounds like this in a status meeting:

The model team has tested the model and it meets spec. The platform team has tested the pipeline and it meets spec. The hardware team has tested the board and it meets spec. Everyone is correct, everyone is being honest, and the system does not work.

That is not a mystery. It is a well-defined class of failure with a location, and the location is between the boxes rather than inside them.

Sign one: every component passes in isolation

The most reliable indicator, and the one people misread most often.

When every part passes its own tests and the whole fails, the natural conclusion is that the tests are not good enough. Sometimes that is true. More often the tests are fine and they are testing the wrong scope: each one verifies its component against its own assumptions, and the failure is that two components hold assumptions that disagree.

Units in one place and different units in another. One side treating a field as optional and the other requiring it. A timeout on one side shorter than the retry interval on the other. A model expecting normalised input receiving raw input that looks plausible either way.

None of these is a bug in a component. Each component is doing exactly what it was specified to do, and the specifications were never reconciled with each other.

Sign two: every investigation stops at a boundary

Listen to how the answers end.

"We traced it to the point where we hand off to the platform, and everything is correct on our side."

"We receive what they send us and process it correctly."

Both statements are true. Both investigations were competent. Both ended at the same boundary from opposite directions, and nobody crossed it, because crossing it means understanding two systems well enough to compare what one intended against what the other received.

The tell is that after weeks of work you have several confident partial answers and no complete one. That is not a resourcing problem and adding people to either side does not change it. What changes it is one party who owns the comparison across the boundary rather than the correctness of either side.

Sign three: it only fails assembled, in production, or at scale

A component failure reproduces in a component test. A seam failure needs the other side present to appear at all.

So the symptom profile is characteristic: works on the bench, works in staging, fails in the field. Works at ten requests a second, fails at a thousand. Works with the simulator, fails with the real device. Works when one team runs it end to end manually, fails in the automated path.

Each of those pairs differs by what is connected and under what conditions, not by what any component is doing internally. When the reproduction recipe requires assembling the system, the failure is a property of the assembly.

Sign four: nobody can name the responsible layer

This one is diagnostic precisely because it feels like ignorance and is actually information.

Ask each team which layer they believe is the constraint. If you get four different answers, that is not four teams being unhelpful. It is a system where the failure does not sit in a layer, so no layer's view contains it and every honest observer points elsewhere.

Compare that to a component failure, where the answers converge quickly. When a model really is at its ceiling, the platform team can usually tell you that too, because they have watched the inputs go in clean and the outputs come back wrong.

Divergent answers from competent teams is the signature of a cross-layer failure.

Sign five: adding specialists has not helped

The counter-intuitive one, and the one with the most expensive consequences.

Each specialist you add creates boundaries with everyone already there. Two parties have one seam. Four have three. Eight have seven. If the failure lives in the seams, resourcing the components adds surface to the exact place the problem is.

This is how a program gets worse as it gets better resourced, which sounds like a joke until you have watched it happen. The org chart looks stronger every quarter. The number of places where two assumptions can silently disagree grows faster than the depth in any component.

It also explains why a large integrator does not solve it by being broad. The breadth is real on the org chart and the hand-offs are internal, which means the same seams exist and you can no longer see them.

What to do instead

The fix is not more depth. It is somebody whose scope is the boundary.

Write down what crosses each seam. Literally: the fields, the units, the ranges, the timing, the ordering guarantees, who retries and how often, what happens on a partial success. Most organisations have never written this down for any of their boundaries, and the act of writing it finds the disagreement surprisingly often, before anyone runs anything.

Instrument at the boundary, not in the components. Capture what one side sent and what the other received, and diff them mechanically rather than by reading two logs side by side. This is the same move as comparing intended tool calls against executed ones: the comparison is the instrument, and its absence is why the other failures stay hidden.

Make one party accountable for the seam. Not for both components. For the agreement between them, with the authority to change either side. Where that ownership does not exist, the boundary is defended from both directions and improved by neither.

Reproduce with both sides present before changing either. A fix applied to a component for a failure that lives between components will sometimes appear to work, because it perturbs the timing. It comes back.

The procurement consequence

The reason to identify this early is that it determines what you can usefully buy.

A failure inside one layer is a depth problem, and the right purchase is the best specialist you can find in that layer. A failure across layers is a different category, and buying depth in any single layer cannot reach it however good the specialist is. That is the third option as a purchasing decision: not broad and shallow, not deep and narrow, but one party accountable across the boundary.

Getting the category wrong is the expensive mistake, and it is usually made before anyone technical is in the room.

FAQ

How do I know if a failure is in the integration rather than the model? Five signs: every component passes its own tests, each team's investigation ends at their own boundary, it only fails assembled or in production or at scale, teams give divergent answers about which layer is responsible, and adding specialists has not helped. Those together indicate the failure is a property of the assembly.

Why do all our components pass while the system fails? Because each component is tested against its own assumptions, and the failure is that two components hold assumptions that disagree: mismatched units, a field optional on one side and required on the other, a timeout shorter than the other side's retry interval. No component is buggy and the specifications were never reconciled.

Why does adding more specialists make it worse? Each party you add creates boundaries with everyone already present, so the number of seams grows faster than the depth in any component. If the failure lives in the seams, resourcing the components adds surface to exactly the place the problem is.

Who should own a cross-team failure? One party accountable for the agreement between the components rather than for either component, with the authority to change either side. Where that ownership is missing, the boundary is defended from both directions and improved by neither.

What is the first concrete step? Write down what crosses each seam: fields, units, ranges, timing, ordering guarantees, retry behaviour, and what happens on a partial success. Most organisations have never documented this for any boundary, and writing it down frequently exposes the disagreement before anything is run.