What we believe

Privacy as architecture, not policy

Most privacy is a promise. It lives in a policy, on a settings page, in a paragraph you scroll past — a statement of intent only ever as strong as the company making it, on its best day, with its current management, until the incentives change. We wanted privacy that does not depend on any of that, so we put it somewhere a promise cannot reach: the architecture.

The limits of a promise

A policy is a statement about what a company intends to do. That is worth something, but not much, because intentions are the first thing to change under pressure. New owners arrive. A quarter goes badly and the growth has to come from somewhere. The privacy notice gets a quiet edit, and the toggle that was off by default is on by default now. Nothing technically broke — the promise was always the kind of thing that could be revised.

This is the structural weakness of policy-based privacy: the same hand that made the promise can unmake it, usually without you noticing, always without your consent in any meaningful sense. A settings page that says the right things is not protection. It is a description of the current mood, and moods are exactly what you should not have to trust with the things you cannot afford to lose.

Where configuration lives

So we moved the decision out of policy and into structure. Every product reads its runtime configuration — integrations, model providers, retention, how data flows — from a per-customer encrypted store. There is no global switch an operator flips to change how everyone's data is handled, because the settings that govern your data live with your data, encrypted, under your tenancy, not in a central console someone could reach across all customers at once.

That single decision is what turns privacy from a claim into a property. It is not that we promise not to funnel everyone's data somewhere; it is that there is no place in the architecture where that funnel could be built without redesigning the substrate every product stands on. A new feature that cannot be expressed as per-customer configuration does not get a policy exception — it gets sent back to design before any code is written.

Why structure beats intention

The point of putting privacy in the architecture is that architecture does not have moods. It does not get quietly revised the quarter growth is short. It holds the same way on the company's worst day as its best, because it is not relying on anyone choosing well in the moment — the choice was made once, structurally, and is now just how the software works. Good intentions are welcome, but they are not the thing standing between your data and misuse. The structure is.

This is the mechanism underneath everything else we say about not selling user data. Docusift, Memoria and Lekha do not each make a separate privacy promise and hope to keep it three times. They inherit one architectural decision about where configuration lives, and that decision enforces the promise whether or not anyone is feeling principled that day. Privacy you can only be asked to trust is weaker than privacy you can point at in the design.

Questions

People also ask

    What does privacy enforced by architecture actually mean?

    It means the settings that govern your data — integrations, retention, data flows — live in a per-customer encrypted store, not in a global console an operator can change for everyone. There is no place in the design where your data could be funnelled elsewhere, so the promise does not depend on anyone's good intentions.