Features

The whole picture

One pass in. Routes, watches, topics, and digests out.

Every message flows through the same real-time path — ingest, classify, then routes, watch rules, and topic matching all act on that single classification pass (no second scan, no extra egress). Three kinds of digest run on their own schedule on top. The sections below walk each stage in detail; this is the map.

Section 1

Intelligent Classification

Each incoming message is classified by a local LLM into one of your categories. The classifier sees the sender, subject, and body; you write the category descriptions and the system uses them as the classifier's instruction.

Default Categories

12 system categories ship out of the box:

Category	Description
to-respond	Emails that need a reply from you
action-required	Tasks, requests, deadlines
fyi	Informational. No action needed.
newsletters	Subscriptions and recurring content
meetings	Meeting invites, agenda, scheduling
meeting-request	Prose-only requests to schedule a meeting (no .ics)
grant-related	Grant applications, reviews, funding communications
self-event	Note-to-self about a personal event. Auto-creates calendar entry.
… plus invoices, comments, notifications, sponsor

Custom Categories

Add as many as you want. Each category is defined by a short slug and a description; the description is what the LLM uses to decide whether a message belongs. Write it well, the classifier follows.

/categories — system defaults + user-added categories with operator-editable descriptions

Classification Hints

Two types of fast-path rules bypass the LLM entirely:

• Mailing-list rules. Map a List-Id header to a category with a deterministic rule.
• Pattern rules. Match on sender domain, subject substring, or arbitrary regex.

/rules — mailing-list, sender, and regex rules with 30-day hit counts

Caching

An email the system has effectively seen before doesn’t pay for a second AI look — it reuses the earlier decision, so repeat and near-duplicate mail is fast and cheap. On HIPAA-flagged accounts the cache stores no free text: the same reuse still applies, but the classifier’s free-text reason is stripped at write time and the cache key is hashed — so no PHI sits in the side-cache. (For your IT reviewer: a two-level Redis cache keyed on a hash of sender + normalized subject + body; on HIPAA accounts the free-text reason field is dropped at store time.)

Section 2

Automated Routing & Actions

After classification, messages route through configurable action chains. Actions are independent — any number can fire on a single message.

Available Actions

Action	What It Does
move	Move to a different folder. Per-category folder mapping.
label	Apply the category as a label / Gmail label.
notify	Metadata-only alert (never the email body) fanned out to the outbound webhook system — Slack, PagerDuty, Opsgenie, Teams, Discord, or a custom signed endpoint.
draft_reply	Generate a contextual draft reply, save to Drafts folder.
suggest_meeting_times	Calendar-aware draft listing free slots. Auto-fires on meeting-request.
accept_invite / decline / tentative	Calendar invite handling with iMIP-threaded replies.
escalate	Forward to a configurable recipient. SMS-gateway pattern for phone delivery.
mute	Suppress all classification + action firing.

/accounts/<id>/routes — per-category action table. Different accounts can route the same category differently.

Watch Rules

Independent of category. Match a sender, subject, body pattern → fire escalate / webhook / mute. Useful for "alert me immediately when X arrives" patterns that don't fit a category.

Alerting & Integrations

The notify action and any watch rule fan an event out through the outbound event webhook system. Five receiver types ship with tuned default payloads; a sixth “custom” option delivers Email Triage’s own signed envelope to your own relay or SIEM.

Target	Delivered as
Slack	Incoming-webhook message
PagerDuty	Events API v2 trigger
Opsgenie	Alert API alert (GenieKey auth)
Microsoft Teams	Incoming-webhook MessageCard
Discord	Webhook message
custom	{event, timestamp, data} envelope — verbatim, HMAC-signed

Each payload is a template you can edit per target ({{data.category}}, {{data.subject}}, {{data.flow_id}}, …), rendered through one shared code path so the wire shape can’t drift between targets.

Section 3

Digests & Periodic Summaries

Two digest features that solve the two recurring inbox problems every professional has: "I subscribe to too many newsletters to read" and "I've handed my inbox to an AI and now have no idea what it's doing."

Newsletter Digest — for the high-subscription-volume professional

