Skip to content

Integration Examples

Ciprian-LocalPulse edited this page Jul 31, 2026 · 1 revision

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.

Pattern: Email (Gmail-style)

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
Loading

Adapter responsibilities specific to email:

  • Thread reconstruction from In-Reply-To / References headers, 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.

Pattern: Chat (Slack-style)

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
Loading

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

Pattern: Calendar

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]
Loading

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."

Pattern: CRM (Deal/Pipeline Data)

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
Loading

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.

Writing a New Adapter: Checklist

  1. Map the channel's native payload to the NormalizedMessage schema — see Data Schemas Reference.
  2. Apply channel-appropriate pre-filtering before ingestion, if the channel is high-volume/low-relevance by nature (like chat).
  3. 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.
  4. Implement the outbound path (sending an approved draft back through the native channel, correctly threaded).
  5. Register the adapter's supported explicit_priority mapping, if the channel has a native priority concept.
  6. Add adapter-specific test fixtures to the suite described in Testing Strategy.

See Also

Clone this wiki locally