The deposit as a unit

Every system has one abstraction that, once chosen, decides most of the others. For Lethra that abstraction is the deposit.

A deposit is one sealed envelope. A single piece of compliance-relevant content — a cancellation letter, a tax filing, a dispatch confirmation, a prescription — that a partner encrypts on their side and submits together with a retention regime. We hold the ciphertext, the partner keeps the key, and we return an identifier and a signed receipt.

That is the whole definition. What follows from it is most of the product, and the reasoning is worth setting out because the alternative choices are tempting and each one breaks something.

One thing to be remembered, one deposit

The unit is a single artefact, not a transaction, not a case file, not a customer.

This sounds like a detail and is not. Every operation the system offers acts on a deposit. Events bind to a deposit. Retrieval returns a deposit and its event log. Forgetting acts on a deposit and destroys exactly that deposit. Pricing is per deposit. There is no operation anywhere in the API whose scope is larger or smaller.

The alignment is what makes the system reason about correctly. When a lifecycle question arises — is this still in retention, has this been forgotten, what evidence exists for this — the question has exactly one subject and exactly one answer.

What goes wrong at coarser granularity

The obvious alternative is to make the unit the case: all the documents belonging to one cancellation, one claim, one filing, held together as a bundle.

It is an appealing model because it matches how a human thinks about the work, and it fails on the lifecycle.

A single insurance claim can produce a dozen artefacts across weeks. They do not share a retention clock: the initial submission, the supporting evidence, the insurer's correspondence and the final settlement may attach to different obligations with different starting points. Bundling them leaves two options, both bad. Hold everything for the longest applicable window, which over-retains material that was meant to be released and creates its own exposure. Or unpick the bundle later, which means the bundle was never really the unit.

Erasure makes it worse. If a data subject's request touches one artefact inside a bundle of ten, a bundle-level design has no clean answer. It can destroy the bundle, taking nine documents with it that were under obligation to be kept. It can refuse. Or it can develop a partial-destruction mechanism, at which point it has invented deposits with extra steps.

What goes wrong at finer granularity

The other direction is worse in a different way. Making the unit a field, a page, or a chunk produces a system where nothing corresponds to a thing anybody has an obligation about. Nobody is required to retain page three. Obligations attach to documents, so the unit is a document.

One key per deposit

Because the deposit is the unit of forgetting, it has to be the unit of encryption.

Each deposit is sealed under its own data encryption key, generated at storage time, held in a hardware-backed key store, and shared with nothing. Forgetting the deposit means destroying that key, after which every copy of the ciphertext — in every replica, snapshot and backup — is noise.

The granularity is the entire point. A key per customer means one subject's erasure request and another's retention obligation contend for the same key, and there is no good resolution. A key per bundle reproduces the bundle problem in cryptography, where it is harder to fix. A key per deposit means the erasure question always has a clean answer, because the thing being erased and the thing being destroyed are the same thing.

It also means a great many keys, which is why the key store's design and its cost model mattered enough to shape the signing architecture.

The metadata boundary

A deposit carries metadata the partner supplies: which regime applies, retention parameters, content type, byte count, and whatever identifiers the partner wants to search on later.

That boundary is deliberate and it runs in one direction. We hold what we are given plus a hash of the ciphertext. We do not derive metadata from content, because we cannot read content. We do not enrich, classify, or index anything inside the envelope.

The practical consequence is that a partner decides what we know. A partner who sends an opaque identifier and nothing else gets a system that knows nothing about their business. A partner who sends structured metadata gets richer filtering, and has made a considered decision about what leaves their systems. Neither is wrong, and the choice belongs to them rather than to a default we picked.

Events bind to deposits

Dispatch evidence — a fax confirmation, postal tracking, an email engagement signal — is not a separate object with its own lifecycle. Each event binds to exactly one deposit and shares its fate.

This falls straight out of the unit choice and is worth making explicit, because it is where a lot of the practical value sits. The question a platform eventually has to answer is rarely just did you keep the document. It is what happened to it — when it was sent, by what channel, whether it arrived, what came back. Events are that record, they are signed as they occur, and they travel with the deposit into any retrieval.

When the deposit is forgotten, its events go with it. There is no orphaned evidence trail describing a document that no longer exists, which would be an odd thing to retain and an awkward thing to explain.

What survives forgetting

One thing does outlive the deposit: the content hash.

After a deposit is forgotten, our records retain its identifier, its regime, the relevant dates, and the hash of the ciphertext that was held. Nothing about the content is reconstructable from a hash — that is what a hash is for.

What it makes possible is answering a later question without holding what we were obliged to destroy. If someone asks whether a deposit with a particular fingerprint ever existed and what happened to it, the certificate of forgetting plus the retained hash answers precisely, and answers nothing else. Discarding the hash along with the content would leave us unable to substantiate our own certificate, which would make the certificate worth less than the paper equivalent.

Why pricing follows the unit

Pricing is per deposit, and that is a consequence of the model rather than a commercial decision made separately.

A unit that is billed differently from how it is stored, retained and destroyed creates a permanent translation layer between what the system does and what the invoice says. Every conversation about cost becomes a conversation about the translation. Aligning them means a partner who understands the data model understands the bill, and a partner who wants to reduce the bill knows exactly which lever to pull — send fewer deposits, or release them when the obligation ends.

That second lever is one we deliberately left in the partner's hands, even though it reduces our revenue when they use it. A retention system whose economics reward over-retention is a system whose incentives point away from its purpose.