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.

Storage at rest

Journal entries and notes are stored in readable form on our servers, protected by TLS in transit and by strict per-user access controls, including row-level security described below. Reviewers should treat readable-by-default storage as the baseline architecture, because it is what applies to the great majority of content on the platform.

Daylogue also operates an encrypted vault that holds content for a subset of accounts. Where an account has a key, vault content is encrypted with AES-256-GCM and that key is wrapped with PBKDF2-SHA256 at 600,000 iterations. Four properties of the design matter to a reviewer, and are stated here rather than left to be found:

• There is no user-facing setting that turns vault storage on. Key provisioning happens during signup and onboarding, it is not gated on which sign-in method was used, and it is not guaranteed to complete. A reviewer should assume that whether any given account holds a key is a property of that account rather than of the signup path.
• Where an escrowed copy of the key exists, it is wrapped with a server-held secret and can be unwrapped by an account-recovery endpoint. That endpoint requires the account holder's own signed-in session and their own account email, and it returns the key to that person's browser. There is no support-operated path that decrypts an account on someone else's behalf. Either way, vault content is not end-to-end encrypted.
• Derived text is stored unencrypted by design. Summaries, extracted themes, and mood metrics are stored in readable form because server-side pattern detection runs on them.
• Encrypting a check-in has not, so far, removed the readable copy. Vault writes populate the ciphertext column but leave the original text in the plaintext column of the same row. Measured on 2026-07-26: every check-in row holding ciphertext also still held its plaintext, with no row encrypted-only. For those rows the vault adds a second protected copy rather than replacing the first, so the row's real exposure is the plaintext one, and a reviewer should assess it that way. This is a defect, not the intended design, and it is being fixed; it is documented here because a reviewer would otherwise reasonably read “encrypted with AES-256-GCM” as meaning the readable copy is gone.

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. TLS is the primary protection for journal content 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

Entries are in readable form server-side, so no decryption step precedes AI processing. Content reaches the model provider when a check-in is saved, before anything is written to storage. The path works as follows:

1. 1.Check-in text is sent from the client to Daylogue over TLS 1.3.
2. 2.Content is sent to AWS Bedrock over TLS 1.3 to extract themes, mood, energy, and a short essence line.
3. 3.AWS Bedrock processes the request and returns results under Daylogue's current service configuration and written terms. Current provider, retention, and training details are maintained in the Privacy Policy and subprocessor list.
4. 4.Extraction results are stored in readable form, and server-side pattern detection runs on them. AI-generated results (summaries, narratives, insights) are stored server-side, unencrypted, since they need to be readable server-side to power those features.

Generative requests are designed to minimize direct identifiers. Voice-session infrastructure may use an account-scoped identifier to bind policy and revoke access safely. Providers receive only the data required for the requested feature under the current service configuration and subprocessor disclosures.

Voice processing

Voice check-ins use ElevenLabs Conversational AI for real-time voice interaction. Audio is streamed to the provider during the session. Provider retention and deletion follow Daylogue's configured account terms and the current subprocessor disclosures. The resulting text follows the same AI processing and storage path as typed check-ins. Daylogue reads the transcribed words; it does not analyze vocal tone or acoustic features to infer emotion.

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

Entries are stored in readable form and are technically accessible to authorized personnel with database access, though employees do not have routine access to individual entries in the ordinary course of business. Entry text is kept out of Daylogue's application logs and error reports, so day-to-day operational tooling does not surface it. Some administrative and batch-processing paths run with elevated database privileges that bypass row-level security; they exist for platform operations such as batch regeneration, not for browsing individual accounts. Administrative access to account information, subscription status, and 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.
• A database breach would expose journal entries in readable form. That is the consequence of readable-by-default storage, and it is stated here so it is not a surprise later.

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:

• Entry text is kept out of Daylogue's application logs and error reports
• 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

Product-level safety boundaries are documented on the Ethics Principles page: no streaks or other loss-aversion mechanics, an age gate in onboarding, a scope-consent checkpoint, and voice check-ins that end once crisis resources are shown.

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