Privacy, stated as fact.

Yours alone — one owner, no shared tenancy.

Laedis belongs to one person. There is no shared account model and no shared store, wherever it runs. You use it one of two ways: as a local install on a machine you control, or as an isolated instance we operate for you, reached over a private URL. Single ownership holds in both. Where it runs changes what "private" can honestly mean — and that is stated plainly below, not glossed.

How it works: your record is held in a file store under a single owner. There is no second-owner or organisation path anywhere in the code. This is true in either run mode.

Run it yourself and nothing leaves your machine. A hosted instance forfeits that.

Local, on a machine you control. Nothing leaves that machine except the calls to the model you connect. There is no Laedis server in the middle receiving your conversations. This is the only setup that guarantees complete privacy, and it is the one we recommend.

Local, on a machine you don't fully control. That guarantee is only as strong as the machine. On a computer someone else monitors — a managed work device — that environment limits your privacy independently of Laedis. "Local" does not mean private if the machine itself is not.

The same in every setup. Laedis sends no telemetry, runs no analytics, and makes no third-party calls beyond the model you connect. You connect your own model account, so what goes to the model goes only to the provider you chose, under your own terms. And you keep complete export and permanent deletion.

How it works: every part of Laedis except the model adapters makes no network calls at all — the test suite checks this. On a local install the only thing that ever leaves is your call to your own model. A hosted instance runs that same core on a machine we operate; what changes is who runs that machine, not that Laedis starts sending your data anywhere else.

Complete export, and permanent deletion — in both setups.

You can export everything Laedis holds at any time, in a readable form. You can delete everything, permanently, in one click. Deletion is real: the data is removed from disk and the removal is verified before it is reported as done. It is not a hidden flag. This is the same whether you run Laedis yourself or we host it for you.

How it works: the export reads every part of your store from disk, so it cannot quietly leave something out; the erase path re-reads disk to confirm the data is gone and refuses to report success it can't verify.

Held by you; never logged; sent only to your model.

If you connect a cloud model, its key is stored in your own local store, covered by the same export and deletion as the rest of your data. It is never written in plain text into the program, never logged, never put in an error message, and never sent anywhere except to the provider you chose, to make the call. Erasing everything removes it.

How it works: the key is never kept on a running connection; it is read from your own store only at the moment of a call, and the model adapters leave it out of their logs and error messages — checked by the test suite.

Honesty over reassurance.

We claim no certification or compliance badge we don't hold. We don't assert SOC 2, ISO, HIPAA, or a blanket "GDPR-compliant" label here. We describe the mechanisms above, which you can check. Where your data goes to a cloud model you connected, that provider's terms govern that processing — see how your data is handled for the exact, per-provider statement you're shown before you commit.

If you choose the hosted path, we become a processor of your data on the infrastructure we run. For a paying engagement that path needs more than this page describes — a sub-processor list, a data-location statement, and a data-processing agreement — set with counsel, not asserted here. We would rather name that gap than paper over it.

If a claim on this page can't be traced to a mechanism, or isn't scoped to the setup in which it's true, it shouldn't be here. If you find one that isn't, that's a defect — tell us.