Security Architecture

Daylogue stores some of the most personal data a person can generate: how they feel, what they think about, what patterns run through their emotional life. This page documents the technical measures that protect that data. It is written for security reviewers, enterprise compliance teams, and anyone who wants to understand the architecture before trusting the product.

Encryption at rest

Journal entries and encrypted notes are protected with AES-256-GCM, a symmetric encryption algorithm used by financial institutions and government agencies. Encryption and decryption happen on the user's device. The process works as follows:

• Encryption keys are derived on-device during account creation.
• Keys are stored locally on the user's device and are never transmitted to Daylogue servers.
• Entries are encrypted before leaving the device and stored in their encrypted form in the database.
• Decryption happens on-device when the user views their entries.

Encryption in transit

All API communication between client applications and Daylogue servers uses TLS 1.3. This protects data in transit from interception, even on untrusted networks. Note that journal entries are already encrypted on-device before transmission, so TLS provides a second layer of protection for encrypted payloads and protects non-encrypted metadata (such as authentication tokens) in transit.

Database security

Daylogue uses Supabase PostgreSQL as its database layer. Security is enforced at multiple levels:

• Row-level security (RLS). Every database query is scoped to the authenticated user via PostgreSQL RLS policies. A user can only access rows where their user ID matches the row's owner. This enforcement happens at the database level, not the application level, which means that even application-layer bugs cannot expose one user's data to another.
• Cascading deletion. All user data tables reference the user's profile with foreign key constraints and ON DELETE CASCADE. When a user deletes their account, all associated data is deleted at the database level. This is not a soft delete or an archive. The data is removed.

Authentication

Authentication is handled by Supabase Auth, which provides:

• Session-based authentication with secure token management.
• CSRF token generation in middleware to prevent cross-site request forgery.
• Support for Sign in with Apple (iOS) and email-based authentication (web).

AI processing path

AI features require a brief decryption window. This is the tradeoff that makes AI-powered pattern detection and narrative generation possible. The path works as follows:

1. 1.Entry is decrypted in memory on the server for the duration of the AI request.
2. 2.Decrypted content is sent to AWS Bedrock over TLS 1.3.
3. 3.AWS Bedrock processes the request and returns results. Content is not stored or logged by the provider. AWS Bedrock does not use customer data for model training.
4. 4.AI-generated results are encrypted before being stored in the database.

No personal identifiers (name, email) are included in AI requests. The AI provider receives check-in content, recent metric history, and Focus Area labels. Nothing more.

Voice processing

Voice check-ins use ElevenLabs for real-time voice interaction. Audio is streamed to the provider during the session and is not stored after the session ends. The voice provider does not retain audio recordings or session transcriptions. The resulting text follows the same AI processing and encryption path as typed check-ins.

Data residency

Daylogue is hosted on Supabase, which runs on AWS infrastructure. All data is stored in US regions. AI processing via AWS Bedrock also occurs in US regions.

Access controls

No Daylogue employee can access encrypted journal entries. The encryption keys exist only on user devices. Administrative access to non-encrypted metadata (account information, subscription status, aggregate analytics) is logged and restricted to authorized personnel. Access logs are maintained for audit purposes.

Incident response

In the event of a data breach or unauthorized access attempt:

• Affected users will be notified within 72 hours.
• Users will be notified of any unauthorized access attempt to their account.
• Encrypted journal entries remain protected even in the event of a database breach, because the encryption keys are not stored on the server.

Compliance posture

Daylogue is a wellness tool, not a medical device or covered entity under HIPAA. It does not store, transmit, or process protected health information (PHI) as defined by HIPAA.

That said, Daylogue is designed with security practices that align with HIPAA-adjacent standards:

• AES-256-GCM encryption at rest
• TLS 1.3 encryption in transit
• Row-level security at the database layer
• Administrative access logging
• 72-hour breach notification
• Full data export and deletion on request

Daylogue was independently ethics-audited in February 2026, scoring 87 out of 100 across privacy, data handling, consent, gamification, and emotional safety.

For enterprise deployments involving educational institutions, Daylogue is designed with FERPA-compatible data handling practices. Student data is encrypted, aggregate dashboards enforce K-anonymity, and individual check-in content is never visible to administrators. Details are available on request for institutional compliance review.