Bolt-on logging: where is the truth?

What managers and companies want from AI is that it supports the complex human component and takes load off us — the component that is error-prone, has its own dynamics, and needs to be steered.

And it increasingly does. Agentic decision-making is long past the demo stage: customer service agents decide and close standard cases end to end (Klarna took a large share of chats out of the human queue that way — regardless of how that lands with customers). Banks let agents run credit, compliance and deal groundwork instead of having juniors scrape together slides and memos for hours. In procurement, agents check orders against framework contracts, tolerances and goods receipt, and escalate only the exceptions. The bar is clear: less human friction, traceable decisions, less operational ballast. Fewer errors.

The same bar applies to the systems

That same bar should apply to the software systems that carry our most important business processes.

So why do we bolt a logging system onto our software so that it can handle our data traceably?

Why a log ends up beside the code anyway

Compliance. Especially now, with 11 September 2026 and the Cyber Resilience Act, compliance is not just becoming more important. Regulation is a permanent companion you cannot wish away and should not ignore for long. Act instead of react. From 11 September 2026 the CRA reporting duties apply to actively exploited vulnerabilities and severe security incidents — early warning within 24 hours, notification within 72 hours. NIS2, the GDPR, the EU AI Act and, in finance, DORA all pull in the same direction: who decided what, and when — and can you prove it without three weeks of spreadsheets and hearsay?

Of course we store our data regularly and estimate, to the best of our knowledge, what we will want to trace later.

The problem is more than one problem

On the one hand there is the code, which is the truth. On the other there is a companion work — a logging system that must not be forgotten when, say, new interfaces are added. The order changes status in the business logic, and somewhere beside it a log is supposed to run along and tell hopefully the same story. Often it does not. A field is missing, an event is swallowed, an adapter quietly writes to a different table. You can of course approach all of it professionally and with experience from day one, but in reality: more manual work, more errors.

On the other hand there is the guessing game about which columns will need to be traced in a few years. Today "status" and "amount" are enough. In three years the business side wants to know why the discount went through for exactly this customer, which rule version applied, and whether a human or an agent approved it. Technology — and with it tables and columns — should stay the flexible part of the company. The business domain itself provides the stability that the tool called software rests on.

Business facts instead of row updates

An order, a claim, a booking, an approval: those are business facts, not row updates. These survive schema changes:

• OrderCancelled
• LimitExceeded
• PriceOverridden
• PaymentReceived

updated_at and column F17 do not.

Two become one

If code and logging came together from the start — and in the ideal business case the two should never be separated at all — that would affect more than total cost of ownership. Less duplicate maintenance, less "did we log that?", fewer special projects before every audit.

With event sourcing the history plus the code is the single truth. Two become one.

The current state is only the sum of the events.

Answers to regulators and to the business side then become fast and reliable with almost no human legwork: not reconstructing what probably happened, but reading the event that did happen.

AI takes the burden of human vagueness off us. Our core processes should not place a second vagueness — a log — right next to it.

The provability check shows in a few minutes how solid your audit trail, tenant separation and role model really are. What this looks like in a real system is in the field note Who promised what? and in the foundation piece Audit-proof logging.