I spend most of my time on systems, but a side project put me in front of a very different kind of compliance problem, and it changed how I think about logging.
The project was cleaning contracts for licensed childcare centres. Not the cleaning itself, the operations behind it. And the thing that surprised me was that the customer was almost never buying "clean." They were buying evidence.
Here is the shape of it. A licensed daycare gets inspected. The inspector does not watch you sanitize a bin of toys. They arrive weeks later and ask what happened on a Tuesday in March. If the only answer is "our cleaners came, they are good," that is not an answer. It is a claim with no backing store.
Any engineer will recognize the failure mode. The work was done and the work was untracked, which in a compliance context is the same as not done.
So the useful part of the contract was never the labour. It was the record. Every night: which surfaces, which product, which dilution, who signed off, timestamped, retrievable months later. That is an append-only audit log with a retention policy, described in different words.
A few things carried over almost exactly from software:
- Granularity has a cost. Log every wipe of every surface and nobody reads it, the same way nobody reads a DEBUG-level firehose. Log only "cleaned the room" and it proves nothing. The useful level is the one an auditor would actually ask about, which took a few iterations to find.
- Timestamps are the whole product. A record with no time on it cannot answer "what happened that Tuesday," and that is the only question anyone ever asks.
- The log has to be written by the person doing the work, at the time of the work. Anything reconstructed afterward is a guess with good formatting.
- Retention beats volume. One year of clean, boring, structured entries is worth more than three months of extremely detailed ones.
The other lesson was less comfortable. For a long time the operations side treated documentation as overhead on top of the real job. It is not overhead. In a regulated environment it is the job, and the physical work is the part that generates the record. Once you invert it that way, the process design gets a lot more obvious.
I see the same inversion go wrong in software constantly. Observability gets scoped as something you add after the feature ships, and then an incident arrives and the only honest answer is that nobody knows what the system did at 3am on the Tuesday in question.
The teams I have worked on that handled incidents well were not the ones with the cleverest architecture. They were the ones who could reconstruct a timeline without arguing about it. Same for the cleaning crews that keep their contracts. The ones who survive a licence review are not necessarily the most thorough. They are the ones who can show their work.
If you want to see how that gets packaged commercially, we ended up writing the documentation standard directly into the scope of work for daycare and childcare cleaning in Toronto, which turned out to be the part clients actually compared vendors on.
None of this is a novel insight. But it took a completely unrelated industry, with a regulator instead of a pager, to make me stop treating the log as a side effect of the work and start treating it as the deliverable.
Top comments (0)