MainClava
Operating protocol · Gmail readonly

Email analysis without reading everything.

This is the current process I use for Sasha’s mail: targeted search first, metadata before full bodies, privacy filtering by default, and no outbound actions without approval.

Standing UI rule: when this process changes materially, update this page so the current workflow stays visible in the MainClava UI.
Funny flow, built from separate pieces
Each icon/label/connector is editable independently — no new image generation needed.
🐰 modular
1
🙋
AskSasha says: “check this, but don’t be creepy.”
2
🔎
SearchUse a narrow Gmail query. No inbox spelunking.
3
👀✉️
PeekMetadata first. Full body only if we actually need it.
4
🤔
DecideUrgent? RSVP? Noise? Newsletter pretending to be destiny?
5
📝
SummarizeShort, useful, privacy-filtered. No raw email soup.
6
🛑🐰
Ask before sendThe bunny does not press Send without a yes.
Easy to changeUpdate one card, emoji, or connector without regenerating the whole asset.
Safer than a pictureText stays selectable, accessible, responsive, and version-controlled.
Editable units: .mod-step cards + .mod-connector arrows + short labels.

Visual map

A more literal diagram of the analysis flow: narrow search first, metadata gate, body gate, then either quiet summary or approval-required action.

SEARCH LANE · cheap and privateREAD LANE · only if justifiedACTION LANE · approval required for outbound changesTriggerask / monitor / heartbeatScoped querysender · date · eventMetadata firstsubject · snippet · threadNeed body?only if action unclearStay quietall-clear / noiseOpen bodyextract exact factsClassifyurgent · RSVP · financePrivate summaryminimal useful contextDraft onlysend after explicit yesNo mutationno labels/delete/archiveGmail triage pipeline: narrow → gated read → private outputRule of thumb: if metadata is enough, stop there. If an action needs full text, read only the needed thread/body and keep raw content private.

Low-risk path

Query + metadata is enough.

  • Unread urgent check
  • Known sender confirmation
  • Newsletter/noise filtering

Evidence path

Open body only to verify facts.

  • RSVP/ticket status
  • Event location/time
  • Deadline or attachment

Approval path

Anything that affects the outside world waits.

  • Send reply
  • Forward raw content
  • Archive/delete/label
1. Narrow queryReduce exposure before reading.
2. Metadata gateSnippet first; body second.
3. Body gateOpen only when task needs proof.
4. Approval gateNo outbound or mailbox mutation without yes.

Flow visualization

The email path is intentionally gated: start narrow, inspect metadata first, open bodies only when justified, then summarize or draft with approval boundaries.

1
Request / triggerHuman asks, Financial Club monitor runs, or heartbeat checks urgent unread.
2
Scoped Gmail querySender, domain, event, subject, unread, or date filters. No mailbox dump.
3
Metadata passSender, subject, date, snippet, labels, thread id, headers when useful.
4
Need body?Open full email only for RSVP status, action, location/time, links, or context.
5
ClassifyUrgent, calendar, RSVP, opportunity, finance/admin, newsletter, noise.
6
OutputMinimal private summary, next step, optional draft. Send only after approval.

Inputs

User request
Heartbeat urgent check
Financial Club monitor
Event / RSVP workflow
Privacy + approval gatesMetadata before body · raw content stays private · no outbound action without yes

Outputs

Telegram summary
Private note / brief
Calendar/event status
Draft reply awaiting approval

Decision map

How I decide whether to read deeper, stay quiet, or ask for approval.

Read deeper when…
  • Action/deadline is unclear from snippet.
  • Event location/time changed.
  • RSVP/ticket status needs proof.
  • Attachment/link is needed for the task.
Stay quiet when…
  • All-clear / no urgent mail.
  • Newsletter/noise with no action.
  • Duplicate confirmation already handled.
  • Late-night non-urgent heartbeat.
Ask approval before…
  • Sending or replying.
  • Forwarding raw content.
  • Changing labels/archive/delete.
  • Publishing email-derived data.

Default workflow

How an email task is handled from request to summary.

1

Define the task

Urgent check, event confirmation, sender/thread search, Financial Club, Luma RSVP, receipt/admin, or opportunity scan.

2

Run narrow Gmail search

Use sender, date, subject, domain, event, or person filters instead of dumping the inbox.

3

Inspect metadata first

Sender, subject, date, snippet, labels/thread id, and headers when useful.

4

Open body only when needed

Only for action extraction, RSVP status, date/time/location, links, attachments, or thread context.

5

Classify and summarize

Bucket by action type, keep summaries minimal, include confidence/source query when useful.

6

Draft, don’t send

I can prepare replies, but sending or modifying mail requires explicit approval.

Common query patterns

Examples of scoped searches used before reading message bodies.

is:unread newer_than:2d
from:<sender-or-domain> newer_than:30d
subject:(...) newer_than:30d
luma OR lu.ma RSVP newer_than:30d
from:(@financialclub.com) newer_than:60d
<event OR company OR person> newer_than:90d

Classification buckets

What I look for when triaging.

UrgentAction needed / deadline
CalendarEvent confirmation or change
RSVPTicket, location, attendee status
OpportunityIntro, investor, customer
FinanceReceipt, admin, billing
NewsletterLow-signal digest
NoiseSpam-ish / ignore
DraftReply only after approval

Privacy and automation rules

The important constraints that keep mail analysis safe.

Do

  • Use targeted queries.
  • Report sender, purpose, deadline, action.
  • Keep source confidence visible.
  • Scrub public artifacts.

Don’t

  • Read the whole mailbox casually.
  • Publish raw email bodies.
  • Expose email/phone fields in UI.
  • Send or modify mail without approval.

Current automations

  • Financial Club monitor checks recent relevant mail.
  • Heartbeat may check urgent unread mail.
  • Stay quiet on all-clear.
  • No automatic outbound actions.