Target user: the knowledge-work professional whose job requires staying current on a high-volume subscription feed. The research clinician subscribed to journal alerts + NIH funding announcements + IRB digests + society newsletters + sponsor communications. The financial analyst tracking 12 industry briefings. The consultant signed up for every category-defining substack in their vertical.

For someone like this, newsletter overload is a 60-to-90-minute-per-day problem. Each newsletter has 2–4 articles worth a 30-second scan; only 5–10% of those articles deserve a real read. The current state-of-the-art is Cmd+A → Archive — losing the signal entirely.

The newsletter digest replaces that with one inbox entry at a scheduled time (typically 7 AM local, operator-configurable):

1. The digest action pulls every newsletter-category message from the lookback window (default 24 hours)
2. The local LLM reads each newsletter body and extracts per-article structure: headline, 1–2 sentence summary, "read more" link
3. Articles are grouped by source so each newsletter's content clusters together
4. An HTML digest renders with section headings per newsletter, article cards beneath, and "Read more" buttons linking back to the original article URLs
5. The digest delivers to the account's own inbox (or sends, per operator policy)

Configuration (per-account, on the Digests tab)

• Schedule — time of day in the account's timezone, days of week
• Categories included — defaults to newsletters but can bundle any category (e.g. team-internal, comments for GitHub-style notifications)
• Lookback window — 24 hours for daily; 168 hours for weekly Monday digests
• Render template — HTML email shape; custom templates supported via the API for brand consistency
• Recipient — defaults to the account's own inbox; can be overridden for a "send digest to my assistant" pattern

Each schedule slot has an independent enable/disable toggle and a "Run now" button for previewing without waiting 24 hours.

/accounts/<id>/edit on the Digests tab — Daily Activity, custom digests (Morning Newsletter, Weekly Wrap), per-slot Preview and Send-test-now buttons

What a rendered newsletter digest looks like

The HTML body of a generated newsletter digest as it arrives in your inbox — section headings per source, article cards with headlines, 1–2 sentence summaries, and "Read more" links back to the original article URLs. The visual "30 emails → 1 digest" outcome:

A daily newsletter digest — 13 articles across 5 sources (NIH funding, NEJM, AHA, STAT News, JAMA), each with a headline + summary + "Read more" link

Triage-Activity Digest — for the "I want to know what the AI is doing" user

The "set it and forget it" anti-pattern is real: an AI quietly classifies + drafts + moves mail for weeks, the operator's confidence drifts toward "I have no idea what it's doing," trust erodes, eventually the operator pulls the plug. The triage-activity digest is the antidote — every day, the operator gets a complete record of what email-triage did with their mail.

Daily summary delivered to the account's own mailbox at the scheduled time (typically end-of-day, 6 PM local — operator-configurable):

• Today's triage summary — counts per category ("47 newsletters, 12 to-respond, 8 meetings, 3 invoices"), counts per action ("12 drafts created, 47 moved, 8 labeled, 0 errors")
• Per-message detail — sender, subject, category, confidence, and the action chain that fired. Operator reads top-to-bottom in 2 minutes and knows exactly what got done.
• Drafts that need your attention — every saved draft linked back to the Drafts folder. Closes the "drafted reply forgotten in my Drafts folder" loop.
• Classification confidence flags — any message classified at <0.85 confidence surfaces here so the operator can correct via rules. Turns the digest into a tuning surface.
• Errors — anything that went wrong (auth failures, draft-creation errors, watch-rule webhook timeouts). Surfaces operational issues to the user, not just the admin.

Compliance posture, locked in code

• Locked to the account. Delivery is to the account's own email address — never to a notify_email or third party. "What email-triage did to MY mail goes back into MY mailbox."
• Owner-only initially. Delegates of the account don't get their own opt-in surface yet — only the account owner can enable the digest.
• Recipient verification, hard. If the account's email address changes and the configured to-address no longer matches, the digest refuses to send with an audit-log row.

Delivery mechanics

• Supervised scheduler. Background worker polls every account's schedule slots once per minute and fires when a slot's wall-clock matches. Quarantine + auto-retry on transient failures.
• Idempotent fire. Each schedule slot tracks the last-fired timestamp — no double-fire within the same 60-second window even across a container restart.
• HIPAA-aware. Newsletter-digest action runs against the LLM (local Ollama by default; cloud only with BAA ack). Triage-activity digest renders only category names + action verbs + counts — no PHI in the digest body itself.

