Deactivate, delete, erase: what happens to your account when you leave

Why several steps

“Delete my account” sounds simple. In practice, three needs cross paths. You want your content gone for good. The administrator wants to be able to suspend access without destroying everything, for example while a doubt is cleared up. And billing must be able to answer a question about an expense later: how much, for which model, on which day.

So I split these needs into steps, each with a clear effect, and made them successive: you only delete an account that is already deactivated, and you only erase an account that is already deleted. Nobody ends up half gone, with a session still open on an emptied account.

The four states

Active: you sign in and LIA works for you.
Deactivated: access is cut off, your open sessions are closed and an email lets you know. Your data stays intact, and the administrator can reactivate the account.
Deleted: your personal content is purged. The account keeps your name and email as the billing contact.
Erased: the account row disappears in turn. The billing records remain, but they are no longer tied to any account.

The administrator of your instance moves an account from one state to the next, from their panel: you ask them for the deletion. An administrator account cannot be deleted this way.

What really disappears

Deletion targets everything that comes from you or talks about you: conversations, memories, journal and portrait, reminders, routines, documents and knowledge spaces, files on disk, health data, saved places, your phone number, the registers of what LIA did for you. Access to your connected services is revoked with the providers when possible. The internal state of your conversation and the caches are emptied, and your presence is removed from the shared world.

I didn't want a new feature to forget its own data one day. So a test checks that every table holding personal data is covered by the purge: a forgotten table fails the build.

The purge is final: reactivating a deleted account brings nothing back.

Background tasks stop too

Part of LIA's work happens without you: notifications, routines, reminders, journal review, refreshing access to your services. A deactivated account must not keep consuming model calls during the night. So before acting, these tasks check the account's state, and a deactivated or deleted account is simply skipped. At the moment of deactivation, this check is refreshed right away, so that no call slips through in the meantime.

Signing in with Google doesn't change an account's state either. A pending registration stays pending, a blocked account stays blocked, and a deleted account doesn't come back.

What remains, and why

Usage records remain: tokens, costs, calls to Google services. They make it possible to answer a billing dispute, and they don't contain your conversations. Audit or diagnostic logs may keep identity details according to their own retention period, and backups follow the policy the operator chose. If the instance sends model-call tracing to an external tool like Langfuse, what's stored there follows that tool's retention. These mechanisms help respect your rights; they aren't enough to certify that a deployment complies with the GDPR.

If you want to keep your account but lighten what it holds, lighter options exist: disconnect a service, clear your conversation, or download the archive of your data before you leave. The details are in the privacy FAQ.