Case Study 01 / 03
Root-Cause Investigation on an Ambiguous Production Bug
The situation. A recurring, unexplained data-loss bug in an automated export pipeline — a design tool's export was silently substituting the wrong asset into a document's background layer, with no error thrown. Two prior fix attempts, based on incorrect assumptions about where the fault lived, made the problem worse rather than better.
What I did. Refused to trust surface-level QC and built a pixel-level verification method to test the actual claim being made. Traced the fault to its precise structural cause by unpacking the file format directly rather than working from assumptions. Identified that my own first fix attempt had solved the wrong problem — caught it before delivery by re-testing against the original requirement. Documented the corrected root cause and the verified fix so a future team member could act on it without re-deriving any of it.
What this demonstrates. Comfort sitting with ambiguity rather than reaching for the first plausible explanation. Willingness to say my own earlier work was wrong and fix it rather than defend it. Documentation discipline that makes findings usable by someone else, not just understood by me.
01
Case Study 02 / 03
Building a QC Pipeline With No Single Point of Failure
The situation. A content-production pipeline needed quality control — but an early single-check approach missed a real, high-impact error: two supposedly-different assets turned out to be byte-identical, silently duplicated under different names. The single check had passed both, since each was individually valid.
What I did. Diagnosed why the existing check couldn't have caught that specific failure mode. Designed a second, independent verification layer specifically because it catches a different class of error than the first. Formalised both as a standing, non-negotiable process for every future batch. The same duplicate-detection logic was independently corroborated by a separate audit process weeks later — confirming the method generalises, not just patches one incident.
What this demonstrates. Systems thinking about why a control works, not just that it passed. Building for repeatability rather than solving the immediate instance. Comfort formalising a process improvement into a standing rule.
02
Case Study 03 / 03
Migration and Handoff Discipline Across a Multi-Session Project
The situation. A long-running, multi-phase project handed off repeatedly, with real information loss at each handoff — a referenced file that turned out not to exist, a routing map that described a dead-end rather than a working process.
What I did. Diagnosed the handoff process itself as the point of failure, not any individual piece of missing content. Restructured the documentation to explicitly flag anywhere something was unbuilt, unverified, or assumed. Built a persistent, append-only running log and a stable open-items register. Enforced a hard versioning rule after a real instance of confusion caused by skipping it.
What this demonstrates. Recognising a process failure rather than a content failure. Building infrastructure that prevents a class of error rather than fixing individual instances. The discipline to enforce a rule consistently even when inconvenient.
03