Loading Scale Systems...
Updated Sep 2026
10 min read

Seams

Why Failure Lives at the Join Between Well-Built Things

Introduction

Read enough accident reports and a pattern appears that is not what most people expect. The catastrophe usually did not happen because a component was badly made. It happened where two well-made things met.

The autopilot worked and the pilot was competent, and the trouble was in the moment control passed between them. The sea wall was built to a standard and the backup generators were sited to a standard, and nobody owned the question of whether the second standard assumed the first. The regulator was capable and the manufacturer was capable, and the certification sat in the space between them. In each case you can inspect every part and find nothing wrong, because the fault was never in a part.

The joins have a name in engineering - interfaces, boundaries, handovers - and a peculiar property: they belong to nobody. Every organisation has someone accountable for each system and almost none has anyone accountable for the gaps between them. This page is about why those gaps are where things break, why the people on each side were usually behaving correctly, and what can be done about a problem that by definition falls outside everyone's job description.

An old corroded pipe joined to a newer polished one by a bolted flange in an industrial plant
Two things that work, joined by something nobody specified together

Why the Middle Is Safe and the Edge Is Not

The inside of a system gets attention. It has an owner, a specification, a test suite, a maintenance schedule and someone whose reputation depends on it working. Decades of engineering practice have gone into making the middle of things reliable, and it shows: individual components now fail far less often than they did.

The edge gets none of that, for a structural reason rather than a careless one. A seam is defined by two specifications, written by two teams, at two times, for two purposes. Neither document describes the join, because the join is not inside either scope. The tests exercise each side under the assumptions its own designers held, and the assumptions were never compared. What sits between them is not a thing anyone built. It is a residue.

Charles Perrow gave this its clearest general statement in 1984 in Normal Accidents, written after Three Mile Island. His argument was that some systems fail not despite good design but because of two properties they possess together. The first is interactive complexity: parts affect each other in ways not foreseen and not visible while they happen. The second is tight coupling: there is no slack between stages, so a problem propagates before anyone can intervene. Where both hold, he argued, serious accidents are a normal property of the system rather than an aberration in it, and adding more safety devices sometimes makes things worse by adding interactions.

The word "normal" is doing careful work there, and it is often misread as fatalism. Perrow was not saying failure is acceptable or that nothing helps. He was saying that if you build a system with those two properties, occasional serious failure is a property you chose along with the design, and treating each one afterwards as a surprise caused by somebody's error will not reduce the rate.

Everyone Was Right Inside Their Own Edge

The most uncomfortable feature of seam failures is that the investigation rarely finds anybody being stupid. It finds a series of people making reasonable decisions with the information and the remit they had.

At Fukushima Daiichi in 2011 the sea defences were built to a design basis derived from the historical record, which is the normal and correct way to size such a thing. The emergency generators were placed low, which is normal and correct for heavy machinery, and which was safe on the assumption that the sea defences would hold. Neither decision was negligent. The two together contained an assumption that only becomes visible when you look at them as a pair, and looking at them as a pair was not a task assigned to anyone.

The Boeing 737 MAX contains two seams stacked on each other. One is between an automated system and the crew: a flight-control function that could act on the aircraft's pitch, and pilots whose training and documentation did not fully describe it, so the aircraft and the person were working from different models of what was happening. The other is regulatory. The Federal Aviation Administration delegates a large share of certification work to the manufacturer's own designated staff, an arrangement that exists because the regulator cannot match the manufacturer's depth on its own product. Both the delegation and the design decisions were defensible in isolation. The join between them was where the failure lived.

This is what safety researchers mean by local rationality: people act sensibly given what they can see from where they stand. Diane Vaughan's study of the Challenger launch decision made the point at book length, and the finding that stuck was not that anyone gambled with lives. It was that a deviation from expected behaviour, repeated without consequence, gradually became the expected behaviour - what she called the normalisation of deviance. Nobody decided to accept the risk. The risk was redefined, in small steps, into something that did not need deciding about.

The practical consequence is that hunting for the person who got it wrong is usually the least productive response available. If the failure came from the gap between two correct behaviours, removing a person leaves the gap exactly where it was, now staffed by someone with less experience of it.

The Handover

The sharpest version of a seam is the moment responsibility moves from one party to another. Handovers concentrate risk because they are where context fails to travel. The facts move; the reasoning behind them usually does not.

Automation handovers are the most studied case and the least intuitive. An autopilot that manages ordinary conditions and disengages in unusual ones has, by design, arranged for the human to receive control at the hardest possible moment, with the least recent practice, and often with an ambiguous picture of what is wrong. The 2009 loss of Air France 447 over the Atlantic followed that shape: sensors iced, the automation withdrew as designed, and a crew who had been monitoring rather than flying inherited a confusing situation in darkness. The automation did what it was specified to do. What was not specified was the state it left a person in.

Human-to-human handovers have the same shape with different content. Hospitals have long known that shift changes are among the more dangerous moments in a patient's stay. That is why structured handover protocols exist at all. The point of a fixed format is to force the transfer of things the outgoing person no longer notices they know. The same is true of the control-room handover, the case passed between caseworkers, the project inherited by a new team, and the code handed to whoever is on call tonight.

What is lost at a handover is almost never the data. It is the shape of the situation: which numbers are being watched and why, which reading was odd earlier, what has already been tried, which alarm is known to be spurious. That knowledge is held informally, it is what makes the outgoing person effective, and it is exactly the part no form captures.

