Deployment Guide

Deployment Guide

Cross-cutting reference. Assumes familiarity with Architecture Overview and Sovereign Path Data Sovereignty.

Deployment Topologies

Sentinel supports three deployment topologies, in order of increasing convenience and decreasing data sovereignty:

flowchart TB
    subgraph T1["Topology 1: Fully Local (reference default)"]
        A1[All components self-hosted]
        A2[Local model inference, or self-managed API keys]
        A3[No data leaves the machine except explicit outbound messages]
    end
    subgraph T2["Topology 2: Local + Managed Model API"]
        B1[Components self-hosted]
        B2[Model calls routed to external provider]
        B3[Layered anonymization applied per Sovereign Path]
    end
    subgraph T3["Topology 3: Fully Managed / Cloud"]
        C1[Sentinel components hosted remotely]
        C2[Operator accepts provider's storage/retention terms]
        C3[Recommended only when local hosting is genuinely impractical]
    end

Loading

Topology 1 — Fully Local

Who this is for: founders whose primary concern is data sovereignty and who have the technical comfort (or a technical collaborator) to run the stack themselves.

Requirements:

• A persistently running machine or small server (the ingestion and routing layers need to be available whenever messages might arrive)
• Local model inference, or self-managed API credentials for an external model provider used only for the LLM-dependent stages (scoring, drafting)
• Local encrypted storage (see Sovereign Path Data Sovereignty for the storage model)

What stays local: everything. Tier 4 data (biometrics, PII, style profile) never leaves the machine under this topology.

Topology 2 — Local + Managed Model API

Who this is for: founders who want local data control but don't want to self-host model inference.

Requirements: same as Topology 1, plus an API key for a model provider used only for the specific LLM calls (scoring, drafting, negotiation analysis).

What crosses the boundary: only the minimized, anonymized payload required for each specific call, per the layered anonymization process in Sovereign Path Data Sovereignty — never raw biometric data, and never unredacted PII.

Topology 3 — Fully Managed

Who this is for: founders prioritizing convenience over maximal sovereignty, who accept a third-party host's storage and retention terms for their data. This topology is supported, not recommended as the default — see Design Philosophy for why sovereignty is treated as a first-order design goal rather than an afterthought.

Configuration Surface

flowchart LR
    A[Config: Deployment] --> B[Topology selection]
    A --> C[Model provider + credentials]
    C2[Config: Cortex] --> D[Priority matrix weights]
    C2 --> E[Locale calibration for sentiment]
    C3[Config: Persona] --> F[Auto-send scope, if any]
    C3 --> G[Style calibration corpus threshold]
    C4[Config: Energy Shield] --> H[Biometric integration on/off]
    C4 --> I[Capacity signal weights]
    C5[Config: Negotiation] --> J[SLA tier definitions]
    C5 --> K[Market-rate reference source, if any]
    C6[Config: Retention] --> L[Per-category retention windows]

Loading

Minimum Viable Setup Checklist

1. Choose a topology (start with Topology 1 unless there's a specific reason not to).
2. Configure at least one source adapter (see Cortex Ingestion Pipeline).
3. Set the priority matrix and locale for Cortex Scoring Model.
4. Supply an initial writing-sample corpus for Persona Stylometry Engine — below the minimum threshold, drafting falls back to a generic, clearly-labeled draft rather than a falsely confident style match.
5. Decide whether biometric integration is enabled; if not, Energy Shield Decision Fatigue Model still functions on decision-volume data alone.
6. Define SLA tiers for Negotiation Pricing and Leverage, or accept the documented defaults.
7. Review and confirm retention windows per Sovereign Path Data Sovereignty.
8. Confirm auto-send is disabled (recommended default) or explicitly scope it if enabled.

Upgrade and Rollback

Because Persona Stylometry Engine and configuration are versioned, a deployment can roll back to a previous configuration or style-profile version without data loss — this is a deliberate design choice so operators can safely experiment with tuning.

See Also

• Architecture Overview
• Sovereign Path Data Sovereignty
• Roadmap and Status