-
-
Notifications
You must be signed in to change notification settings - Fork 0
Integration Examples
Cross-cutting reference. Concrete integration patterns for the source adapters described in Cortex Ingestion Pipeline and API Reference. Tracked as a Phase 5 deliverable in Roadmap and Status.
sequenceDiagram
participant Gmail as Email Provider
participant Adapter as Email Source Adapter
participant API as POST /v1/ingest
participant Pipe as Pipeline
Gmail->>Adapter: new message webhook / poll
Adapter->>Adapter: extract headers, body, thread-id
Adapter->>Adapter: map to NormalizedMessage shape
Adapter->>API: POST /v1/ingest {source: "email", ...}
API->>Pipe: ingestion -> cortex -> persona/negotiation/energy
Adapter responsibilities specific to email:
- Thread reconstruction from
In-Reply-To/Referencesheaders, since email threading is not always reliable from subject-line matching alone - MIME parsing, stripping HTML to clean text for Cortex Ingestion Pipeline sanitization
- Mapping the sender's own client-side priority flag (e.g., Gmail's "Important" marker) to
explicit_priority, per the Data Schemas Reference contract
Outbound path: an approved DraftResponse is sent back through the same provider's send API, preserving the original thread so the reply appears correctly threaded to the recipient.
sequenceDiagram
participant Slack as Chat Platform
participant Adapter as Chat Source Adapter
participant API as POST /v1/ingest
participant Pipe as Pipeline
Slack->>Adapter: message event (channel or DM)
Adapter->>Adapter: filter: relevant channels/DMs only
Adapter->>Adapter: map thread_id to Slack thread_ts
Adapter->>API: POST /v1/ingest {source: "chat", ...}
API->>Pipe: ingestion -> cortex -> persona/negotiation/energy
Adapter responsibilities specific to chat:
- Scoping: most chat platforms carry far more volume than email, much of it not founder-relevant (internal team chatter, bot notifications) — the adapter applies a relevance pre-filter before anything reaches Cortex Ingestion Pipeline, so the Cortex isn't scoring noise
- Real-time expectations: chat urgency signals (rapid successive messages) are weighted differently than email, since chat's baseline cadence is faster — see thread-velocity weighting in Cortex Scoring Model
- Shorter, more fragmentary message bodies change how Persona Contextual Masks selects tone — the Direct-Casual mask is far more commonly applicable here than in email
Calendar integration is consumed, not just produced — it's a signal source for Energy Shield Biometric Integration (calendar density) and for real Do Not Disturb windows (see Design Philosophy), not a message channel in the same sense as email or chat.
flowchart LR
Cal[Calendar Provider] --> Adapter[Calendar Adapter]
Adapter --> A[Calendar density signal]
Adapter --> B[Real DND window creation]
A --> Shield[Energy Shield capacity aggregation]
B --> Real[Actual visible calendar event —<br/>never a fabricated one]
Key constraint: when the Energy Shield gates a low-priority item and the operator has configured visible DND signaling, the calendar adapter creates a real, honestly-labeled event ("Focus block"). It never creates an event with false content to manufacture an excuse — this is the specific mechanism discussed in Design Philosophy as the direct replacement for "Calendar Hijacking."
CRM integration primarily feeds Negotiation Intelligence Algorithms — historical deal data for pricing, active pipeline count for leverage's "founder's alternatives" factor.
sequenceDiagram
participant CRM
participant Adapter as CRM Adapter
participant Neg as Negotiation Engine
Neg->>Adapter: request historical pricing basis for segment X
Adapter->>CRM: query closed deals, segment X
CRM-->>Adapter: deal records
Adapter->>Adapter: minimize to required fields only
Adapter-->>Neg: pricing basis data
CRM data typically includes counterparty-identifying information that isn't needed for the aggregate pricing computation — the adapter minimizes to exactly the fields Negotiation Pricing and Leverage requires, consistent with the minimization principle in Sovereign Path Data Sovereignty.
- Map the channel's native payload to the
NormalizedMessageschema — see Data Schemas Reference. - Apply channel-appropriate pre-filtering before ingestion, if the channel is high-volume/low-relevance by nature (like chat).
- Ensure sanitization runs on the adapter's output before it's treated as trusted — never bypass Cortex Ingestion Pipeline's sanitization stage even for a "trusted" internal channel.
- Implement the outbound path (sending an approved draft back through the native channel, correctly threaded).
- Register the adapter's supported
explicit_prioritymapping, if the channel has a native priority concept. - Add adapter-specific test fixtures to the suite described in Testing Strategy.
A reference architecture for emotionally-aware business automation.
Designed and maintained by Ciprian Ștefan Pleșca (Stefano D'Angelo) · LocalPulse Research
Home · Architecture · Design Philosophy · Five Pillars · Roadmap · Glossary & FAQ
"Sentinel does not lie." — engineering constraint, not just intention. See Design Philosophy for how this principle is enforced architecturally rather than merely stated.
Repository: github.com/Ciprian-LocalPulse/the-sentinel-protocol · License: MIT · © 2026 Ciprian Ștefan Pleșca