Reference architecture

How a single AI-generated message becomes an audited dispatch.

DataVibe is the runtime gate between AI and your customers. This page walks through the system end-to-end so security architects and SREs can evaluate the design before they pick up the phone.

The end-to-end gate path

1
Ingress
Submissions arrive via REST (POST /v1/gate/outbound), via the SDK, or via inbound webhooks (HubSpot, Intercom, generic email intake). Every inbound webhook is HMAC-SHA256 verified with a per-workspace secret and a 5-minute replay window.
2
Policy engine
Deterministic scanners run synchronously (denylist, regex, tone, plus base-engine rules for pricing hallucination, competitor mentions, unsafe claims). Custom workspace policies layer on top; published versions are immutable.
3
Queue / dispatch / DLQ
Clean submissions queue for human review. Approved submissions hand off to the Core API execute endpoint, wrapped in a circuit-breakered retry loop with exponential backoff and per-provider failure isolation. Terminal failures land in the dead-letter queue.
4
Notification fan-out
Each approval-required event fans out to configured channels (Slack, Teams, PagerDuty, Opsgenie, Discord, generic webhook). Slack and Teams payloads include signed Approve/Reject controls so reviewers never have to open the dashboard.
5
Audit + replay
Every action writes an append-only audit row with actor, resource, IP, and request id. The flight recorder reconstructs the full timeline per submission and can replay scanners against historical payloads using the current published policy.
6
Incident postmortem
Operational incidents capture root cause, blast radius, scanner history, and dispatch traces in a single timeline that auto-correlates SystemEvents, blocked submissions, and audit log entries within the incident window.

Multi-tenant model

Workspace
Top-level isolation boundary. Every row carries `workspaceId`; every API enforces membership before it touches the DB.
Plan
Feature-gated capabilities (custom scanners, audit export, policy versioning, channel fan-out). Centralized in `lib/plan-features.ts`.
Roles
OWNER → ADMIN → REVIEWER → DEVELOPER. Platform-level: USER → CFO/CISO → ADMIN → SUPER_ADMIN. Centralized in `lib/authz.ts`.
Impersonation
Super-admins can scope a time-bounded support session into a workspace. Every impersonated action carries an `impersonatedBy` audit field.

Reliability fabric

Circuit breaker
5 failures inside a 60-second window → open 30s → half-open probe → closed. Per-provider state persisted in `circuit_breakers`.
Exponential backoff
4 attempts default, jittered exponential delays (250ms → 500ms → 1s → 2s). Only retries transient failures (5xx, 429, network).
Dead-letter queue
Terminal failures persist the full payload (clamped at 64 KiB) so an operator can replay or discard from /super-admin/dlq.
Chaos console
Synthetic failure injection (dispatch outage, scanner storm, queue lag, provider degradation, quota spike) with `metadata.synthetic = true` so analytics ignore drills.

Data flows you can map onto a network diagram

Plain-English versions of the diagrams security teams usually ask us to produce.

Inbound submission: client → Vercel edge → dashboard route → Core API → policy scanners → Postgres (gate_submissions). HMAC verified at edge for webhook intake; bearer tokens validated on REST.
Approval round-trip: reviewer (dashboard or Slack) → applyGateAction() → circuit-breaker gate → Core API execute → dispatch provider → audit_log + Notification.
Notification fan-out: notifyWorkspace() → channel registry → Slack/Teams/PagerDuty/Opsgenie/Discord/webhook (each delivery retried + DLQ'd independently).
Replay: reviewer requests replay → fetch published policy → re-run scanners against persisted payload → return decision + timeline without persisting (no side effects).

The end-to-end gate path

Ingress

Submissions arrive via REST (POST /v1/gate/outbound), via the SDK, or via inbound webhooks (HubSpot, Intercom, generic email intake). Every inbound webhook is HMAC-SHA256 verified with a per-workspace secret and a 5-minute replay window.

Policy engine

Deterministic scanners run synchronously (denylist, regex, tone, plus base-engine rules for pricing hallucination, competitor mentions, unsafe claims). Custom workspace policies layer on top; published versions are immutable.

Queue / dispatch / DLQ

Clean submissions queue for human review. Approved submissions hand off to the Core API execute endpoint, wrapped in a circuit-breakered retry loop with exponential backoff and per-provider failure isolation. Terminal failures land in the dead-letter queue.

Notification fan-out

Each approval-required event fans out to configured channels (Slack, Teams, PagerDuty, Opsgenie, Discord, generic webhook). Slack and Teams payloads include signed Approve/Reject controls so reviewers never have to open the dashboard.

Audit + replay

Every action writes an append-only audit row with actor, resource, IP, and request id. The flight recorder reconstructs the full timeline per submission and can replay scanners against historical payloads using the current published policy.

Incident postmortem

Operational incidents capture root cause, blast radius, scanner history, and dispatch traces in a single timeline that auto-correlates SystemEvents, blocked submissions, and audit log entries within the incident window.

Data flows you can map onto a network diagram

Plain-English versions of the diagrams security teams usually ask us to produce.

Inbound submission: client → Vercel edge → dashboard route → Core API → policy scanners → Postgres (gate_submissions). HMAC verified at edge for webhook intake; bearer tokens validated on REST.

Approval round-trip: reviewer (dashboard or Slack) → applyGateAction() → circuit-breaker gate → Core API execute → dispatch provider → audit_log + Notification.

Notification fan-out: notifyWorkspace() → channel registry → Slack/Teams/PagerDuty/Opsgenie/Discord/webhook (each delivery retried + DLQ'd independently).

Replay: reviewer requests replay → fetch published policy → re-run scanners against persisted payload → return decision + timeline without persisting (no side effects).