Email 4.0 Filtering System

Version: 0.1
Last Updated: 2026-05-19
Status: Planned

Overview

Email 4.0 is the next generation of RABS email filtering. It treats mail filtering as a system-wide quality layer that runs before individual users manage their own inboxes.

Most email clients expect each user to create their own rules. RABS takes a different approach: the system applies a shared, predictable set of filters across connected mailboxes first, then users can work with the cleaned and organised mail afterwards.

This gives every mailbox the same baseline protections and the same common system folders. For example, every active mailbox can have a consistent receipts destination for expense reporting, and junk can be measured across all accounts without guessing which folders users created themselves.

Why This Exists

The current system has useful automatic routing, especially around junk and receipts, but those destinations are too narrow for the future. As more filters are added, names like AutoJunk, AutoReceipts, AutoFacebook, and AutoSomethingElse become noisy and hard to understand.

Email 4.0 introduces a cleaner model:

• system-owned folders use a visible [RABS] prefix
• filters run in a predictable queue
• important filters are locked in place
• optional filters can be enabled only for relevant mailboxes
• optional filters can be reordered to express priority
• a signal pre-scan gives filters shared context
• every move is based on criteria, recommendation, and validation
• dashboards can explain what happened and why
• an independent Email Wizard can provide a second opinion after routing

The aim is not just automation. The aim is trustworthy automation.

System Folders

RABS-controlled folders are infrastructure. User folders are personal workspace.

System folders use this naming pattern:

[RABS] Junk
[RABS] Receipts
[RABS] Facebook
[RABS] Adobe
[RABS] YakPay

The [RABS] prefix makes the folder's purpose clear. These folders are created by the system when a validated move needs them.

If a user renames [RABS] Receipts to [My Receipts], RABS does not rename it back. That renamed folder becomes an ordinary user folder. The next time the system needs the canonical receipts folder, it creates [RABS] Receipts again.

If a user deletes a system folder, RABS recreates it when required. Normal filtering does not merge, delete, or repair user folders. A future drift detection tool may suggest cleanup when similar folders exist, but that is a separate maintenance workflow.

Destinations

A destination is the logical place a filter routes mail to. A folder is only the current physical container for that destination.

For example:

Destination ID: receipts
Canonical folder: [RABS] Receipts
Legacy folder: AutoReceipts

Reports should talk about the destination, not only the folder name. This means reporting still makes sense if a folder is deleted and recreated later.

Filter Queue

Every mailbox gets an effective filter queue. The queue is built from:

• mandatory filters that apply to every mailbox
• optional filters enabled for that mailbox
• optional filters that are default-enabled unless the mailbox opted out

Filters have position numbers. These numbers are stable sort keys, not a dense list. A mailbox queue might be:

1  Security
2  Junk
3  Receipts
4  POI / YP3000 Identity
20 Adobe
50 Canva

Another mailbox might be:

1  Security
2  Junk
3  Receipts
4  POI / YP3000 Identity
30 YakPay
40 Xero

The missing numbers do not matter. Gaps make it easy to insert new filters later without renumbering everything.

For optional filters, order is priority. The first approved move wins.

If the organisation wants all Facebook mail grouped before topic filters, Facebook goes higher in the optional filter list. If the organisation cares more about zebra-related content than the sender/provider, an Animals filter can go above Facebook.

This keeps the system understandable. Changing filter order changes which approved filter gets the first chance to route a message.

Locked Core Filters

The first filters are mandatory and locked.

Position	Filter	Purpose
1	Security	phishing, scams, fraud, impersonation, malicious account/payment bait
2	Junk	obvious low-value junk, spam, cold outreach, generic marketing garbage
3	Receipts	receipts, invoices, purchase orders, statements, bills, expense documents
4	POI / YP3000 Identity	known people/entities such as participants, staff, carers, and providers

These filters form the universal baseline. Everyone gets the same security screening and common system destinations.

Security Outcomes

Security is the most important filter. It has three outcomes:

Outcome	Result
Malicious	Move to [RABS] Junk
Suspicious but not proven	Leave in inbox, visually flag, and halt further filtering
Clear	Continue to the next filter

The middle state is important. A suspicious fake invoice should not continue into the receipts filter and get another chance to be filed away. It should stay visible until a user confirms it is junk or dismisses the concern.

Criteria, Recommendation, Validation

Each filter follows the same pattern:

criteria -> recommendation -> validation -> action

The criteria describe what the filter is looking for. The recommendation decides whether the message might match and where it could go. The validator treats that recommendation as candidate evidence, not final truth.

