Hinata Email Intelligence — Domain Evolution Plan

Authored 2026-06-04 · Owner: Meruem (domain-evolution) · Reviewed by: Jimmy Neutron Scope: end-state maturity path + Mail.Send gate conditions Architecture baseline: the-government/information_reference/runtime-state/email-intelligence-architecture.md

---

Current State Snapshot (2026-06-04)

Dimension	Status
Gmail archive	14,682 emails · fully ingested · ~/Sandpit/hinata/resources/email-poller/gmail-michael-asolo1/
Outlook backfill	In progress · 3 accounts: n.nnamah, michael.nnamah, michael.asolo@hotmail.co.uk
Azure app hinata-brain	Mail.Read + Mail.ReadWrite + offline_access active · Mail.Send NOT enabled
Classification	Architecture approved · not yet built
Sent analysis	Not started
Cross-account unification	Not started
Lead routing	Not started

End-state (backward-planned): A unified Michael identity graph, derived from all 4 accounts, that reads, classifies, surfaces missed opportunities, generates leads for Rock Lee and Zuko, and — under strict doctrine gate conditions — drafts and sends on Michael's behalf with a mandatory human-in-the-loop approval step at every send action.

---

Phase 0 — Archive Complete (current → complete)

What it unlocks: Full corpus available for one-time ML fit. Nothing is classifiable until the corpus is whole.

Deliverables:

• Outlook backfill complete: all 3 accounts → ~/Sandpit/hinata/resources/email-poller/
• SENT folders extracted for all 4 accounts (Gmail + 3 Outlook)
• Deduplication pass: cross-account duplicate detection by Message-ID header, thread-ID, subject+date+sender triplet
• Corpus manifest: total count per account, date range, sent vs received split

Maturity criterion: All 4 inboxes + sent folders present locally. Dedup report shows <2% duplicate rate across account pairs.

Government alignment:

• probe-before-execute — any mass archive operation is irreversible; Jimmy must probe for confirmation before executing server-side deletions
• explicit-intent-must-become-task — Outlook backfill task must carry Closure path pointing at corpus manifest file

---

Phase 1 — Classification Engine Live

What it unlocks: Every email in the corpus has a category, confidence, and priority score. The Layer 1/2/3 pipeline from the architecture doc is running.

Deliverables:

• email-classifier.py — Layer 1 (structured rules) + Layer 2 (BGE-small + BERTopic + spaCy NER)
• BERTopic one-time fit on full corpus (run overnight, paid once)
• Layer 3 recommendation engine with delete confidence scores
• All classification rules reference STRUCTURED_CATEGORIES and PROTECTED domains from architecture doc

Maturity criterion: >90% of emails have a category + confidence score. BERTopic topic map reviewed by Michael and topic→commander domain mappings confirmed.

Government alignment:

• cli-write-target-is-inbox-only — classifier writes output to designated data paths, never to vault root
• All classification category labels must map to a named Hinata commander domain — no orphan categories

---

Phase 2 — Account Homogenisation + Unified Identity Graph

What it unlocks: Michael is one identity across 4 accounts. Cross-account sender relationships, threads, and deduplication resolve to a single view.

Account Homogenisation Doctrine

All 4 email accounts (Gmail michael.asolo1@gmail.com, n.nnamah@outlook, michael.nnamah@outlook, michael.asolo@hotmail.co.uk) are treated as a single Michael identity surface. Rules:

1. Sender graph is unified. A sender who has emailed across multiple accounts is one node in the sender relationship graph. Their interaction history, reply rate, and lead signals aggregate across all accounts.
2. Thread continuity crosses accounts. Replies to an email sent from Gmail that arrive at Outlook are one thread. Resolved by Message-ID, In-Reply-To header, and subject normalisation.
3. Priority scoring is per-identity, not per-account. An email flagged as priority=5 in one account does not exist again as an unscored email in another account.
4. SENT folders contribute equally. Sent email from any account is first-class data, not a secondary signal.
5. No account-specific classification rules. The same STRUCTURED_CATEGORIES and PROTECTED lists apply identically to all 4 accounts. Account-specific overrides require a law store entry, not a code override.

Deliverables:

• Sender relationship graph (sender → all accounts they have contacted, reply rate, last contact, thread count)
• Unified priority feed endpoint: GET /api/email/feed returns de-duplicated results across all 4 accounts
• Cross-account dedup report: counts of deduplicated threads and senders

Maturity criterion: Unified feed returns results without account-level duplicates. Sender graph has been generated and is accessible via API.

