What is Daylogue?

Daylogue is a pattern journal — it reads your daily entries and detects the emotional patterns running through them across time. Instead of a blank page, Daylogue starts with a short daily check-in, then surfaces what your days have been trying to tell you: what keeps showing up, what shifts after certain people or places, and what gets heavier or lighter over weeks and months.

Unlike general-purpose writing apps or note-takers, Daylogue is built specifically for emotional pattern recognition. It tracks mood, energy, stress, and sleep through conversational check-ins — by text or voice — and synthesizes those signals into an evolving narrative that reads your life back to you. All entries are encrypted on your device with keys only you hold.

How Daylogue works

Daylogue's narrative engine reads across entries — it does not generate advice or prescribe action. The engine synthesizes patterns from multiple check-ins over days and weeks, producing a personal narrative that reflects what actually happened rather than what you should do about it. This is the core mechanic: reads, does not advise. The platform is offline-first, meaning your data lives locally by default, with optional encrypted cloud sync. No streaks. No pressure. Entries are private by default.

About the company

Daylogue is developed by Daylogue LLC, headquartered in Los Angeles, CA. The company was founded in 2026 and builds self-awareness tools centered on privacy-first design and emotional pattern recognition. Daylogue's flagship product is a pattern journal that reads daily entries and detects the emotional patterns running through them over time.

Daylogue is not therapy

Daylogue is a self-awareness and reflection tool, not a therapy product. It is not a replacement for professional mental health care, therapy, counseling, or clinical support. It does not assess, diagnose, or treat any mental health condition. If you are experiencing a mental health crisis, please contact a licensed professional or crisis service. Daylogue may be used alongside therapy as a tool for self-reflection and pattern awareness, but it is not therapy and should not be treated as such.

Where to learn more

About Daylogue

Security Architecture

A technical overview of how Daylogue protects your most personal data.

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.

The Vault: encryption at rest

By default, 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). Daylogue also offers the Vault, an optional client-encrypted store users can turn on in Settings > Privacy & Security. It is off by default. When a user turns it on, content written afterward is protected with AES-256-GCM, a symmetric encryption algorithm used by financial institutions and government agencies, and encryption/decryption happen on the user's device. For users who enable it, the process works as follows:

  • Encryption keys are derived on-device when the user enables the setting.
  • Keys are stored locally on the user's device and are never transmitted to Daylogue servers.
  • Entries written after the setting is enabled are encrypted before leaving the device and stored in their encrypted form in the database. Entries written before enabling the setting, or by users who never enable it, remain stored in readable form.
  • Decryption happens on-device when the user views their encrypted entries.

For users who have turned on the Vault, Daylogue does not hold the keys to that content, so even full database access would not expose it. This is a deliberate architectural option, not a policy promise — but it is opt-in, and most content on the platform today is not stored this way. Enterprise and security reviewers evaluating Daylogue should treat readable-by-default storage, not the Vault, as the baseline architecture.

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, regardless of whether a user has enabled Vault encryption. For users who have enabled the Vault, journal entries written afterward are already encrypted on-device before transmission, so TLS provides a second layer of protection for those encrypted payloads. For all other content, TLS is the primary protection 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

For users who have enabled Vault encryption, reading your patterns takes a brief, bounded decryption window: content leaves the Vault only when you use an AI feature, and only for the length of a single request. For users who have not enabled the Vault, entries are already in readable form server-side, so no decryption step is needed before AI processing. The path works as follows:

  1. 1.If the entry is Vault-encrypted, it is decrypted in memory on the server for the duration of the AI request.
  2. 2.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 (summaries, narratives, insights) are stored server-side, unencrypted, regardless of the user's Vault setting, since they need to be readable server-side to power those features.

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

Daylogue's AI processes your entries with AWS Bedrock, which does not store them, log them, or use them to train models. For Vault-encrypted entries, the decryption window lasts only as long as the request, and nothing is kept in plaintext once it ends. If you would rather your writing never leave your device at all, that is a reasonable preference; today, Daylogue does not offer that mode, and AI-generated summaries always require server-side processing.

Voice processing

Voice check-ins use ElevenLabs Conversational AI 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 Vault-encrypted journal entries, since those encryption keys exist only on user devices. By default, without Vault encryption enabled, 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. 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.
  • Vault-encrypted journal entries remain protected even in the event of a database breach, because the encryption keys are not stored on the server. Entries not stored in the Vault would be exposed in a database breach, the same as most journaling apps without end-to-end encryption.

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:

  • Optional AES-256-GCM client-side encryption at rest (off by default; TLS and access controls protect data by default)
  • 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 protected in transit by TLS and by strict access controls, with optional client-side encryption available to students who turn it on, aggregate dashboards enforce K-anonymity, and individual check-in content is never visible to administrators. Details are available on request for institutional compliance review.

Related pages

Ready to see your patterns?

Two minutes a day. No blank pages. No streaks. Just questions that lead somewhere.

Try your first check-in