The Record Shows

Some failures announce themselves. They arrive without warning, from directions nobody anticipated, carrying evidence that has to be assembled piece by piece before the shape of the problem becomes clear. The previous four cases in this collection are of that kind — investigations that required tools, tests, hypotheses, replications, and in one case no resolution at all.

This case is not of that kind.

This failure was announced in advance. It was documented. It was communicated to the people with the authority to prevent it. It was overruled. The product launched. The failure occurred. And the people who had predicted it, documented it, and communicated it were asked, in the aftermath, why they hadn't done more to prevent it.

I have thought carefully about how to write this case. The others in this collection are investigations — forensic reconstructions of events that had already occurred, working backward from evidence to cause. This one is a different kind of account. It is not a reconstruction. It is a record. The record shows what was known, when it was known, and what was decided. What it cannot show — what no record can — is what the people in those meetings were thinking when they made the decisions they made.

I will confine myself to what the record shows.

The product was a monitoring adapter — a hardware peripheral designed to connect to the diagnostic port of industrial equipment and draw power from it. The adapter was an ODM product. A third-party manufacturer had designed and built it. Our client, a larger company with an established brand and the regulatory obligations that come with one, had licensed the design, applied their branding, and prepared to bring it to market as their own product.

This arrangement is common. It is also consequential in ways that are not always appreciated at the outset. The ODM manufactures to whatever standard it manufactures to. The brand that puts its name on the product is held to the standard of the brand. When a regulator looks at the adapter in the field, they see the larger company's name. They do not see the ODM. The regulatory obligation — the duty to ensure the product is safe, to identify risks, to communicate them, to address them — belongs to the brand.

Our client understood this. Most of the people in the room understood this. It mattered later.

The diagnostic port on industrial equipment is not standardized in its physical location.

This is the foundational fact of the case and it is worth dwelling on. The port serves a consistent function across equipment types — it provides access to diagnostic systems, allows external devices to draw power and communicate with internal systems — but where the port sits on the physical machine varies by manufacturer, by model, by generation. On some equipment the port is recessed, tucked into a housing, positioned well away from the operator's primary control area. On others it sits directly adjacent to the space the operator occupies and moves through during normal machine operation.

The adapter, when installed, protruded from the port. On equipment where the port was recessed or remote, the protrusion was irrelevant. On equipment where the port was positioned near the operator's control area, it was not. On those configurations, an installed adapter occupied space that the operator's hands, arms, or body would naturally move through during normal operation. The interference would disrupt normal operation. It would contact the operator during routine movements. It would, in certain configurations, create a meaningful safety hazard that the applicable regulatory agency would take seriously.

We knew which equipment configurations were problematic. The port locations were documented by equipment manufacturers. A compatibility analysis — mapping the adapter's installed dimensions against the port locations and operator workspaces of the major equipment makes and models — was not a complex undertaking. It was the kind of analysis that should have been part of the product development process from the beginning.

It was not part of the product development process from the beginning.

We raised it.

I want to be precise about what this means because the word raised carries a range of meanings in organizational contexts and the distinctions matter here. We did not mention it in passing. We did not include it as a footnote in a larger document. We identified the risk, characterized its scope, mapped the affected equipment configurations, estimated the population of users who would encounter it, described the regulatory implications, and communicated all of this to the product team in terms that were intended to be unambiguous.

The recommended mitigation was not a hardware redesign. It was not a recall-level intervention. It was a compatibility verification step in the purchase flow — a process by which customers would confirm their equipment make and model before completing the purchase, and would be advised against installation on incompatible configurations. Clear installation guidance. Explicit warnings. A filter between the customer and a configuration that would create a safety problem.

This was not an expensive fix. It was not a technically complex fix. It was the kind of mitigation that takes weeks to implement, not months, and that costs a fraction of what a post-launch remediation costs. It was a reasonable and proportionate response to an identified risk of known scope.

The recommendation was received. It was understood. It was not implemented.

The directive, as it was communicated, was to move fast.

The ODM knew what they were doing. The product had been designed by people with experience in this space. The launch timeline was the priority. The concerns that had been raised were noted — and this word, noted, does the specific work that it does in these situations, which is to acknowledge receipt without implying action — and the program would proceed.

What I know is what the record shows, and the record shows that the product launched without the compatibility verification, without the installation guidance for incompatible configurations, and without the explicit warnings that had been recommended.

The record also shows that the risk communication had been documented. This would matter later, though not in the way that documentation is supposed to matter.

The field feedback arrived quickly.

Customers reporting that the installed adapter interfered with their normal operation of the equipment. That it contacted their hands or arms during routine movements. That in some cases it had been dislodged during operation and fallen into the control area of the machine. The language in the feedback carried the register of people who had been startled — who had experienced, in the middle of operating equipment that required their full attention, an unexpected physical intrusion from a device they had installed and forgotten about.

This was not a product complaint. This was a safety signal.

Internally, the response was what the response always is when a predicted failure arrives on schedule. Urgent meetings. Escalating concern. The question — how was this missed, why wasn't this caught, who was responsible for identifying this kind of risk — asked with the genuine bewilderment of people who either did not know the answer or found it convenient not to.

The team that had identified the risk, documented it, recommended the mitigation, and been overruled found itself in the position that team always finds itself in.

It became the answer to the question.

The scapegoat is a very old mechanism. Its function is consistent across all of its applications: to concentrate the cost of a collective failure onto a specific party, relieving the remainder of the group of the burden of accountability. It works best when the designated party has some plausible connection to the failure. It works least well when the record is clear.

The record was clear.

The risk had been identified before launch. The mitigation had been recommended before launch. The recommendation had been overruled before launch. The product had launched without the mitigation. The failure had occurred exactly as described. The sequence was documented. The dates were documented.

None of this prevented the question from being asked. The record being clear does not mean the record is consulted. In the immediate aftermath of a visible failure, with external feedback arriving and leadership looking for an account of what happened, the record is often the last thing anyone looks at.

What people look at is who is in the room, and who is not.

The fix, when implemented, was what it had always been. Compatibility verification. Installation guidance. Explicit warnings. Everything recommended before launch, deployed after it. The safety signal subsided. The product continued.

I have been asked what the right move was.

Documentation helps. Formal escalation helps. A paper trail that makes the sequence irrefutable helps. All of those things were done here, and none of them were sufficient to redirect accountability in the immediate aftermath.

What documentation does is not prevent the scapegoating. It limits its duration.

The root cause here was not a component, not an assembly variation, not an unknown failure mechanism. It was a decision — made with full awareness of the communicated risk, in a context where speed was the priority and the consequences would be borne by people downstream.

You cannot do a failure analysis on a decision. You can document it. You can build the record. You can stand on the track and wave your arms.

You cannot stop the train.

What you can do — what the job requires, even when it feels insufficient — is make sure the record shows you tried.