Data retention & deletion

Last updated: 2026-08-07 · Version 0.1 · Status: Draft for legal review — not yet in force

What is kept, for how long, and what deleting actually deletes. Written from the scheduled job that does the deleting, not from an intention. Where the software keeps something after you have asked it not to, that is stated here rather than left for you to discover.

1. The automatic purge

A scheduled job runs daily and permanently deletes:

Those first two rows are deliberately different lengths, and the difference matters if a filename is itself sensitive. The document is destroyed after seven days. The one-line diagnostic record that a file was delivered — who to, what it was called, how large it was — is kept for ninety, because a run of refused or unexpected deliveries is how we would notice an assistant sending something it should not. So a document called redundancies-final.pdf is gone in a week, but the fact that a file of that name went to that person is visible to us for three months.

This is a hard delete, not an archive or a flag. Once the job has run, the row is gone and we cannot produce it again — including for you.

2. What the purge does not touch

This is the section a template would omit. It is the one worth reading.

• A copy of what the assistant has worked out is now held in our database, so it can be shown on your settings page and included when you export. It is refreshed from the assistant's own notes and is deleted with your account. The original still lives on the assistant, as below.
• The chat assistant's own memory. Each customer's chat assistant runs on its own machine and forms its own long-term memory from the conversations it has. That memory is not covered by the purge above, it is not removed when a member of staff deletes a conversation, and there is no interface through which our application can edit it. Deleting a conversation in the app removes it from that person's list; it does not make the assistant forget what it learned. Removing something from that memory is a manual operation performed on the machine.
• That memory is shared between colleagues at the same business. A fact one member of staff tells the assistant can be retrieved by another. It is one assistant for the business, not one per person.
• The assistant's own copy of a file it made for you. When your assistant produces a document, it writes the file on its own machine and then sends a copy here for you to download. Our copy is deleted after seven days, as above. The original stays on that machine until it is removed there, which is a manual operation on the machine and not something this application does.
• Your accounting records. Where your assistant keeps books for you, the journal — every transaction, with its payee, amount and accounts — is a plain text file on your own machine, together with the notes it files as evidence for each entry. It is the only copy of those records in existence: this application never receives it, never stores it, and cannot show it to you, so nothing on this page's purge table applies to it and nothing we delete here touches it. What your assistant reads from a receipt you send it is written into that file as text; the photograph itself never reaches the machine and is not stored anywhere.
• We hold a nightly copy of that machine, and that includes your books. Each customer's machine is archived every night so it can be rebuilt after a failure. Since the books live on that machine, the archive contains them. Those archives are held on operator-controlled equipment, not in the application database and not with any third party. While an account is open, the backup job normally keeps fourteen days of successful archives; it deliberately keeps the last good copy longer when new backups fail. Because it is what stands between a disk failure and the loss of your accounts, an archive is not removed on request while the account is open. When the account closes, the offboarding procedure removes every archive for that business after the final export decision; see section 4.
• An email account you have connected — the address and the encrypted credential, whether that is a Gmail app password or an AgentMail API key — is kept until you disconnect it or your account closes. No job removes it, because a credential that expired itself would stop your assistant answering mail with no warning. Disconnecting deletes it from our database at once; it does not cancel the credential where it was issued. Only you can do that — on Google's app passwords page, or at console.agentmail.to.
• The record of email your assistant sent — recipient, subject, length, when, and whether it went — is kept for the life of the account and is not covered by any purge. It is deliberately not on a timer: it is the only way to answer "what did my assistant send, as me?", and a record that ages out is no answer at all six months later. The body of the message is not stored by us; the account it went out of — Gmail, or AgentMail — keeps its own copy in its Sent folder.
• Email your assistant reads is not stored anywhere by us. The messages it fetches to answer a question exist in that conversation and nowhere else in our systems — no copy, no index, no attachments — so there is nothing here to purge. If the assistant files something it read as a fact about your business, that line is marked as filed by the assistant and lives with your saved business information, below.
• A code repository you have connected — the repository name, your GitLab address if you self-host, and the encrypted access token — is kept until you disconnect it or your account closes. Disconnecting deletes it from our database at once; it does not revoke the token at GitHub or GitLab, which only you can do, in your own account's token settings.
• A calendar you have connected — the permission Google gave us, encrypted, the address of the Google account that granted it, and the name and time zone of the calendar you nominated — is kept until you disconnect it or your account closes. Disconnecting is different here, and better: we ask Google to cancel the permission before we delete our copy, so it stops working at both ends. If Google does not confirm the cancellation we say so on the page rather than claiming it worked, and you can remove it yourself at any time in your Google account's permissions.
• What your assistant reads from your diary is not stored anywhere by us — the entries it fetches to answer a question exist in that conversation and nowhere else in our systems. What it books is not ours either: the appointment lives in your own calendar, where you can move or delete it. We keep no copy of your diary, and there is no purge here because there is nothing to purge.
• The record of changes your assistant proposed — the repository, branch, title, how many files, when, and the link to the pull or merge request — is kept for the life of the account and is not covered by any purge, for the same reason the email record is not. The changes themselves are not stored by us: what it proposed lives in the pull request in your own account, where you can read it, revert it or delete the branch. We never hold a copy of your code, and nothing your assistant read from the repository is stored anywhere in our systems.
• Usage records — how many messages and files were processed, and what they cost — are kept beyond the purge horizon. They are how an invoice is explained and cannot be reconstructed once discarded.
• Saved business information (the knowledge your assistant works from) is kept until you change or delete it. Earlier versions are retained as a short save history so a bad paste can be undone.
• Call audio, where a business has recording switched on, is held by the telephony provider under their retention rules, not ours. See the sub-processor list.
• Backups of this application's database. A deleted record may persist in the production database's point-in-time backups for up to seven days. This is a different thing from the machine archive above: the database holds your account, your saved business information and your usage records, and never holds your books.

3. Asking us to delete something

If you are a business using the service, you can clear your saved business information from your own settings page at any time. For anything else — a specific call record, a customer's data, or your whole account — write to info@moneliautomation.com.

If you telephoned a business and want your information removed, ask that business: they decide what is collected and we act on their instructions. The call recording and AI disclosure page explains this.

We will tell you plainly which parts we can delete and which we cannot, including the assistant memory described above.

4. When an account closes

Before anything is destroyed, we make and retain a complete final export for the business. The export includes the business records in this application, files the assistant generated, chat transcripts available from its dedicated machine, its learned memory, and its accounting files. If a complete export cannot be made, deletion stops. The only exception is when the customer explicitly declines the export with a separate confirmation.

The closure workflow then permanently deletes the tenant and its users, configuration, credentials, calls, contacts, chat records, generated files, integrations, scheduled work, email and repository activity records, usage records held by the application. The customer's dedicated assistant machine is destroyed, not selectively wiped, so its memory, accounting journal and files leave with its disk. Operator-held disaster-recovery archives and the box credential are removed separately.

We keep an operator deletion report with the time, operator, row counts and a separate result for the application, dedicated machine, operator archives and database backups. If a machine, archive directory or provider could not be checked, the report says not checked; it does not call the source empty or the deletion complete. Application database backups can retain deleted rows for seven days after the application deletion. Account deletion is not marked complete until that period has ended and an operator has verified the expiry.