Government alignment:

• All routing and classification rules in the unified system must have a corresponding law or architecture doc reference — no freestanding local rules

---

Phase 3 — Sent Email Analysis + Style Model

What it unlocks: Michael's writing voice is modelled. Cold leads are surfaced. Missed opportunities become tasks.

What to Extract from SENT Folders

Signal type	Method	Output
Writing style fingerprint	Token frequency, sentence length distribution, formality score, vocabulary richness	Style baseline JSON per account (expect variation by account = context)
Tone by recipient type	NER on recipient domain → cluster by recruiter/personal/finance/arts	Tone-by-context profile
Vocabulary corpus	All body text from sent emails → vocab frequency table	Input to AI drafting style model
Cold lead detection	Sent with no reply within 14 days + recipient not in PROTECTED list + subject not transactional	Surface as missed opportunity candidate
Outbound opportunity signals	Sent emails referencing money, work, collaboration, meeting request	Flag for Rock Lee / Zuko review

Commander Feed

Extracted signal	Routes to
Cold outbound leads > 14 days no reply	Rock Lee (side hustle opportunity feed) + Zuko (career outreach follow-up)
Recruiter / career outreach sent	Zuko — career relationship tracker
Writing style corpus	Held locally for AI drafting baseline (future Phase 5 input)
High-value outbound (finance, legal, official)	Bulma (financial), Kakashi (VMO2 / work)

Deliverables:

• sent-analyser.py — processes all SENT folders, produces style JSON + cold lead list + outbound opportunity list
• GET /api/email/missed-opportunities — ranked list of cold leads + no-reply threads surfaced as task candidates
• Task emission: each missed opportunity above confidence threshold → emitted to tasks.json with Closure: path per task-emission-must-carry-closure-path law

Maturity criterion: Sent analysis has run on full corpus. Cold lead list reviewed by Michael. At least one missed-opportunity task successfully closed (lead followed up, outcome logged).

Government alignment:

• explicit-intent-must-become-task — every missed opportunity flagged by the system that Michael explicitly acts on must become a task row, not a Telegram message only
• task-emission-must-carry-closure-path — every task emitted from missed-opportunity detection carries a Closure path

---

Phase 4 — Lead Generation Feed (Rock Lee + Zuko)

What it unlocks: Email intelligence is a live lead generation signal for Rock Lee (side hustle) and Zuko (career). Inbound and outbound leads are surfaced automatically.

Lead Signal Detection

Inbound (RECEIVED emails):

• Recruiter domain + job title keyword + salary mention → Zuko · priority=5
• Partnership / collaboration / commission / freelance keyword + person_name in From → Rock Lee · priority=4
• Workshop / course / skill-building aligned with Hinata KPIs → Shikamaru / domain-learning

Outbound (SENT emails, Phase 3 cold leads):

• Sent to recruiter domain + no reply 14d → Zuko follow-up task
• Sent re: project/collaboration + no reply 14d → Rock Lee follow-up task

Deliverables:

• GET /api/email/leads — returns inbound leads split by Rock Lee / Zuko domains
• Rock Lee brief template populated from email lead data (company, contact, signal type, email date, follow-up status)
• Zuko brief template populated from career lead data

Maturity criterion: At least 3 inbound leads routed to Rock Lee or Zuko and confirmed as valid by Michael. Lead detection false-positive rate <20% on a 50-email sample review.

Government alignment:

• Lead routing to commanders must follow the delegation-hierarchy law — email system routes signal, not instructions; commanders own the decision layer
• colonel-mandatory-review — Rock Lee and Zuko leads reviewed by their colonels (Goku/FIRE for Rock Lee · Levi/FORGE for Zuko) before actioning

---

Phase 5 — Mail.Send Active

What it unlocks: The system can send emails on Michael's behalf. AI-drafted replies, follow-up templates, and outbound sequences are possible.

This phase does not begin until all gate conditions below are satisfied.

---

Mail.Send Gate — Explicit Conditions

Mail.Send is enabled in Azure app hinata-brain (client_id: 1f369c04-4a43-46c7-8b7c-a81166f7066c) only when ALL of the following are satisfied:

Gate 1 — Human-in-the-loop is structurally enforced, not optional. No email is sent without Michael explicitly approving the draft. Approval must be a deliberate action (button click in Studio or Telegram confirmation), not a timeout or default. The system architecture must make skipping approval impossible, not just unlikely. Reference: probe-before-execute law — any outbound action is irreversible; every send is a probe-required action.

