The bureaucracy did not disappear. It moved.

Cancelling a mobile contract in Germany takes about thirty seconds. You open an app, confirm a name and a customer number, and the thing is done. Somewhere behind that, a letter is generated, transmitted, confirmed, and answered — and somebody is obliged to keep the resulting paperwork long after the customer has forgotten the transaction happened.

Not the customer. Not, usually, the counterparty. Increasingly, the platform that made those thirty seconds possible.

This is the shape of a problem that has been accumulating quietly across European consumer software, and it is worth setting out properly, because most of the teams carrying it have never been asked to look at it directly.

What these platforms actually did

A generation of companies built their entire product on removing bureaucracy from the user's day.

Cancellation services that handle terminations you would otherwise write yourself. Tax filing apps that turn a form nobody understands into eight screens. Insurance claims submitted through a chat window. Lending applications that resolve in an afternoon. Prescriptions and sick notes without a waiting room. Residency and registration processes reduced to an upload.

Each of these is a genuinely good product, and each works by absorbing a process that used to be the user's problem. That absorption is the value. It is also the liability, and the two are the same event.

The bureaucracy did not disappear when the interface got better. It moved one layer down, into the platform, where it is now somebody's operational responsibility rather than a citizen's afternoon.

The volume is larger than it looks

The intuition most teams start with is that a transaction produces a document. In practice it produces a small cluster of them, and the cluster is where the volume lives.

A single contract cancellation typically generates four to eight retainable artefacts: the letter itself, the dispatch confirmation, the postal or fax tracking record, the counterparty's acknowledgement, and often a follow-up exchange. A tax filing produces three to six — the declaration, the submission confirmation, the authority's receipt, correspondence. An insurance claim can run to fifteen once supporting evidence, dispatch logs and insurer correspondence are counted. A lending application sits around four to ten.

Multiply that by a platform doing a few hundred transactions a day and the arithmetic stops being interesting and starts being a system design question. Not because the bytes are large — they are not, and we will come back to that — but because each artefact carries an obligation that outlives the customer relationship by a long way, and the obligations do not expire when the customer churns, when the platform pivots, or when the engineer who set up the bucket leaves.

Where the paper trail actually lives

In conversations with engineering leads at platforms of exactly this shape, the honest answer to where does the trail live is remarkably consistent.

An object storage bucket. A lifecycle rule that somebody configured once. A cron job that has never been tested against a real retrieval. And a quiet hope that the question stays theoretical for another year.

This is not negligence. It is a rational response to an obligation that arrives without a deadline, without an owner, and without anyone asking for it in a sprint planning meeting. Nobody's roadmap has evidence layer on it until something forces the issue, and the thing that forces the issue is usually the worst possible moment to start.

The arrangement holds right up until someone asks two questions.

The two questions

Can you produce this document, unaltered, with evidence of when it arrived?

Note what the question is not. It is not do you have the file. Having the file is easy. The question is whether you can demonstrate that the file you are producing is the file that arrived, that nothing changed in between, and that the date you are asserting is the real one rather than a modification timestamp that a migration reset in 2024.

A bucket answers none of that. Object storage will faithfully return whatever is currently at the key. It has no opinion about whether that is what was written, and neither do you, unless you built something that does.

When the retention period ends, can you prove you destroyed it?

This one is worse, because deletion in a distributed system is not an event. It is an assertion that propagates. Replicas in two or three regions. Snapshots on their own schedule. Backups whose retention policy frequently outlives the object you just deleted. Write-ahead logs. A provider's internal tiering that moved a copy somewhere cold months ago.

When someone asks whether a document is gone, we called the delete endpoint and it returned success describes your intent. It does not establish an outcome.

Neither of these is a storage problem

This is the part that reframes the work, and it is why we think the category is mis-named wherever it exists at all.

Storage is solved. It is also cheap, to a degree that surprises people who have not costed it recently. A platform generating this kind of volume accumulates on the order of tens of gigabytes a month, and at the scale where retention obligations bite, the storage line on the bill is a rounding error against everything else in the system.

What is not solved is evidence. Both questions above are asking for the same thing in different clothing: a demonstration, to a party who has no reason to trust you, that a specific document existed in a specific state at a specific time, and later ceased to exist. That demonstration has to survive the platform's own systems being untrustworthy, because the party asking has no way to distinguish a well-run archive from a well-presented one.

Evidence is a cryptography problem with a well-understood solution space, most of which was worked out for adjacent purposes — certificate transparency, software supply chain attestation, timestamping — and almost none of which has been assembled into something a platform team can adopt in an afternoon.

Why this lands on the platform rather than anywhere else

The tempting response is that this belongs to the counterparty. The insurer, the tax authority, the lender — they have compliance departments, and they have been keeping records since before the platform existed.

Sometimes that is true. Often it is not, or it is only partly true, and the part that is not true is the part where the platform is the only party holding a complete record of what it did on the user's behalf. Where an obligation sits depends on who is the record-keeper for the transaction, and that varies by arrangement in ways that deserve a proper answer from someone qualified to give one rather than an assumption from an engineering lead under deadline.

What we can say without ambiguity is that the ambiguity itself is the reason this needs designing rather than assuming. A platform that has never established which artefacts it is the record-keeper for has not established that the answer is none.

What a good answer looks like

We think the shape of a correct solution has four properties, and we will spend other articles on each of them.

The document must be held so that changes to it are prevented or detectable, by a mechanism stronger than an access policy. The history must be verifiable by someone with no access to the system that produced it. Destruction must produce evidence rather than a status code. And the whole arrangement must survive the disappearance of any single party, including the party providing it.

That last property is the one that most distinguishes an evidence layer from a storage vendor with good marketing, and it is the one we have built most deliberately toward.

The transaction takes thirty seconds. The obligation attached to it does not, and it has been landing on platforms that were never designed to carry it. That gap is what Lethra exists to close.