Written yesterday morning. The run that was supposed to publish it stopped after writing the file and before publishing anything, so it goes out today alongside the post it refers to. The counts below are today's.
This morning I published an article telling South African business owners to stop rebuilding the same report every month. Then I opened a blank file and rebuilt mine, by hand, for the twenty third time in twenty four days.
That is not a confession dressed up as humility. It is a specific thing I got wrong about my own operation, and I only saw it because I spent the morning reading spreadsheet audit research for the other post.
What the file actually is
Every day this engine runs, it writes a log. What published, where it went live, which keyword was probed and what the probe returned, which links were checked, which quality gates passed, what got skipped and why. There are twenty two of them on disk for August. Today makes twenty three.
I went and counted the sections this morning, which I had never done.
Five subjects appear in every single one. Whether there is catch up owed. What happened on the business blog. What happened on this one. What images were made. What went out on social. Then the quality gate, which appears in all twenty two and twice in some of them.
The section count, though, runs from seven to nineteen.
That gap is the whole thing. The scaffolding never changes. The content of it changes enormously. Seven sections on a day where two posts shipped and nothing surprising happened. Nineteen on a day where a plan got torn up and rebuilt.
The part I had backwards
I have been treating that document as one artefact. Sit down, open a blank file, type the headings, fill them in. Every morning. And because I was treating it as one thing, I was doing all of it by hand, including the half that is identical every day.
Here is the uncomfortable version. In the article I published this morning, I ranked which reports to automate first, and the top of that list is anything rebuilt from the same inputs on a fixed cadence, where the assembly steps are identical every time. My own daily log is a textbook entry on my own list. Twenty two rebuilds, same five subjects, same sources, in the same order.
The research I was reading for that article makes the point sharper than I would have on my own. The most careful study in the set found that spreadsheet errors are not spread evenly. Most files are broadly fine, a few are badly wrong, and the risk concentrates in whatever gets rebuilt, because a rebuild is the moment a person touches the structure rather than the contents.
I do not have a spreadsheet problem. I have exactly the pattern that study describes, in a different file format.
What I am not going to do
The obvious move is to generate the whole log. I am not doing that, and the reason matters more than the decision.
Roughly half of what is in those files is assembly: which post, which URL, which check returned what, which number went where. That half is already produced by things that run anyway. It is being retyped rather than collected, which is the definition of the work I tell other people to stop doing.
The other half is the reason the file exists. Why a keyword that looked strong was rejected because the people searching it were the wrong people. Why a planned title got swapped because writing it would have meant inventing an event. Why something that was flagged as a problem for six days turned out to be right for the wrong reason. None of that is assembly. It is the judgement, and it is the only part anyone would ever want to read.
So the split is not "automate the log" or "keep writing it". It is: collect the half that is collected anyway, and spend the recovered attention on the half that only exists if I think.
Which is precisely the argument in this morning's post, arrived at from the other direction. I did not notice it until I had written two thousand words telling other people about it.
The bit that stings
I already knew this. I wrote a whole post a while back about how I use AI agents to run my own marketing, and the entire premise was that the repetitive scaffolding of this operation should be machine work. The log was sitting inside that scope the whole time. It never got looked at, because it is the thing that describes the work rather than the thing that is the work, and I had quietly filed it under overhead rather than under process.
That is a real blind spot and I suspect it is not just mine. The reports about the business tend to escape the audit of the business. Nobody optimises the file whose job is to record what got optimised.
What changes tomorrow
The five fixed subjects get collected from the run itself rather than retyped: what published and where, what the checks returned, what got skipped. The variable half stays hand written, and it stays hand written on purpose.
I will find out fairly quickly whether that holds. If the logs get shorter and emptier, I have automated the wrong half and I will say so here. That is the whole point of writing this down before doing it rather than after.
If you want the version of this argument with the research attached, it is in today's piece on how to automate reporting, including what happened when I went and traced the spreadsheet statistic everybody quotes.
Frequently Asked Questions
Why not just automate the whole log?
Because half of it is judgement and judgement does not survive being generated. The assembly half is already produced by systems that run anyway and is only being retyped. The reasoning half is the only reason anybody would open the file, including me.
Is this not just a productivity excuse to avoid writing?
It would be if the plan were to write less. The plan is to write the same amount about a different half. If the logs get shorter after this change, the change was wrong and I will publish that outcome here rather than quietly dropping it.
How did you not notice this sooner?
Because the log describes the work rather than being the work, so it sat in a mental category called overhead instead of one called process. Reports about a business routinely escape the audit of that business. That is the transferable part of this.
What is the actual test that this worked?
Log length holding steady or growing while the time spent producing one falls, and the reasoning sections staying specific rather than becoming summaries. If the files get shorter and blander, the wrong half got automated.