Gate 2 — Audit trail is complete and permanent before first send. Every send action must be logged to a local append-only audit file (~/Sandpit/hinata/data/email-send-audit.jsonl) with fields: timestamp, recipient, subject, draft source (AI-generated / human-composed), approval_method, account_used. This log must exist and be non-empty from a test send before Mail.Send is activated in production. Reference: task-emission-must-carry-closure-path law — no send capability without a traceable closure artifact.

Gate 3 — Style model has been reviewed and confirmed by Michael. The AI drafting component must produce at least 20 draft emails from Michael's sent corpus, reviewed and rated by Michael, before it is permitted to generate drafts for outbound sending. Minimum approval rating: 80% of drafts rated "acceptable without major edit". Reference: sent analysis Phase 3 — the style corpus is the prerequisite; the model is not activated until Michael has validated its voice.

Gate 4 — Protected-address blocklist is enforced at the send layer. A blocklist of addresses and domains that the system may never send to autonomously must be defined and enforced at the API layer, not at the application layer. Includes: HMRC, NHS, banks, legal contacts, any address in PROTECTED domains from the architecture doc, and any address Michael explicitly adds. Sending to a blocked address must return a hard error, not a warning. Reference: no-writes-to-home-root law analog — the system must have structural guardrails, not advisory ones.

Gate 5 — Send rate limit is configured and enforced. The system may not send more than 5 emails per 24-hour window in Phase 5. This limit is enforced at the Azure token / middleware layer, not in application code alone. Rate limit increase requires explicit Michael approval and a new doctrine entry in the government law store. Reference: split-heavy-tasks-parallel law — high-impact tasks must be bounded; autonomous send is high-impact.

Gate 6 — Doctrine alignment check has passed. Before Mail.Send is enabled, Jimmy Neutron runs a classification-rules audit against the government law store (the-government/feedback/) to confirm: no classification rule contradicts an existing Hinata law, no routing decision overrides a commander's domain boundary, and no auto-action operates without an explicit human approval step. Audit output must be reviewed and approved by Orochimaru (scout / doctrine alignment role). Reference: audits-are-police-not-law law — the audit confirms compliance; Orochimaru's sign-off is the gate.

Gate 7 — Credential security confirmed.Mail.Send scope must be stored in Itachi (credential store), not in plaintext config files. Token rotation plan must be in place. Reference: no-credentials-in-telegram law + never-print-credentials law — send credentials are higher risk than read credentials; security standard must be higher, not equal.

---

Risk Register

Risk	Likelihood	Impact	Mitigation
False-positive send (system sends without Michael's intent)	Low pre-gate · Medium if gates skipped	Critical — reputational, legal	Gate 1 (structural approval) + Gate 4 (blocklist) are non-negotiable; no workaround path
Sent corpus style model amplifies a bad communication pattern	Medium (style models learn what is, not what should be)	Medium — subtle tone drift in AI drafts	Gate 3 requires Michael to review 20+ drafts before activation; style corpus excludes emails Michael rated as poor
Cross-account dedup misses a thread (false merge)	Medium (threads split across accounts are edge cases)	Low-medium — duplicate actions on same email	Phase 2 dedup uses 3-signal matching (Message-ID + subject normalisation + date); single-signal merges are flagged for review, not auto-merged
Lead routing to Rock Lee / Zuko generates noise (low-signal leads treated as high-priority)	High in early iterations	Low-medium — commander time wasted	Phase 4 maturity criterion requires <20% false-positive rate before leads are routed automatically; initial period is human-reviewed
Government law drift — a new law contradicts an existing email classification rule	Low (laws are additive)	Medium — classification behaviour becomes non-compliant	Gate 6 doctrine alignment check runs before Mail.Send + quarterly re-run thereafter; email system rules are not standalone, they reference law store entries

---

Next Upstream Moves (in order)

1. Complete Phase 0: Outlook backfill + SENT folder extraction for all 4 accounts
2. Run email-classifier.py (Phase 1) — BERTopic fit overnight
3. Build sent-analyser.py (Phase 3 — can run in parallel with Phase 2 once corpus is whole)
4. Emit missed-opportunity tasks to tasks.json with Closure paths — first real output of the system

Research brief for l-research (SYNTHESIS): Style model fidelity — what is the minimum sent-email corpus size required for a fine-tuned or retrieval-augmented drafting model to produce output that a subject cannot distinguish from their own writing at >80% accuracy? What is the state of the art for personal-voice preservation in small-corpus conditions (< 5,000 sent emails)?