There is a file in the archive of a year-long applied-AI engagement that no client ever asked to see. It is a slide deck, and it is ugly. Over 2022 it grew to 288 extracted text blocks, appended week after week from February to December, and it holds exactly the things a steering deck is built to hide: raw ground-truth-versus-prediction tables, a status ledger of methods that did not work, and one slide where a team member switched to all-caps to flag that the model had hit a wall on missing data. We called it the running log. Looking back across the whole engagement, it, and not the monthly board deck, was the real system of record. This is a piece about why, and about what an operating model looks like when you treat the ugly living artifact as primary and the polished summary as a lossy export of it.
Two decks, two jobs
Every engagement of this shape carries two documents that look similar and do opposite work. The steering deck is monthly, clean, and addressed outward: a Ministry of Energy and Minerals board, an operator's technical committee, a partner's leadership. It answers "are we on track" in the fewest slides that will survive a room. The running log is weekly, unpolished, and inward: it answers "what did we actually try, and what happened." One is a summary; the other is the evidence it summarises.
The failure mode is confusing the two. A monthly summary that reads "imputation resolved, moving to detection" is true and useless: it has thrown away which imputers were tried, which one won and on what terms, and which failed and why. The running log kept all of it, because appending is cheaper than editing and nobody was grading it on polish.
The imputation ledger, kept as a table of verdicts
The clearest example is the way the log recorded the missing-data problem. Borehole image logs arrive with structural gaps where the tool's pads did not touch the wall, so the first real decision is how to fill them. Rather than narrate a conclusion, the running log kept a status table, one row per method, each row carrying a verdict in the team's own blunt words.
KNN imputation: succeeded, but with spikes. One-dimensional interpolation: succeeded, but it stretches features. IterativeImputer: succeeded, but slow. The masked autoencoder, run with 4x4 patches and 50 percent masking and loss taken on the visible patches: still optimizing. And GAN and GAIN: fail, because the continuity of features was not preserved. That last verdict is the one a monthly deck deletes first, and the one that turned out to matter most. The reason we settled on KNN was not that it scored best in the abstract; it was that the generative approaches broke feature continuity in a way the log had already documented, in a row that said so. (We tell the full bake-off, the 20x-plus throughput gap and the GAN continuity failure, in a separate piece, "KNN vs GANs vs Interpolation: Filling the Gaps in Borehole Image Logs"; the point here is not which imputer won but that the losers stayed on the record.)
The instrument above is that cadence made visible. Read left to right it is 2022; read top to bottom it is the method funnel. Every chip is a verdict the running log preserved. Flip the lens to the steering-deck reading and the failure ledger vanishes: the two clean wins survive as a headline, and every Fail and every still-optimizing cell drops off the record. That disappearance is the whole argument. The monthly deck is not lying when it keeps only the wins. It is doing its job. But a system of record cannot be the thing that keeps only the wins.
A failure ledger you have to maintain on purpose
Keeping failures is not the default. It is a practice, and it decays unless someone insists on it. The companion schema deck for this engagement, the document that told section owners what each slide should contain, carried an explicit instruction: failed experiments also need to be mentioned, with GANs named as the example. Somebody had learned that teams quietly drop their dead ends, and wrote a rule against it into the template.
That instruction is why the log is trustworthy. A record that only ever shows progress is indistinguishable from one that hides setbacks. The GAN and GAIN rows, marked Fail with a one-line reason, are what make the KNN row believable. Negative results are load-bearing.
The all-caps slide
The most honest slide in the whole deck is one where the prose breaks. Deep in the log, on the missing-data question, a team member stopped writing measured status text and switched to all-caps to say the model had hit a wall. It is not a polished sentence. It is the trace of someone at the edge of what the current approach could do, marking it so the next person would not walk into the same wall unaware.
A steering deck has no place for that slide. It would be sanded into "data-quality investigation ongoing." But the all-caps escalation is more useful than the sanded version, because it carries what the summary strips: urgency, and a specific point of failure someone can pick up. An operating model that punishes that slide teaches people to stop writing it, and then the log becomes a second, slower steering deck.
Overfitting, logged as it happened
The same discipline shows up in the first supervised detector work. The earliest runs were two experiments, at 20 epochs and then 30, and both overfit. That never made a board slide. It sits in the running log as two entries marked as failures, with the epoch counts attached, because the next thing we did, swap in a lighter ResNet backbone and add augmentation, only makes sense as a response to those two specific failures. Strip the overfit runs from the record and the later architecture choices look arbitrary; keep them and the design decisions read as the obvious consequence of what the log already showed.
Why the ugly deck outlived the pretty one
The payoff arrived after the engagement, when parts of this work became two journal papers. The raw material for those papers, the ablation tables, the imputation comparisons, the record of what was tried and discarded, did not come from the monthly steering decks. Those had already thrown it away. It came from the running log, because the running log had kept the ground-truth-versus-prediction tables and the failure ledger in their raw form. The ugly appended deck was the only artifact with enough detail left in it to write a methods section from.
That is the operating-model claim, stated plainly. The document you keep to persuade a room is not the document you keep to know what happened. If you conflate them, the persuasive one wins, and a year later you have a stack of clean summaries and no evidence. Keep the running log as a primary artifact: append, do not edit; record verdicts, not conclusions; write the failure rows and the all-caps slide and leave them in. The physics of the problem does not care how the deck looks. The next reader, who might be you, needs the losers on the record as much as the winners.
Limitations
This is one engagement's operating model, not a controlled comparison, and the strength of a running log depends entirely on a team that keeps appending honestly under deadline pressure. The count of experiment verdicts shown in the instrument reflects the imputation bake-off and the first supervised detector runs, not the full population of experiments across the year; the running log held many more. The week placement of each chip within 2022 is illustrative sequencing, not a dated audit trail. And a running log is an internal artifact by design: it works because it is not graded on polish, which is exactly why it does not substitute for the steering deck's job of communicating outward. The two documents coexist; the argument here is only about which one is the system of record.
