Structural Privacy Document

What Throughline does (and doesn't) handle

Throughline is a follow-through agent for AI products whose users make commitments. It receives commitment intents from integrators (e.g. an AI assistant capturing "remind me to send the draft Friday EOD"), classifies them, and runs a campaign of touches (emails, SMS, push, etc.) until the commitment is closed. The minimum data we need is the user's intent text, a contact address (email at minimum), and an identifier the integrator can use to dedupe their users.

We do not store payment data, government IDs, biometrics, or PHI. Integrators are responsible for keeping such data out of the intent + context fields. When detected, our injection-defense classifier flags and blocks captures that contain credential-shaped content.

Data flows by class

Capture intents

Integrator → Throughline API (HTTPS, API-key auth) → commitments table. The intent text passes through three LLM gates (noop check, classifier, injection-defense) via Vercel AI Gateway → Anthropic. AI Gateway logs are off by default for Throughline; integrators using their own AI Gateway tenants can configure separately. Retention: 1 year past close on the parent commitment.

User contact addresses

Each user's contact channels (email, phone, push token, etc.) live in user_channel_addresses. Email and phone are required for outbound delivery; the channel adapter encrypts in transit but stores plaintext (the address itself is the routing key — encryption-at-rest at the column level would defeat that). Database disks are encrypted at the provider layer.

Audit log events

Every state-changing action lands in audit_events with actor, kind, payload (JSONB), and an integration/teamspace fk. Retention defaults to 7 years per teamspace, configurable down to 90 days. The Phase 11.6 cron prunes events older than the teamspace's retention window daily.

OAuth tokens (Google Calendar, future)

Refresh + access tokens encrypted with AES-256-GCM under a per-row DEK. Decrypted only at request time by the channel adapter; never logged, never echoed in responses. Scoped to the minimum needed: https://www.googleapis.com/auth/calendar.readonly for reads, https://www.googleapis.com/auth/calendar.events for write-back if the integrator opts in.

SSO claims (enterprise tier)

When a customer's admin logs in via OIDC, the verified id_token claims (sub, email, name) drive JIT provisioning. We store the email on teamspace_members.email and a synthetic users.externalId derived from the IdP subject. The id_token itself is consumed and discarded; only the minimum identity fields persist.

Outbound channel logs

Each outbound touch records delivery / engagement / dismissal / failure timestamps in touches. We retain message bodies in audit payloads where useful for delivery debugging; customers can opt to omit message bodies from audit payloads for stricter retention profiles.

Lawful basis (GDPR Art. 6)

• Contract for processing necessary to deliver the agreed service to the integrator (commitment storage, campaign execution, channel delivery).
• Legitimate interest for security telemetry (audit log, abuse signals, trust scoring) — balanced against data-subject rights via the export + delete endpoints.
• Consent for direct outbound communication channels where required (SMS in the US/UK, voice). Consent is captured by the integrator; Throughline enforces the user-permission table at the channel-resolve step.

Data subject rights

GDPR + CCPA/CPRA rights are honored through:

• POST /v1/users/:id/gdpr/export — returns a machine-readable bundle of every record keyed to the user.
• POST /v1/users/:id/gdpr/delete — soft-deletes the user, redacts message bodies in audit payloads, and cancels in-flight campaigns. Hard delete follows after the audit retention window expires.

Both endpoints require integrator API-key auth and emit a dedicated audit event so the data-subject request itself is traceable.

Contact

Privacy questions: privacy@throughline.dev. Security disclosures: security@throughline.dev.