Local Email Summarization Without Uploading Content

Direct answer

Email summarization is a content task with a clear source boundary: the user must choose which message or thread is in scope, and the summary must remain a derived draft rather than replacing the original. `PRIVACY-01` says local inference removes the need to send user content to a remote inference server for that step but does not prove other requests are absent. `BENCHMARK-01` requires raw records before publishing task-quality results. These facts support a controlled test method, not a claim that any Cove application reads an inbox or summarizes email today. Start with a selected-message contract. Define whether the input is a single body, a thread, a user-selected text excerpt, or a file such as an exported message. Record sender, date, subject, reply order, quoted history, signature, and attachment references separately if they are part of the input. Do not scrape an inbox in the background or assume account access is authorized because an email app is installed. For a file import, use a user-directed picker and treat the URI permission and parser as explicit boundaries. The original message should remain immutable. Quoted replies are a central test condition. A thread may contain the same text repeated below a new reply, an old request that has been cancelled, a forwarded warning, or an attachment whose content is not parsed. Define which messages are included and how order is represented. The summary should not attribute a quoted statement to the latest sender. Keep sender/time labels where needed to verify attribution, and mark attachment content as unprocessed unless a separate, tested path extracted it. A fluent paragraph is not enough if it merges speakers or omits that a request changed later in the thread. Create a versioned synthetic fixture set with expected facts and forbidden additions. Include a simple one-message note, a reply chain, quoted duplicate text, conflicting dates, a negation, a changed decision, missing attachment text, a long thread truncated at a boundary, and an empty or malformed message. Have a reviewer prepare the reference summary properties before running the model. Validate source parsing first, then test summary fact preservation and attribution. Do not publish a general “accurate email summary” score from a handful of messages or change the source and expected summary after seeing output. Privacy is part of the selected-message flow. Email commonly contains names, contact details, financial or workplace information, and quoted content from people other than the user. Keep fixtures synthetic or explicitly authorized; do not paste real private messages into logs, analytics, crash reports, or source control. Before any optional export, show the selected content and generated summary and identify the destination. Local summary generation alone does not prove the app has no network clients or backup behavior. Test network paths and storage separately, including temporary parse files and derived indexes if they exist. Review and persistence need separate acceptance states: parsed source, summary draft, user-edited draft, accepted summary, rejected result, and export. Editing the summary must not overwrite the email source. If parsing or generation stops partway through a thread, label the summary partial, show which messages were processed, and let the user retry. The model should not invent missing sender identities, attachments, or decisions. If a generated action item is extracted, require review before task creation or forwarding; summarization is not permission to act on the message. Test the exact build with a fixed input route, parser version, model/runtime identity where available, network state, and retention settings. Record failures, corrections, and partial outputs, not only successful summaries. The result can say which synthetic message patterns the tested workflow handled; it cannot imply universal quality, automatic inbox support, legal compliance, or zero data transmission. Keep the user in control from message selection through review, save, export, and deletion.

A user summarizes one selected email thread before a meeting

The thread contains a changed date, an earlier quoted request, and an attachment that is not available to the parser. The user wants a concise draft but must see which source messages it reflects.

Decision

Use only the explicitly selected thread, keep quoted messages and attachment availability labeled, and require review before saving or acting on extracted tasks.

Expected outcome

The summary preserves the latest decision and identifies unprocessed material without replacing the source or inventing attachment contents.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Input source contract
• Required-fact fixtures
• Network audit

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Define message selection and parsing scope. Specify single body, thread, excerpt, or imported message file. Record which headers, replies, quotes, signatures, and attachment references enter the task.
2. Build synthetic thread fixtures. Prepare a reply chain with repeated quotes, changed dates, negation, changed decisions, missing attachment text, boundary truncation, and malformed input.
3. Validate parser output before generation. Check message order, sender and time attribution where available, duplicate quote handling, and an explicit unprocessed-attachment state; preserve the original source unchanged for later comparison.
4. Evaluate summary properties. Compare the draft with prewritten required facts and forbidden additions. Check that later changes supersede old requests and that attribution remains correct.
5. Test review, privacy, and recovery. Exercise partial thread processing, cancellation, edit, reject, save, export, and delete. Inspect logs, network paths, and temporary storage with synthetic canaries.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The workflow processes only the explicitly selected message scope and preserves source order and attribution in its test record.
• Required facts, changed decisions, missing attachments, and partial processing remain visible; no missing identity or content is invented.
• User review precedes persistence or action, and privacy tests keep real message content out of default logs and analytics.

Decision table

Failure patterns to prevent

• Logging full messages
• Claiming universal summary quality

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove benchmark method
• Android Storage Access Framework documents and files
• RFC 5322 Internet Message Format
• Android security and privacy overview

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions