Architecture Overview

Architecture Overview

Purpose

This page describes the Sentinel Protocol as a system: the components, how data moves between them, where trust boundaries sit, and what guarantees each stage must uphold. It is the map every pillar-specific page assumes you already have.

System Context

Sentinel sits between a founder's raw communication surfaces (email, chat, calendar, CRM) and the founder's attention. It does not replace the founder's judgment — it triages, drafts, and paces, and leaves the decision with a human.

flowchart LR
    subgraph Sources["External Sources"]
        M[Email / Chat / Forms]
        C[Calendar]
        CRM[CRM / Deal Data]
        B[Wearable / Biometric Feed]
    end

    subgraph Sentinel["Sentinel Protocol"]
        I[Ingestion]
        S[Cortex Scoring]
        P[Persona Drafting]
        N[Negotiation Intelligence]
        E[Energy Shield]
        R[Routing & Review Queue]
    end

    F((Founder))

    M --> I
    CRM --> I
    I --> S
    S --> R
    S --> N
    N --> R
    P --> R
    E --> R
    B --> E
    C --> E
    R --> F
    F -->|approve / edit / reject| Out[Outbound Message]
    F -->|sets policy| Sentinel

Loading

End-to-End Data Flow

sequenceDiagram
    participant Src as Source (email/chat)
    participant Ing as Ingestion
    participant Cor as Cortex (scoring)
    participant Per as Persona (drafting)
    participant Neg as Negotiation Engine
    participant Ene as Energy Shield
    participant Fdr as Founder

    Src->>Ing: raw message
    Ing->>Ing: clean, fingerprint, extract metadata
    Ing->>Cor: normalized message + context
    Cor->>Cor: score urgency, sentiment, priority
    Cor->>Ene: request capacity check
    Ene-->>Cor: current capacity state
    Cor->>Fdr: routed by priority tier
    alt commercial context detected
        Cor->>Neg: flag for negotiation support
        Neg->>Fdr: leverage analysis, pricing suggestion
    end
    alt response drafting requested
        Cor->>Per: request style-matched draft
        Per-->>Fdr: draft response
    end
    Fdr->>Fdr: review, edit, approve
    Fdr->>Src: send (or Sentinel sends, if pre-authorized)

Loading

Components

Component	Responsibility	Detailed spec
Ingestion	Normalizes incoming messages from heterogeneous sources; deduplicates; extracts structured metadata (sender, thread, timestamps, attachments)	Cortex Ingestion Pipeline
Cortex Scoring	Computes urgency, sentiment, and priority scores; decides routing tier	Cortex Scoring Model
Neural Persona	Learns the founder's writing style; drafts responses in that voice, adapted to context	Persona Stylometry Engine, Persona Mirror Drafting
Energy Shield	Tracks the founder's own capacity signals (biometric, calendar load, decision history) and paces what surfaces and when	Energy Shield Biometric Integration
Negotiation Intelligence	Surfaces pricing and leverage analysis for commercial threads, transparently	Negotiation Intelligence Algorithms
Routing & Review Queue	Presents scored, drafted, capacity-checked items to the founder in priority order	API Reference
Sovereign Path (cross-cutting)	Local-first storage, layered anonymization, encryption at rest and in transit	Sovereign Path Threat Model

Trust Boundaries

flowchart TB
    subgraph Untrusted["Untrusted Zone"]
        Ext[External senders, third-party services]
    end
    subgraph Boundary1["Boundary: Ingestion / Sanitization"]
        Ing2[Input validation, fingerprinting, PII detection]
    end
    subgraph Trusted["Trusted Zone — Founder's Sovereign Store"]
        Store[(Local-first data store)]
        Proc[Scoring / Drafting / Negotiation engines]
    end
    subgraph Boundary2["Boundary: Human Approval"]
        Rev[Review Queue]
    end
    Founder2((Founder))

    Ext --> Ing2
    Ing2 --> Store
    Store <--> Proc
    Proc --> Rev
    Rev --> Founder2
    Founder2 -->|explicit send| Ext

Loading

Every message entering the system crosses at least one sanitization boundary before touching persistent storage, and every outbound action crosses a human-approval boundary before leaving the trusted zone — unless the operator has explicitly configured an auto-send policy for a narrowly scoped, low-risk category (see Sovereign Path Threat Model).

Design Constraints That Shape the Architecture

1. Local-first by default. The reference deployment assumes self-hosting; cloud deployment is opt-in, documented in Deployment Guide.
2. No silent autonomy on sensitive paths. Drafting and scoring are advisory; sending is a founder action unless explicitly delegated.
3. Every score is explainable. Urgency, sentiment, and leverage scores carry their contributing factors, not just a final number — see Data Schemas Reference.
4. Prompts are versioned artifacts, not hidden state. See Prompt Specification Standard.

See Also

• The Five Pillars
• Design Philosophy
• Deployment Guide