The validator can:

• approve a move to one of the filter's allowed destinations
• use a global escape destination, such as [RABS] Junk or [RABS] Receipts, when a later filter notices something important that earlier filters missed
• continue to the next filter
• stop and leave the message in the inbox
• halt for user review when the message is suspicious or uncertain enough to need a person

This is the core safety layer. The scripted and deterministic parts are useful because they gather evidence quickly, but the validator is allowed to correct them.

For receipts, the validator should not ask broad security questions again. Security already ran first. The receipt validator should ask a receipt-specific question:

Is this actually useful as a receipt, invoice, purchase order, bill,
statement, or expense document?

This avoids weak matches such as:

• a message that merely mentions money
• a discussion about an invoice
• a bank product update
• a pricing list
• an account notification
• a billing-related notice that is not itself a document

The distinction is simple:

Mentions money != receipt
Discusses an invoice != receipt
Is an invoice/receipt/purchase order/expense document = receipt

POI and YP3000 Identity

The fourth locked filter connects email routing to YP3000 identity discovery.

After a message clears security, junk, and receipts, RABS can compare header and message information against known identities. This can identify messages connected to participants, staff, carers, providers, or other people/entities already known to the system.

Possible destinations include:

[RABS] Participants
[RABS] Staff
[RABS] Carers
[RABS] Providers

This filter is mandatory because identity-aware routing is a core RABS capability, not a personal mailbox preference. It should still be explainable: the audit trail should show which identity matched and why the destination was selected.

Skippable Filters and Identifiers

Not every filter should need a full model pass for every message. A mailbox may have an Adobe filter enabled, but most emails will have nothing to do with Adobe.

Email 4.0 uses a signal pre-scan before filtering begins. The pre-scan is context only. It does not move mail.

The pre-scan can gather:

• sender and reply-to domains
• sender display names
• subject tokens
• header clues
• link domains
• attachment names
• body mentions
• extracted metadata
• semantic topics
• likely provider/source context
• likely person/entity context

For example, the pre-scan might find:

facebook: medium provider signal
zebra: strong topic signal

That context can help different filters in different ways. Security may use it to check whether a "Zebra credit card cancellation" message is fraud. Junk may use it to avoid discarding topic-relevant mail. Receipts may ignore it because the message is not a receipt. Later, an Animals filter may use it to route the message to [RABS] Zebras.

Filters can also have lightweight identifiers:

Filter: Adobe
Identifiers: adobe, creative cloud, acrobat, photoshop, lightroom

Identifiers can be found in:

• sender address
• sender name
• subject
• headers
• message body
• link domains
• attachment names
• extracted metadata
• semantic pre-scan topics

Filters can be marked as skippable:

not skippable -> always run when active
skippable -> only run if one or more identifiers or relevant signals are present

The locked core filters usually are not skippable. Optional provider/topic filters usually are skippable.

This keeps the pipeline efficient. An Adobe message can reach the Adobe filter when Adobe-like signals are present, but ordinary mail does not need to be analysed by every optional filter in the catalog.

Identifiers are not meant to be rigid sender rules. Companies rotate sender addresses and marketing systems. The point is a soft precheck: does this message contain enough signal to justify running this filter?

Identifiers are optional. If a filter has no simple identifiers, it can still run when active, or it can rely on semantic pre-scan relevance. This allows topic-based filters, not just provider filters.

For example:

Filter: Animals
Destinations:
  [RABS] Zebras
  [RABS] Pandas

That filter is about topic, not origin. An email does not have to come from a zebra-related sender to be routed by a zebra topic filter.

Optional Filters

Not every mailbox needs every filter. The accounts mailbox may need YakPay or Xero. A graphic designer may need Adobe or Canva. Creating every possible system folder for every mailbox would create clutter.

Email 4.0 lets filters be:

• mandatory
• optional and off by default
• optional and on by default

When an optional filter is enabled for a mailbox, RABS adds it to that mailbox's effective filter queue. It does not create the filter's [RABS] folders immediately. The folder is created only when an active filter produces a validated move to that destination. When a filter is disabled, RABS stops routing future mail through that filter but does not delete existing folders or move old messages.

Optional filters can be reordered. Their order represents priority. The higher filter gets the first chance to approve a move.

Multi-Destination Filters

A filter can route to more than one destination.

For example, a Facebook filter might route:

Message type	Destination
Facebook account notification	[RABS] Facebook
Facebook marketing digest	[RABS] Junk
Meta advertising invoice	[RABS] Receipts

