Gmail to LifeOS: useful mail, preserved context

An inbox is a good place to receive useful information. It is a harder place to build a reference library you can use later.

A newsletter can contain a worthwhile prompt, an explanation of a tool, or a workflow worth revisiting. Saving the whole message is easy. Finding the useful part when it matters is the job this system tries to improve.

Choose before you collect

The workflow begins with a defined source scope and a small selection of candidates. It is not an instruction to copy every message into another system. The useful question is whether something in the email belongs in a reference library and why it will be worth finding again.

That decision happens before the writer runs. The helper accepts reviewed records; it does not independently decide which senders are appropriate, determine consent, or assess the sensitivity of a message. Those responsibilities remain in the review process.

The flow

Preserve the route back to the source

The prepared record can include the sender, received date, subject, message and thread identifiers, and a link back to Gmail. The writer carries those fields into the note alongside categories, a content hash, and a processing timestamp.

The body has sections for a summary, why the material is useful, key ideas, prompts, workflows, tools, possible actions, links, and attachments. A useful note should make it easy to tell what came from the source and what is an interpretation or possible next step.

A blank attachment section is not evidence that a file was read. The writer can record an attachment description or a saved-file path supplied by the reviewer. It does not download or inspect an attachment itself.

Make uncertain material visible

The helper chooses between a resource destination and a review destination using flags in the supplied record. A record marked sensitive, out of scope, or needing review goes to the review folder.

This is deliberate routing, not automatic sensitivity detection. If the flags are missing, the script cannot infer what the reviewer overlooked. Keeping a review destination helps only when the upstream selection and classification are done carefully.

It is also reasonable to skip a message. A reference system should earn its storage through future usefulness, not through a target number of notes created.

Recognize repeats without hiding the limits

The writer maintains an index for each destination. It checks the email’s message identifier and a hash of normalized subject and body text before creating a note. That helps prevent the same material from being repeatedly imported into the same destination.

The normalization removes URLs, lowercases text, and collapses whitespace. Two messages whose only important difference is a link can therefore look identical to the content check. Separate destination indexes also mean duplicate detection is not global across every folder.

Filenames are based on the received date and title. Different records can produce the same filename, so a new content hash does not by itself guarantee a new output path. Reviewing the proposed destination is important; a stronger collision policy is a useful next improvement.

A saved note is not permission to change the mailbox

The script writes Markdown and index files. It does not label, archive, or delete mail. That separation makes the work easier to reason about: first verify the reference note, then decide whether any mailbox action is appropriate and authorized.

An action item captured inside a note is similarly not a committed task. The reader still needs to decide whether to act, where the commitment belongs, and who owns it. LifeOS remains the reference layer rather than becoming an invisible second task queue.

What is verified here

This note is based on the workflow definition and the writer implementation reviewed on October 31, 2026. The implementation supports structured note creation, destination routing, a dry-run option, and destination-level duplicate indexes. No mailbox was searched or modified to prepare this page, and no private email content is shown.

The next improvements are safer filename collisions, clearer handling of interrupted writes, and explicit checks that required provenance fields are present. Those changes would strengthen the handoff without expanding the system into an indiscriminate email archive.