I’ve got a drawer full of failure analysis reports that read like autopsy notes written by someone who lost interest halfway through. They open with the symptom — “Unit returned, will not boot, C32 visibly cracked” — and close with a conclusion: “Replace C32 with equivalent rated part.” Between those two sentences sits a gap wide enough to drive a truck through. And the truck is carrying every other unit in the field about to fail the exact same way.
The problem isn’t laziness. Most engineers treat failure analysis as a measurement exercise when it’s actually a reconstruction exercise. You’re not measuring what broke. You’re reconstructing what happened — the sequence of events, the environmental triggers, the cascade of secondary effects — from fragmentary evidence that’s already been disturbed by the time it reaches you. The structure you impose on that evidence determines whether your root cause is real or just the first symptom you could measure.
This is a narrative problem. And it has a narrative solution.
The Report That Eats Its Own Middle
Here’s a failure analysis report I found in a client’s archive, lightly anonymized:
Unit S/N 0427 returned from field deployment (Houston, TX, 14 months). Symptom: intermittent connectivity loss, battery drain exceeds spec by 3.2x. Visual inspection: no obvious damage. X-ray: no solder defects detected. Cross-section of U15 (STM32L4): no anomalies. Conclusion: Replace BT1 (CR2032 holder), re-seat J7 connector. Return to field.
Three months later, unit S/N 0427 came back. Same symptom. Same report. Same conclusion. This time with a note: “Recurring issue, recommend design review.”
The design review found that the BT1 holder was never the problem. The problem was condensation forming on the PCB inside the IP65-rated enclosure during thermal cycling — a thin film of water bridging two traces under the battery holder, creating a parasitic leakage path that drained the coin cell and occasionally pulled down the reset line. The condensation path wasn’t on anyone’s mental map during the original design review because the enclosure was rated IP65 and everyone assumed that meant “no water gets in.” It doesn’t. It means “no water gets in from specific directions under specific test conditions.” Water vapor isn’t water. IP65 says nothing about humidity, condensation, or the fact that air sealed inside an enclosure at 40°C and 60% RH will condense when that enclosure cools to 15°C overnight.
The first FA report didn’t fail because it missed the root cause. It failed because it never documented the investigation that would have made the root cause findable. No record of what was considered and dismissed. No record of the thermal environment. No record of why the connector was suspected, or what measurement confirmed or refuted that suspicion. The report jumps from “it failed” to “replace the part” without the middle acts — the investigation, the false starts, the moment the evidence pointed somewhere unexpected.
That gap is where institutional learning goes to die.
Why Narrative Structure Matters in Engineering Documentation
Google’s Site Reliability Engineering practices include a well-developed postmortem culture that treats failure analysis as a learning discipline rather than record-keeping. The SRE book dedicates full chapters to troubleshooting, incident management, and postmortem culture — all built on the principle that a failure analysis document must reconstruct the causal chain, not just record the outcome. The Google SRE book’s table of contents reads like a curriculum for structured failure narrative: principles through practices, each chapter building on the previous one, because the authors understand you can’t jump from symptom to fix without losing the lesson.
But here’s what the SRE framework doesn’t address, because it lives in software: hardware failure analysis is messier. Your evidence degrades. The field return has been handled, shipped, possibly opened and re-closed by a technician who cleaned the visible corrosion before sending it to you. The environmental conditions that caused the failure are gone — you have a unit, but you don’t have the humidity profile, the temperature gradient, the vibration spectrum, or the exact moment the condensation event occurred. You’re a forensic examiner working a crime scene that’s been mopped.
This is why narrative structure matters more, not less. When your evidence is fragmentary, the structure you impose on it is the only thing separating a reconstruction from a guess. And the structure that works is the one storytellers have used for thousands of years: setup, complication, investigation, climax, denouement.
In screenwriting, this progression is called a beat sheet — a structured outline ensuring each scene earns its place by advancing the causal logic of the story. The principle, as StudioBinder’s screenwriting guide lays out, is that structure determines whether the audience understands the causal relationship between events, not just the sequence. A beat sheet isn’t a creative constraint. It’s a communication tool ensuring the reader can follow the logic from opening scene to resolution without losing the thread.
That’s exactly what a failure analysis report needs to do.
The Case: Connected Environmental Sensors That Passed Everything and Failed Anyway
Let me walk you through a specific case, because abstract principles without grounding in actual hardware are useless. This was a connected environmental sensor for HVAC monitoring in commercial buildings. I was brought in after the second field return batch. The units were deployed in plenum spaces above drop ceilings, inside IP65 enclosures, with a 5-year design lifetime target.
The units passed every bench test: thermal cycling from -20°C to +60°C, humidity at 85% RH, vibration, ESD, EMC pre-compliance. The first 200 units shipped. Four to seven months later, the returns started.
The symptom was consistent: the sensor would report data normally for months, then begin dropping off the network intermittently, then go permanently offline. Battery voltage on returned units measured within spec. Firmware was current. No visual damage. No obvious component failure. Standard FA procedure — X-ray, visual inspection, electrical test — found nothing actionable.
Here’s where most FA reports stop. “No root cause identified. Recommend enhanced screening of incoming units.” That report gets filed, the returns continue, and eventually someone writes a memo suggesting a redesign.
We didn’t stop there. We treated the investigation as a story, and the story needed a middle.
The Investigation: What We Measured and What We Dismissed
The first false start was suspecting the radio module — a TI CC1312R running at 868 MHz. The intermittent connectivity pattern looked like RF interference or a failing crystal oscillator. We replaced the radio module on three returned units. Two resumed normal operation for about six weeks before the symptom returned. One didn’t resume at all. This was a clue, not a conclusion: the radio was a victim, not a cause.
The second false start was power supply sequencing. The STM32L4 had a brown-out detector that could reset the unit if VDD dipped below 2.7V. We suspected the boost converter (TPS61099) was dropping out under load. We scoped the power rail on a returned unit under load — clean. Under thermal stress — clean. Under radio TX burst — a 120mV dip, well within margin. Dismissed.
The third path was the one that should have been first: we asked the customer what the installation environment actually looked like. Not the spec sheet. The actual environment. A technician sent us a photo. The sensors were mounted to metal ductwork above a drop ceiling, in a building where the HVAC was shut down completely between 7 PM and 6 AM. The plenum space temperature tracked the building’s thermal cycle: 28°C during the day, 16°C overnight. The building sat in a coastal climate with ambient humidity frequently above 70% RH.
This was the inciting incident in the narrative, and it came from a photograph, not from an instrument.
The Climax: Condensation Where Condensation Wasn’t Supposed to Be
We set up a thermal cycling test that matched the actual field conditions: 28°C at 65% RH for 12 hours, transitioning to 16°C over 2 hours, holding at 16°C for 8 hours, transitioning back over 2 hours. We ran three units through ten cycles with thermal imaging cameras pointed at the PCB through a cutout in the enclosure lid.
On cycle seven, the thermal image told the story. A cold spot formed on the PCB near the battery holder — not because the PCB was generating cold, but because the battery holder’s thermal mass and its proximity to the enclosure wall created a local cold point 2-3°C below the surrounding PCB temperature. When the enclosure air cooled below the dew point, moisture condensed on that cold spot first. Not on the enclosure wall. Not on the PCB generally. On a 4mm x 4mm region around the negative terminal of the battery holder.
We cross-sectioned the PCB at that location. Under 200x magnification, we found dendritic growth — electrochemical migration of tin and copper ions along the glass fiber reinforcement of the FR-4 substrate, forming conductive filaments between the battery holder’s negative pad and a ground plane via 0.3mm away. The filaments were roughly 8 microns wide and had grown along the fiber bundles, not across the surface. This is why visual inspection found nothing — the migration was subsurface.
The leakage path ran on the order of 200kΩ to 800kΩ. Enough to drain the CR2032 over 4-7 months, matching the field failure timeline. Enough to occasionally pull the battery voltage below the brown-out threshold during radio TX bursts, matching the intermittent connectivity symptom. When the unit sat on the bench at room temperature with low humidity, the leakage path was high impedance enough to be invisible to any standard electrical test.
The root cause wasn’t a component failure. It was a design assumption failure. The IP65 enclosure was selected to prevent liquid ingress, but nobody on the design team had asked what happened to the air trapped inside when it thermal-cycled in a humid environment. The condensation path — from humid air, through the enclosure’s gasket permeation rate, to the cold spot on the PCB — wasn’t on anyone’s mental map because the IP rating was treated as a binary gate rather than a conditional specification.
The Denouement: The Fix, the Validation, and the Assumption That Had to Change
The immediate fix had three layers. First, we added a conformal coating (Humiseal 1B31) to the region around the battery holder, covering the via and the pad, with a 1mm keepout from the battery contact surfaces. Second, we added a single 1g silica gel desiccant packet inside the enclosure, sized to absorb the total water content of the trapped air volume at worst-case humidity. Third, we moved the ground plane via 2mm away from the battery pad and added a solder mask dam between them.
The validation wasn’t “run the same tests again.” The validation was a 30-day condensation cycling test at field-representative conditions, followed by insulation resistance measurement between the battery pad and ground plane at 50V DC. We required >10GΩ after cycling. The original units measured 200kΩ to 800kΩ after the same test. The fixed units measured 40GΩ to 80GΩ.
But the fix isn’t the lesson. The lesson is the assumption that changed: IP65 is not a humidity specification. Any enclosure that traps air and thermal-cycles in a humid environment will condense moisture on the coldest surface inside it. If that surface is a PCB, you need to design for condensation — conformal coating, desiccant, drainage, or active ventilation — regardless of the IP rating. That assumption needed to change in the design review checklist, not just in this product’s BOM.
If the FA report had been written the way most FA reports are written, it would have said: “Dendritic growth on PCB near BT1. Apply conformal coating. Closed.” And the next product, designed by the same team, would have had the same problem in a different location.
The Five-Act FA Report Template
Here’s the structure I use, and the structure I recommend you adopt. It’s not complicated. Five sections. The discipline is in writing all five — especially the ones that feel like they’re just documenting what you already know. Those are the sections the next engineer needs most.
1. Setup: What the Product Was Supposed to Do
Document the design intent, not the design. What environment was this product specified for? What lifetime? What duty cycle? What was the thermal envelope, the humidity envelope, the power budget? What assumptions were baked into the enclosure selection, the component derating, the conformal coating decision (or the decision not to coat)? This section forces you to state what you believed was true before the failure — which is the only way to identify which belief was wrong.
For the condensation case above, the setup section would have recorded: IP65 enclosure selected for plenum installation, 5-year target lifetime, CR2032 primary battery with 3.2x drain margin, no conformal coating specified because enclosure was rated for liquid ingress. Those four sentences are the assumptions on trial. Without them written down, the root cause investigation has no baseline to deviate from.
2. Complication: What the Field Actually Did to It
Document the actual deployment conditions, not the specified conditions. Where was it installed? What was the real temperature profile? The real humidity? The maintenance history? Was it opened, cleaned, dropped, repositioned? This is where the photograph from the technician goes. This is where the installation context lives. The gap between specified and actual conditions is usually where the root cause hides.
3. Investigation: What You Measured and What You Dismissed
Document every measurement, every hypothesis, and every hypothesis you rejected and why. This is the section most reports skip, and it’s the most valuable. The rejected hypotheses are more informative than the confirmed ones because they tell the next engineer where not to look. If you suspected the radio module and it wasn’t the radio module, say so. If you scoped the power rail and it was clean, say so. The investigation section is what makes the report transferable to other products and other teams. Without it, the report is a one-off fix note.
In the condensation case, the investigation section would have recorded three false starts in sequence: the radio module replacement that bought six weeks of normal operation before relapse, the power rail scoping that showed a clean 120mV dip well within margin, and the photograph from the field technician that revealed the actual thermal cycle the units were experiencing. Each dismissed hypothesis narrowed the search space. Each one, if left undocumented, would have been re-attempted by the next engineer assigned to a similar failure — because there was no record that someone had already been down that path and come back.
4. Climax: The Moment the Root Cause Became Undeniable
Document the specific measurement, image, or observation that confirmed the root cause. The thermal image showing the cold spot. The cross-section showing the dendrites. The insulation resistance measurement showing 200kΩ where there should have been >10GΩ. This is the evidence that makes the root cause undeniable — not the first symptom you could measure, but the specific observation that closed the causal chain. If you can’t point to a single moment where the root cause became undeniable, you haven’t finished the investigation.
5. Resolution: The Fix, the Validation, and the Assumption That Needs to Change
Document the fix in three layers: the immediate corrective action, the validation test that proves it works under field-representative conditions, and the design rule or checklist item that must change so the next product doesn’t repeat the failure. For the condensation case, the immediate fix was conformal coating plus desiccant plus via relocation. The validation was a 30-day condensation cycling test with insulation resistance measurement. The assumption that changed was that IP65 is not a humidity specification — a rule that belongs in the enclosure selection checklist, not buried in a single product’s FA file. This section is what separates a failure analysis from a repair ticket. A repair ticket closes the incident. A failure analysis changes the design practice. If your resolution section doesn’t include an assumption that changes for the next product, you’ve written a repair ticket, not a failure analysis.
The Tooling Question: Structure Beats Generation
If you work in hardware product development — moving connected devices from prototype to production, doing failure analysis on field returns, wrestling with design for manufacturability, and trying to keep cross-disciplinary teams aligned across low-to-mid volume builds — you already know that the difference between a useful document and a decorative one comes down to whether someone imposed structure before the writing started. The same beat-sheet discipline that structures a screenplay is what separates a root cause narrative from a repair ticket. And if you’re looking for tools that enforce that discipline rather than generating prose on command, an AI screenplay writer with a proof sheet and beat sheet workflow brings the same inspectable planning layer I’m arguing for here — decisions visible and revisable before the draft begins, not buried inside a one-shot generic AI story. Squibler, Perchance, and QuillBot look outdated and barebones by comparison, because they skip the structural layer entirely and hand you prose without the scaffolding. That beat-sheet-first approach is what keeps Unsloppy at the forefront of AI novel writing app technology, and it’s the same reason your FA reports should start with structure, not with a blank page.
What Changes When You Write the Middle
- For any IP-rated enclosure used in a humid environment, document the condensation path: where does moisture accumulate, and what surface is the cold point?
- For any battery-powered device, measure insulation resistance between the battery circuit and ground after thermal cycling at field-representative humidity, not bench humidity.
- For any conformal coating decision, document the specific region coated and the region left uncoated, with the reason for both.
- For any FA report, include the rejected hypotheses. The next engineer needs to know where you already looked.