This is why destinations are separate from filters. A filter describes a topic or provider. A destination describes where a message should live.

In the filter definition, the listed destinations are the filter's normal allowed destinations. Email 4.0 can also give validators a small set of escape destinations. For example, a Facebook filter may normally choose between Facebook-specific folders, but the validator can still send a Meta advertising invoice to [RABS] Receipts or a phishing message pretending to be Meta to [RABS] Junk.

Escape destinations are intentionally narrower than ordinary destinations. Security can rescue malicious mail to [RABS] Junk, but it should not file messages into receipts. Receipt escapes still need real expense evidence; a validator cannot move a message to [RABS] Receipts just because it contains financial-sounding language, a document link, or an account alert.

Leaving a message in the inbox is also a valid outcome. This is different from "continue." Continue means this filter rejected the message and later filters may still try. Stay inbox means the validator thinks the message should remain visible and the queue should stop.

When optional filters overlap, the queue order decides. For example, if an email is both Facebook-related and zebra-related:

• Facebook above Animals means Facebook gets the first chance to route it.
• Animals above Facebook means the zebra topic gets the first chance.

This avoids extra terminal-mode settings. The list order is the preference.

Dashboard and Audit

Email 4.0 expands the existing mail dashboard rather than replacing it.

Useful dashboard views include:

• how many messages security moved to junk
• how many messages security flagged as suspicious
• how many messages junk moved
• how many messages receipts approved
• how many messages each custom filter moved
• how many recommendations validators rejected
• how many users rescued messages from system folders

Each message should be explainable:

Security: cleared
Junk: cleared
Receipts: rejected, not an expense document
POI / YP3000: cleared
YakPay: approved, moved to [RABS] YakPay

This audit trail is what makes the system tunable. If a message lands in the wrong place, the team can see which filter made the mistake and whether the validator agreed.

Email Wizard

Email 4.0 routes mail. The Email Wizard advises.

The Wizard is an independent second opinion that can run after, or alongside, the normal filtering flow. It does not block Email 4.0 and it does not silently override a filter move. Its job is to look at the message separately and tell the user what it thinks.

To keep that advice useful, the Wizard should not be told what Email 4.0 decided. It receives the email content and the folders available to that mailbox, along with folder descriptions where available. It then answers:

• where the message should go, or whether it should be left alone
• whether it looks like scam, fraud, phishing, or impersonation
• whether it looks like junk or a waste of time
• why it reached that view

The reasoning should be written for a person, not as a hidden technical log. In the inbox, the Wizard appears as a small icon in the message header. The icon state gives a quick signal:

State	Meaning
Muted	Wizard has no strong disagreement with the current result
Review	Wizard recommends a different folder or sees something worth checking
Danger	Wizard believes the message may be scam/fraud or materially unsafe

Opening the Wizard view should show the reasoning first. The compact facts sit underneath:

Scam/fraud: yes or no
Junk/waste of time: yes or no
Recommended folder: folder name or leave alone

If the user agrees with the Wizard, they can accept its recommendation. That creates a normal move job; the Wizard does not directly mutate the mailbox. If the user believes the Wizard's advice should improve the system itself, a Henry feedback action can record the case for later tuning.

Henry feedback is deliberately separate from live routing. It is a learning queue for maintainers, not an automatic rule editor. This keeps Email 4.0 stable while still collecting real examples of where the system can improve.

Because the Wizard is a higher-cost independent review, its model should be configurable. The planned initial model is gpt-5.5, and the system should allow this to be changed later. All Wizard model calls must be monitored through TokenWatch and the analytics page, separately from the normal email agent and Email 4.0 validator calls.

Accuracy Over Speed

Moves are non-destructive because they are folder moves, but routing mistakes still matter. If users find scams in receipts or important mail in junk, they stop trusting the system.

Email 4.0 favours accuracy:

• use enough message body before routing
• validate move recommendations
• flag uncertain security cases instead of hiding them
• keep uncertain messages in the inbox
• make every decision auditable

The system can run one, two, or more model passes where accuracy justifies the cost. The key is that each pass has a specific job and a specific prompt.

Practical Result

Email 4.0 creates a shared mail hygiene layer:

new message
  -> sync and cache enough content
  -> pre-scan signals
  -> run that mailbox's filter queue
  -> validate move recommendations
  -> first approved move wins
  -> move, flag, continue, or keep inbox
  -> record what happened

The result is a predictable email structure across accounts, cleaner inboxes, better security screening, and a foundation where new filters can be added without redesigning the mail system each time.