Topic / Study Digest — for the clinical researcher tracking a study

Define a Topic — a study, project, or subject — with a few Subject keyword chips and the mailboxes it should watch. Email Triage collects every matching message across those mailboxes into one scheduled digest: Full, Differential (new since last), or both. Built for the PI following an IND across a sponsor inbox, an IRB inbox, and a coordinator inbox at once.

• Matching rides the classify pass — no new egress. Topics are checked as mail is already being triaged, not on a separate scan job. A keyword/IDF pre-filter (no embeddings) narrows to at most a handful of candidate Topics before a single precise check; no message body is ever sent externally.
• It stores no message content. The hit store keeps durable identity (message-ID + your own public matched terms) with an accurate first-seen date — never the subject or body. The real subject and sender are fetched at display time and immediately discarded, so PHI-bearing content is never persisted.
• You can’t even save a PHI-laden Topic. A fail-closed scrubber runs the HIPAA-18 identifier catalogue over a Topic’s Subjects and Details on save; any hit blocks it before it reaches the database (canonical public NCT trial IDs are allowed).
• Back-scan the past. Scan 30 / 60 / 90 days or the whole mailbox to surface matches that predate the Topic, and preview matches live while you edit it.
• HIPAA-class delivery. A Topic aggregating protected mailboxes delivers only into one of your own HIPAA-checked mailboxes (internal use, never an outside disclosure) and refuses to send if there is no safe recipient. At send time it re-checks your current access and drops any match from a mailbox you no longer manage — a stale Topic can’t email content you’re no longer entitled to see.
• Reversible confidence floor. Set, per Topic, how strong a match must be to appear. The floor applies at surface time, so lowering it instantly re-surfaces previously hidden hits.

Section 4

Smart Reply Drafting

The draft_reply action generates a contextual response using your local language model — a real AI-generated reply body. The draft lands in your Drafts folder. Nothing is ever sent automatically.

Three Signals Per Draft

A drafted reply in the email client's Drafts folder — threaded into the original conversation, ready for review

Distilled Writing-Style Profile

The system extracts measurable signals from your sent mail and shows you what it learned. Greeting patterns, signoff conventions, average length, common phrases — all visible and verifiable, not magic.

/profile/style-data — the distilled writing-style profile. Edits you make to drafts feed back into this index.

Multi-Alias Awareness

If your account sends from multiple addresses (work, personal, project-specific), the system maintains a separate writing-style profile per address. A draft to a message addressed to alias-a@ reflects how you write as alias-a.

Captured Feedback Loop

When you edit a draft before sending, the final version is captured as a "high-signal example." Future drafts learn the way you actually want it to write — not the way it guessed.

Section 5

Calendar-Aware Meeting Scheduling

The highest-leverage feature for anyone whose calendar is the bottleneck. When mail is classified as meeting-request, the system reads your calendar, picks slots, and drafts a calendar-aware reply.

/profile?tab=meeting — slot configuration, working-hours grid, OOO override

The Intercept

