Your data is private.
Your intelligence belongs to you.
Every security claim on this page reflects the implementation as it exists today. Where capabilities are planned but not yet active, we say so.
Encryption in transit and at rest
All connections to CONTINUUM are encrypted via TLS. Your data at rest is protected by Neon's infrastructure-level encryption (AES-256). Calendar OAuth tokens receive an additional layer of application-level encryption (AES-256-GCM) before being written to the database.
Invitation-gated access
CONTINUUM is not open registration. Every account begins with a manual access review. Only invited users can create accounts. Authentication is managed by Clerk with verified email addresses.
Append-only audit records
Administrative actions — access approvals, account deletions, setting changes — are written to append-only audit records. Application code does not modify or delete audit log rows.
No data selling
CONTINUUM is a software product. Your personal information and intelligence outputs are never sold to third parties, used for advertising, or shared beyond the subprocessors listed in our privacy policy.
Rate limiting and security headers
API endpoints are rate-limited per user and per IP. All responses include standard security headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referral-Policy, Permissions-Policy.
Minimal calendar data
Calendar integration reads event metadata only — timing, duration, and domain classification signals. Event titles, descriptions, attendee identities, and message content are never stored. Read-only OAuth scopes are requested; write access is not.
Technical architecture
Authentication — Clerk identity provider. Email-verified accounts. JWT session tokens. Invitation-gated registration.
Database — PostgreSQL hosted on Neon. Infrastructure-level encryption at rest. Isolated to CONTINUUM's account. Connection via SSL-required connection strings.
Calendar tokens — AES-256-GCM encrypted at application layer before write, using a dedicated encryption key separate from database credentials. Two independent encryption layers.
Transport — TLS 1.2+ enforced on all connections. HSTS header applied. No mixed content.
Access control — Role-based (member / admin / founder) enforced at middleware and API layers. Invitation-gated at registration.
Rate limiting — Per-user and per-IP limits on all intelligence and mutation endpoints. In-memory with IP extraction from X-Forwarded-For (last-hop only).
WHAT WE DO NOT CLAIM
- — We do not hold SOC 2, ISO 27001, or any other third-party security certification. These are planned for the enterprise roadmap.
- — Database row-level security (Postgres RLS) is not currently configured. Application-layer role checks enforce access isolation.
- — CONTINUUM does not collect biometric data, physiological sensor readings, or wearable device data. No such integrations exist.
- — Audit records are append-only by application convention; immutability at the database layer is not currently enforced.
Security inquiries: [FOUNDER INPUT REQUIRED: security email address]