Email data is not body or nothing
An email API can return sender and recipient details, subject lines, dates, labels, read state, a provider-generated snippet, complete email parts, or raw content. Calling everything outside the complete email “metadata” is technically convenient but not useful enough for a person deciding whether the access is acceptable.
DeclutrMail stores the sender, subject line, Gmail preview snippet, dates, labels, read state, size, and limited unsubscribe information. It does not fetch or store full email contents, HTML, attachments, embedded images, or raw email source. The snippet deserves explicit mention because a short preview can still contain sensitive language.
The honest statement is narrower and stronger: DeclutrMail never fetches or stores full email contents, but it does store Gmail preview snippets. Precision earns more trust than a broader claim that later requires footnotes.
The data boundary should limit product capability
Without complete content, DeclutrMail should not offer full-email search, complete conversation summaries, attachment extraction, or guarantees about what an email means. Sender volume, read state, whether you write back, labels, and recency can support review by sender, but they cannot replace reading a contract, medical result, or conversation.
This is why the interface returns users to Gmail for message content. A deep link is not an unfinished reader; it is evidence that the companion boundary is being respected.
Constraints also protect future product decisions. A tempting feature that requires raw bodies should trigger a visible privacy decision rather than arriving through an unnoticed expansion of the fetch path.
Derived facts need their own threat model
A system can avoid bodies and still accumulate a revealing behavioral graph. Sender frequency, read rate, who you write back to, last-seen dates, Protected status, decisions, and activity history describe relationships and habits. Data minimization must therefore cover retention, access, logs, exports, and deletion for derived records as well as raw API fields.
DeclutrMail’s product needs those aggregates to rank senders and explain recommendations. Observability payloads, worker logs, and error reports are separately barred from carrying email addresses, subjects, snippets, bodies, or OAuth tokens. The principle is containment: a field belongs only in the narrow path that needs it.
Exports similarly separate datasets. A sender decision export should not quietly become a second message-content archive.
External processors are part of the boundary
It is not enough to say what is stored in the primary database. Users also deserve to know what reaches an error service, analytics system, email provider, or language model. The answer may differ by feature.
DeclutrMail can send Anthropic sender totals and read rates without subject lines or snippets to explain a suggestion. Daily Brief works differently: it can send the sender, subject line, and Gmail preview snippet. Full email contents and attachments are never included, and DeclutrMail uses a standard summary when Anthropic is unavailable.
Those two paths should never be compressed into “AI never sees email data” or “AI reads your inbox.” Both slogans are false. Field-level disclosure is the useful middle.
Turn privacy copy into executable proof
The strongest implementation does not rely on developer memory. Database columns define the stored fields. Gmail clients request only the required format. AI inputs omit body fields. Tests fail when a forbidden field appears. Logging helpers remove known sensitive information. Data exports list exact columns.
Copy should be generated from or tested against the same field list wherever possible. Otherwise the homepage, privacy policy, onboarding, and settings will slowly describe different products.
This approach cannot prove the absence of every bug. It makes privacy drift reviewable in code and gives future contributors a clear point where a boundary change must be debated.
Less data can produce a more legible product
A limited data model forces DeclutrMail to be specific about its job: reveal recurring senders, show their volume, present actions for existing email, record results, and return full reading to Gmail. It discourages features built merely because more content could be extracted.
Privacy and product focus reinforce each other here. The missing body is not only something the security page promises. It is visible in the architecture of the experience.