Data Control

Your archive should not become
another account you can never leave.

AtArchive separates provider access from the archive so preserving history does not create another lock-in. Users need clear ways to disconnect provider access, export what matters, remove individual archives, and delete their AtArchive data according to documented behavior.

settings_backup_restore
What do you want to control?
link_off Disconnect provider access
download Export preserved records
delete Delete an archive / account data
fact_check Review what deletion covers
Retention and deletion timing depend on the records and copies covered by the action.

Control means more than one red Delete button

The right question is what happens to every kind of data connected to the archive.

link_off

Disconnect provider access

Stopping future provider access and deleting the archive are different actions. AtArchive keeps that distinction clear so disconnecting provider access does not silently mean deleting preserved history.

download

Export before you leave

Where export is supported, you can take useful records or outputs with you instead of choosing between permanent dependence and total loss.

delete_forever

Delete by meaningful scope

Deletion needs to account for the archive itself and the derived data built from it: attachments, files, calendar records, People/Organizations, indexes, generated intelligence, and other projections.

history

Understand retention windows

When backups, soft deletes, logs, provider retention, or operational safety windows affect deletion timing, AtArchive explains that timing instead of hiding it behind the word "permanent."

smart_toy

Generated intelligence counts too

A Calendar Insights Report, relationship report, summary, embedding, or other generated artifact is still part of the user's archive footprint. Deletion controls include or explicitly explain those derived records.

receipt_long

Make the action understandable

Before a destructive action, AtArchive explains what is being removed, what remains, whether the action can be reversed, and when completion is expected.

Deletion is clear across the archive

When you remove something, the explanation follows the records and copies that make up your archive.

Primary records

Email, attachments, files, calendar events, account metadata, and provider tokens.

Derived records

People, organizations, relationship projections, search indexes/embeddings, summaries, histories, and other intelligence outputs.

Operational copies

Queues, logs, backups, versioned blobs, soft-delete windows, exports, and any other copy that could make an absolute deletion claim misleading.

Clear promise

AtArchive explains what the action removes, what remains, and when the requested change is complete.

Data Control FAQ

Can I disconnect Google or Microsoft without deleting my AtArchive copy?expand_more
AtArchive treats provider access and preserved archive data as separate controls. The provider-specific disconnect flow shows what disconnecting changes and how the preserved archive is affected.
Is AtArchive promising instant physical deletion from every system?expand_more
Deletion timing can depend on storage, backups, queues, logs, and retention windows. AtArchive will describe the applicable timing and any remaining copies instead of making an absolute promise it cannot keep.
Why is this page careful about deletion language?expand_more
Security and deletion are product commitments, not slogans. Clear wording helps you understand what you control and what timing to expect.