> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getcore.me/llms.txt
> Use this file to discover all available pages before exploring further.

# What's Important in My Inbox

> A personal policy for what counts as important email — key vendors, customer signals, security alerts, money matters, and the people I always want to hear from. Loaded whenever email is touched, so triage, replies, summaries, and notifications all use the same definition of "important". Trigger with "what's important in my inbox", "set my email priorities", or "tell CORE what matters in email".

**What this is:** A reusable definition of what *I* consider important in email. This policy is applied wherever email shows up — inbound triage, agent reading my inbox during a task, chat summaries, daily briefs, alert tasks. It does not run on its own. Tasks (a watcher, a brief, an agent flow) read this policy and act on it.

**Tools touched (when this policy is applied):** Gmail.

***

### How to read this policy

Each section answers one question about *me*:

1. Who do I always want to hear from?
2. What signals from customers matter?
3. What security and money events should never be missed?
4. What categories do I care about beyond the above?

Anything matching these definitions is **important**. Everything else is background.

***

### 1. People and senders that matter to me

Stored in memory and refreshed when I tell CORE about a new key contact:

* Named individuals — investors, advisors, co-founders, key customers (by email address)
* Vendor and supplier domains — accountants, lawyers, compliance providers, payroll, infra
* Specific senders flagged by me as "always notify"

> When a new email matches any of these, treat it as important regardless of content.

If memory has nothing here, ask once:

> "Who are the people and companies I should always treat as important? (names, emails, or domains)"

Store answers immediately.

***

### 2. Customer signals that matter to me

The body — not the sender — tells me this. A customer is important when they are:

* Reporting a bug or breakage in my product
* Asking for support or stuck on something
* Giving feedback (positive or negative) about a feature
* Reaching out as a prospect — interested in buying, trying, or evaluating

> Identify the product by name (from memory). Generic newsletters that mention the product in passing are not customer signals.

***

### 3. Security and money events that matter to me

Always important regardless of who else is involved:

* Security alerts — sign-in from a new device, password change, suspicious activity (from accounts I own: Google, GitHub, banks, financial tools)
* Payment failures — declined card, failed payout, overdue invoice
* Account access changes — added user, permission change, billing role change
* Anything from my bank, primary financial platforms, or tax/compliance providers about deadlines or actions required

***

### 4. Categories I've defined for myself

Free-form. Stored in memory as `{category_name, matching_rule}`. Examples:

* "Press or media reaching out" → matches journalists, podcasters, conference organisers
* "Hiring funnel — top candidates" → matches replies in active hiring threads
* "Fundraising — investor replies" → matches threads with known investor domains

> These are the categories *I* care about that don't fit the buckets above. Add freely.

***

### How this policy is used

Other surfaces consume this policy:

* **Triage tasks** decide what to surface vs. skip
* **Notification tasks** decide what to push live
* **Daily / weekly brief tasks** decide what to lead with
* **Agent-in-the-loop work** uses this to know which threads need my attention vs. which it can handle quietly
* **Chat queries** like "what's important in my inbox?" answer against this policy

Each consumer is responsible for *how* to act — this policy only defines *what* matters.

***

### Edge cases

* **Ambiguous signals** → if a sender matches but the body is clearly automated/promotional, treat as not important. Promotional ≠ important even from a key vendor's marketing list.
* **One-off relevance** → if something matches only once and isn't likely to repeat, do not add it to the policy. Keep this lean.
* **Conflicting rules** → security and money events always win over category preferences.