Who promised what? When nobody can reconstruct what happened

It is Tuesday, 09:17. A B2B SaaS company, around 120 people, Vienna plus remote. The account manager opens an email from one of the largest customers:

"The opt-out for passing data to sub-processors does not behave the way it was agreed in the contract and in the workshops. We consider this an acute compliance risk and expect a complete reconstruction by tomorrow."

Management wants four answers within 90 minutes: what exactly was promised, and when? Who approved the final specification? Why does the behaviour deviate? What are the legal and technical risks?

This is the moment that reveals whether a company knows what has happened inside it.

The search everybody knows

The tool landscape is unremarkable and typical: Jira, GitLab, Confluence, Slack, Google Drive, Notion in a few teams, Outlook, and for the past year an AI assistant meant to run "across everything".

• Jira holds three epics and seventeen tickets. Descriptions are incomplete, labels inconsistent, statuses untouched for months.
• The Confluence page "Privacy Feature Spec v2.3" was last edited nine months ago. In the comments, product and legal contradict each other. A newer version exists only as a link inside a Slack thread.
• The privacy channel has forty-plus threads. The decisive conversations happened in direct messages between the product owner, legal and architecture. Some of it is already gone through retention rules.
• GitLab holds three merge requests with commit messages like "quick privacy fix". The actual discussion sits in the comments, linked to no ticket.
• The workshop notes with the customer live in a Notion space the product owner did not know existed.

After two and a half hours, five people have assembled whatever was findable. The picture contradicts itself. The AI assistant produces a clean summary — but it does not know the direct messages or the latest legal opinion, so it constructs the wrong sequence and the wrong ownership. Nobody trusts the result enough to hand it to the customer or the lawyer.

What those ninety minutes actually cost

The obvious line item is the smallest one: five people, two and a half hours, usually the five most expensive in the building. Then come the items that appear in no budget:

• A second round, because the lawyer asks questions the assembled material cannot answer.
• Delayed releases, because product and architecture do nothing else this week.
• A contract risk that cannot be assessed, because what was promised is unclear. At seven-figure annual revenue, that is not a footnote.
• A loss of trust that has nothing to do with the defect and everything to do with the answer "we are still looking into it".

The real damage is never the single incident. It is that the same search happens four or five times a year and starts from scratch every time.

The change nobody can find

The deviation has a mundane cause. In July, a performance hotfix rewrote a feature flag configuration. In the process, the default for the opt-out flipped from "on" to "off".

In a classic system this is invisible. The configuration table holds a value, and that value is stored correctly. What was there before, who changed it and in what context disappeared the moment it was overwritten. The system can tell you what the world looks like now. It cannot tell you how it got there.

That is the structural point, not a documentation problem: storing only state loses reasoning and causality systematically — and quietly. The longer argument lives on Event sourcing: when it pays off.

The same situation, built differently

Suppose this company had started, a year or so earlier, to make three areas event-sourced — not everything, only where traceability hurts: customer commitments, compliance-relevant product decisions, and the central architecture decisions.

An event store holds the facts for those areas. Everything else stays. Instead of a state, there is a chain of events:

• CustomerRequirementCaptured — the verbatim requirement from the workshop
• LegalOpinionProvided — the legal opinion in full, with its conditions
• SpecificationVersionApproved — which version, approved by whom
• ImplementationDecisionMade — the architecture decision including its reasoning
• CodeChangeLinked — a reference to the specific merge request
• FeatureDeployedToProduction and CustomerNotificationSent — what shipped and what was communicated
• FeatureFlagDefaultChanged — the July change, with trigger and responsible person

Alongside the business payload, every event carries an aggregate id, timestamp, user and tenant, plus two identifiers that make the difference here: causation and correlation. One says which event triggered this one, the other says which business process it belongs to. The chain from customer request to hotfix is therefore not reconstructed — it is stored.

On Tuesday morning, someone opens a view computed from those events — a projection — and filters by customer and opt-out. What they see is the full chronology including the July change that explains the contradiction. Not in two and a half hours, but in the time it takes the page to load.

The Confluence page does not disappear. It simply stops being a second truth and becomes a derivation. When the specification changes, a new event is written; the old version stays in the stream instead of being overwritten.

Why AI agents get stuck exactly here

The assistant in the first half of this story did nothing wrong. It produced the most plausible picture from a pile of documents with no reliable timeline. In compliance matters, plausible is worthless.

An event stream changes the input: the agent gets no documents, but a time-ordered, permission-checked set of facts. Every statement traces back to an event with an id and a timestamp — verifiable, without having to believe the model. Anyone letting agents into business processes needs that traceability anyway, at the latest during the first audit.

Permissions run through the projection, not through the agent. Which events a user or tenant can see is decided one layer down — the same logic that applies to multi-tenancy with Keycloak.

What this does not solve

Event sourcing cannot surface an agreement that was never captured. If the decisive commitment still happens in a direct message and nobody turns it into an event, it will not be in any stream either. The gain is not that the system replaces the discipline — it is that the discipline is demanded in one visible place instead of spread across six tools.

The second honest point: this is not a tool purchase. The expensive part is agreeing on which events matter and what they are called. That is exactly why event modeling is first and foremost an adoption tool rather than an architecture diagram — it forces business, legal and engineering into the same language. It is the same transition described in the three transitions: decided is not implemented, implemented is not adopted.

The questions enterprises always ask

Right to erasure. An immutable stream and the right to deletion are not mutually exclusive, but they require a deliberate decision. Personal data does not belong in the event in raw form. The usual patterns are pseudonymisation with a separate mapping store, or crypto-shredding: the payload sits encrypted inside the event, the key lives outside and is destroyed on request. The fact remains, the personal reference goes.

Retention. Not every stream has to live forever. For closed processes, snapshots plus archiving are legitimate, as long as retention follows the business rules rather than convenience.

Access. Who sees which events is decided at the projection layer, not in the interface. That is more work than a role field in the frontend — and the reason auditors like these systems.

Existing systems. They keep running. Read models can be mirrored back into Jira or your own portal so teams stay where they already work. The same incremental logic as in modernising a monolith.

Where to realistically start

Four to six weeks to the first stream in production is achievable if the scope is right:

1. Pick one domain where the question "what happened?" is asked regularly and costs real money. Customer commitments, pricing and contract logic, or compliance decisions are the usual candidates.
2. Model the events together — business, legal and engineering at one table, on paper, before anything is built. That is what the event modeling sprint is for.
3. Put one stream into production, with clean causation and correlation ids from day one. Adding them later is painful. For an implementation on a dedicated event store, see the EventSourcingDB offer.
4. Build a projection that answers a real question — one customer's timeline, not a dashboard.
5. Mirror the read model back into the places people already work in.

If the prior question is whether the approach is worth it at all, the scope is in event sourcing without the fear. And if the question is who carries that decision internally: that is what fractional CTO is for.

What remains

The difference between the two Tuesdays is not a technology question. It is the decision whether the actual business events are recorded, or only their last state.

The honest check takes a minute: take the last uncomfortable customer question your company had to answer. How long did it take, and how confident was the answer in the end?