A control room at shift change, one operator seated at lit screens and another handing something over
The facts transfer at a handover; the reasoning behind them usually does not

Nobody Owns the Join

Organisations distribute responsibility by dividing work into parts and giving each part an owner. This is the only arrangement that scales, and it produces one predictable blind spot: the divisions themselves belong to nobody.

You can see the effect in how seam problems get discussed. Each side describes the issue as belonging to the other, and both descriptions are accurate from where they are standing. The database team says the application is sending malformed requests; the application team says the database is rejecting valid ones. The planning authority says the developer should have surveyed; the developer says the authority approved it. Neither is lying. The question that would resolve it sits outside both remits, and so it is asked by nobody until something forces it.

Two features make this worse than an ordinary coordination problem. The first is that seams are invisible on the organisation chart. A chart shows boxes, and the boxes are what has owners. The lines between them are drawn as though they were free. The second is that seams multiply faster than parts. Split a system into more pieces and the number of possible joins grows much faster than the number of pieces. That is why reorganising a struggling organisation into smaller, clearer units so often creates new failures in places that used to sit inside somebody's head.

The same logic scales up to whole states. Financial regulation in most countries is divided among several bodies by institution type, and the crisis of 2008 travelled through the space between them: originators, packagers, rating agencies and buyers each operated inside a defensible frame, and the accumulating risk was nobody's assigned view. It scales down too. Most software outages traced honestly end at a boundary - between services, between a system and its configuration, between a deployment and the assumptions of the thing it was deployed onto.

What Makes a Seam Dangerous

Not every join is a hazard. Most are crossed constantly and quietly. Four features separate the boring ones from the ones worth attention, and they are worth knowing because they can be checked in advance rather than after.

Hidden assumptions about the other side. The dangerous seam is one where each side has been designed around a belief about the other that has never been written down or tested. Backup power that assumes a barrier holds. A retry policy that assumes the far end is idempotent. A department that assumes another department checks something. The test is simple and rarely run: ask each side to state what it believes about the other, separately, then compare the answers.

Tight coupling across the join. If a disturbance crosses the boundary faster than anyone can react, the seam converts a local problem into a system-wide one. Slack at a boundary - a buffer, a queue, a delay, a human confirmation - is what gives a system time to notice. Removing it is usually described as removing friction, and friction at a seam is frequently the mechanism that was doing the containing.

Asymmetry of information or expertise. Where one side understands the interaction far better than the other, the weaker side cannot ask the right questions and often does not know it cannot. This is the structural problem in regulator-and-regulated relationships, in outsourced technical work, and in any arrangement where the party doing the checking depends on the party being checked for its understanding of what to check.

Transitions that are rare and unrehearsed. A seam crossed a thousand times a day gets debugged by use. A seam crossed only in emergencies - failover, evacuation, manual reversion, the backup supplier - is exercised precisely when conditions are worst and everybody is least practised. Untested transitions are where plans that read well on paper fail on the day.

What Actually Helps

None of this yields a method that removes seams, because seams are what division of labour produces and division of labour is not optional. What follows are the interventions with the best record.

Give the join an owner. The single most effective move is usually the least technical: name a person or a group whose remit is the interaction rather than either side of it. Integration testing, systems engineering, joint operations bodies and inquest-style reviews are all versions of this. The consistent failure mode is making it a committee where both sides are represented but neither is accountable, which reproduces the original gap with more meetings.

Rehearse the rare transitions. If a seam matters only in emergencies, the only way to know whether it works is to cross it deliberately when nothing is wrong. Failover drills, evacuation exercises, and periodically buying something from the backup supplier all convert an assumption into a fact. Organisations resist this because the exercise has a cost today and prevents an event that may never be attributed to it.

Write down what each side assumes. Most hidden assumptions are not secret; they are simply unstated, and they survive because nobody has ever put the two sides' beliefs on the same page. This is cheap and uncomfortable, which is a common signature of useful checks.

Investigate to find the gap, not the person. James Reason pictured layered defences as slices with holes in them, the holes moving, an accident happening when they briefly line up. The image is useful mainly for what it implies about investigation. If the holes aligned, the question is what put them there and what keeps them moving, not which one to blame. An inquiry that stops at an individual has usually stopped one step early. Its recommendation will be more training, for a role that will shortly be filled by somebody new.

Reading Your Own Seams

The idea transfers to ordinary work and ordinary life with very little adjustment, because the mechanism does not depend on scale.

When something goes wrong at work, notice whether the failure was inside somebody's job or between two jobs. If it was between, the fix is not a conversation with a person; it is a decision about who owns the space. When you inherit a project, assume the most important thing you were not told is a reason rather than a fact - the facts are in the documents, and the reasoning went home with whoever left.

And when you rely on a fallback of any kind - insurance, a backup, an emergency contact, a second income - the question worth asking is not whether it exists. It is when it was last crossed. Arrangements never used are assumptions wearing the clothing of preparations, and the difference shows up at the worst possible moment.


Dividing work into parts is how anything large gets built, and it creates a category of place that belongs to nobody. The parts get owners, specifications and tests; the joins between them get assumptions. When something serious goes wrong, the investigation usually finds a sequence of people who were each behaving correctly inside their own edge, which is why looking for the person who erred so rarely improves anything. The joins are not going away, because they are what the division of labour is made of. What can change is whether anyone has been asked to look at them before the day they matter.

How something got there is usually the better question

An unhandled error has occurred. Reload 🗙