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.
Password-less authentication
CONTINUUM has no passwords to steal, reuse, or leak. Every entry is authenticated with a single-use six-digit code sent to a verified email address. Identity is managed by Clerk.
Append-only audit records
Administrative actions — access authorizations, 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 uses timing, duration and classification signals. CONTINUUM stores shortened event titles to sort commitments into life domains, but not descriptions, attendee identities, message content or call links. Calendar changes require explicit acceptance and are never made automatically.
Technical architecture
Authentication — Clerk identity provider. Email-verified accounts. Single-use codes, no stored password. JWT session tokens.
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, independently of the session itself.
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: hello@mmediahouse.com