1. Reads your calendar over the next 14 days
2. Filters to your configured working hours (per-weekday, with lunch-break carve-outs)
3. Skips events marked "free" (birthdays, reminders don't blank your day)
4. Picks N suggestions spread across M distinct days
5. Drafts a reply listing slots in your local time zone with DST-correct labels
6. Saves to Drafts for one-click edit-and-send

A generated meeting-suggestion draft — N slots across M days with proper EST/EDT labels

Invite Acceptance

When a .ics-attached invite arrives, the accept_invite / decline_invite / tentative_invite actions respond on your calendar and draft an iMIP-formatted reply, properly threaded back to the organizer.

Calendar Surrogates (IMAP)

Pure-IMAP servers don't expose a calendar API. The system supports routing calendar operations for an IMAP account through a sibling Gmail / O365 account. Operator sets the surrogate via dropdown.

Section 6

Regulatory Deadline Clock

For clinical-research teams, a missed safety-reporting deadline is a finding. Email Triage can watch for the mail that starts one of those clocks — an FDA IND safety report, an EU CTR SUSAR, an IRB notification — and track the deadline against a working-day calendar. Detection is opt-in and off by default — you enable each rule, and a human confirms every clock before it arms. It is built to assist a human’s judgment, never replace it, and never quietly assume your legal liability.

A human confirms every legal clock

Nothing arms silently. Every deadline begins as a candidate a person must confirm. A clock only starts running when it is both marked as your responsibility to submit and has a computable deadline. “Day-0” is write-once and can never be edited in place — a correction is a new, appended event, not an overwrite (21 CFR Part 11). The app never silently starts or closes a legal clock.

The AI never does the math

Deadline arithmetic runs offline, in working days, skipping weekends and your institution’s configured holidays — the language model is never asked to compute a date. A working-day clock with no calendar configured refuses to arm rather than guess. And the “who is responsible” flag is read only from out-of-band operator configuration; it is never inferred from the content of an email.

Escalation, calendar, and an audit trail

• Escalation ladder. As a confirmed deadline approaches, it flags at-risk, escalates reminders, and marks overdue if missed — recomputed continuously so it self-heals across restarts, with a per-tick cap so a burst of reports can’t stampede the notifier.
• PHI-free calendar write. Each escalating deadline is written to your own calendar exactly once — the event summary is the clock label only, never patient or case detail.
• Tamper-evident clock audit chain. Every legally-meaningful transition (detected, awareness, determination, escalation, breach, submission, dismissal, correction) is recorded in the same HMAC-keyed audit chain — bounded, non-PHI detail only, never the trigger email’s content.
• Automatic detection is off by default. Optional scanning of inbound mail for safety-reporting language is flag-gated and ships disabled; even when enabled it only proposes a candidate for human confirmation.

The Deadlines view — an armed IRB continuing-review clock: Running, a working-day countdown, an explicit due date, and Acknowledge / Mark-submitted / Dismiss actions. Sponsor FDA/EU deadlines surface as informational only; an escalating clock arms solely after a human confirms it is theirs to submit.

Section 7

Email Provider Support

Provider	Push	Labels/Folders	Calendar API
Gmail	Cloud Pub/Sub (seconds)	Native labels	Google Calendar API
Office 365	Graph subscription (seconds)	Native folders	Microsoft Graph
IMAP	IDLE (<2 sec, multi-folder)	SPECIAL-USE detected	via surrogate Gmail/O365

Supports Dovecot, Cyrus, Exchange-via-IMAP, Fastmail, Proton Bridge. TLS by default (port 993). Multi-folder watch per account with per-folder route overrides.

/accounts — multi-account view with real-time push status and per-account health indicators

Per-Account Configuration

Each account has its own tabbed configuration page covering provider credentials, push/poll cadence, watched folders, calendar role assignment, delegates, and integration endpoints. Every knob is in the UI — no config-file editing required.

/accounts/<id>/edit — provider credentials, aliases, time zone, push/poll, watch folders

Section 8

Multi-User & Multi-Account

One install supports any number of users, each with their own accounts, categories, style profile, and meeting preferences. Three role tiers: Admin (install-wide config), User (owns own accounts), Delegate (granted view/triage/draft on another user's account).

Per-user isolation is enforced at the data layer. Delegate actions are audited with both actor and account-owner stamped. The HIPAA §164.312(b) audit gate distinguishes owner self-access from delegate access — the former is a §164.502(a) self-disclosure carve-out and isn't audited as PHI access; the latter writes an audit row every time.

/users — user management, role assignment, and delegate grants visible on the same surface

Section 9

Operations & Configuration

Every operational signal is exposed through the admin UI — classifier latency, cache hit ratio, embedding metrics, supervised-task state, push watcher health, ingestion rollups. JSON for machine consumption (Nagios, Datadog, Prometheus); HTML for the admin stats page.

/admin/stats — operational signals dashboard showing the system is healthy at a glance

Install-Wide Configuration

A single Settings area with six tabs — General, Integrations, AI Backends, TLS, Backup, and Security — with legacy admin URLs 303-redirecting to the matching tab. The Backup and AI Backends tabs are new in v0.2.0. Operator-controlled, audit-logged, no config-file editing.

/config — install-wide configuration tabs

AI Backend Configuration

The classifier model is chosen from a live model picker, not a free-text field: the AI Backends tab fetches what is actually installed on your Ollama endpoint and shows each model’s capabilities, size, quantization, context length, and whether it is currently resident in VRAM. Embedding-only models are flagged and can’t be selected for classification. A free-text “enter manually” escape hatch remains for non-enumerable backends.

An ordered backup_models list provides capability-aware failover: if the primary model hits a capability or resource error, the classifier falls over to the next model and writes a tamper-evident model_failover audit row. A per-backend circuit breaker distinguishes “the AI server is down” from “the AI gave a bad answer,” so a brief outage isn’t misread as a per-email failure.

Encrypted Backups & Restore

Automated, encrypted database backups on a manual / daily / weekly cadence, configured in the Backup tab. Off by default — the operator must set a key and directory and explicitly enable it. A supervised, lease-gated sweeper produces either a full .etbk bundle (database + config + TLS certs + MSAL cache) or a raw SQLCipher .db, inheriting the boot encryption context so no plaintext PHI is ever written to /tmp. Public-key mode requires a parseable X25519 PEM, validated fail-closed before the config is saved.

• Restore is deliberately CLI-only. The restore command sniffs the bundle’s magic bytes, unwraps an .etbk with --private-key, and --list verifies a bundle’s contents without extracting — a non-destructive check. Restore is never a one-click web action.
• Restore-key freshness reminder. The dashboard and the daily health email carry a “last restore-key export” line, so an operator can see at a glance whether their restore key is current — a nudge, not a false guarantee.

Container Image & Lazy Embedding Stack

The runtime container image is ~250 MB compressed, Debian-13-slim with Python 3.12, non-root user, signed with cosign and SLSA-3 provenance. CPU-only PyTorch wheels (the GPU is reserved for the Ollama chat-model host). Fast pulls, fast CI, fits under GitHub Releases' 2 GiB asset cap for air-gap tarballs.

The embedding backend (PyTorch CPU runtime, sentence-transformers, all-MiniLM-L6-v2 model — ~600 MB total) is not baked into the image. On first admin setup, the operator clicks [Install now] on the AI Backends config page; the installer fetches each manifest-listed file over HTTPS, verifies SHA-256 against a pinned manifest baked into the image, and pip installs into the persistent volume at /app/data/runtime-deps/.

Operators who choose Ollama for embedding (rather than the in-process CPU backend) skip the local install entirely; their embed calls go to the same Ollama host as the chat model.

Air-Gap Installation

For organizations on disconnected networks — classified environments, OT segments, regulated research enclaves — air-gap installs use scripts/download-embedding-bits.sh on a connected machine to produce a hash-pinned tarball + SHA-256 sidecar. Transfer the tarball to the air-gap host and sideload through the admin UI. Sideload runs the same hash verification as the auto-download path — operator-staged bytes are not trusted; a bit-corrupted tarball or a tampered air-gap drop trips the same refusal as a poisoned PyPI mirror.

Section 10

Reliability — never silently drop a message

For a research team, a dropped IRB amendment or safety-report email isn’t an inconvenience — it’s a finding. So the system is built so a hiccup — a provider timeout, a brief network blip, a restart caught mid-sync — can’t make an inbound message quietly vanish.

Two things carry that promise. Work that fails is parked and retried rather than thrown away, and the system tracks exactly how far it has read in each mailbox, so nothing between “last confirmed” and “now” gets skipped when it catches back up. A message it can’t handle yet waits in line; it is not lost. (For your IT reviewer — skip if that’s not you: a durable retry queue plus per-mailbox no-loss read cursors.)

Section 11

Security controls, in plain language

Four controls that matter whether or not you read code. Each card leads with what it means for you; the named standard or mechanism sits in the grey line beneath — for your IT or security reviewer, and safe to skip if that’s not you.

Section 12

A program with an owner, not a box that rots

Automation nobody tends quietly decays — a certificate lapses, a login needs re-authorizing, a compliance agreement expires, and no one notices until something breaks. These three capabilities keep a real owner in the loop and let the system grow more useful the longer it runs — an argument for tending it, not just installing it.

See something your team needs?

Email Triage is a reference implementation — proof of what a sovereign, audit-minded AI system looks like in a regulated setting. Craig LaForest builds systems like this as a fractional CTO. A 30-minute call to talk through your environment and where an approach like this fits.

Talk to Craig