Security Architecture

Daylogue stores personal writing and other information people choose to share. This page explains what the service reads, why it reads it, which controls reduce risk, and where those controls stop.

Storage at rest

Daylogue reads the entries you choose to sync to create narratives and surface patterns. Entries are not end-to-end encrypted. Data is protected in transit with TLS, and ordinary account access is restricted with per-user database controls.

Some legacy account and vault paths contain additional encryption components. They do not change the baseline above and are not presented as a user-selectable protection or as end-to-end encryption. Until coverage and key custody are independently re-verified, users should assume synced content is readable by the service.

• There is no user-facing setting that makes synced entries end-to-end encrypted.
• Daylogue's server processing requires readable input for narratives and pattern reads. Service-controlled or recoverable keys do not create a zero-access architecture.
• Generated summaries, narratives, extracted themes, and structured fields may also be stored in readable form to operate the features that use them.
• Additional encrypted copies do not remove the risk created by a readable copy. Daylogue will not market partial or legacy coverage as protection for all entries.

Encryption in transit

Data sent between supported Daylogue clients and the service is protected in transit with TLS. This reduces interception risk while data travels over the network. It is different from end-to-end encryption and does not prevent Daylogue's servers from reading synced content.

Database security

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

• Per-user database controls. Row-level security is used to restrict ordinary signed-in account access. RLS reduces cross-account access risk; it does not make exposure impossible, and privileged service and administrative paths require separate controls.
• Deletion lifecycle. Account deletion begins with a 30-day grace period when you can cancel the request. After that period, Daylogue begins deletion from active product systems. Backup, processor, billing, audit, legal, and user-authorized Collab retention limits are described in the Privacy Policy.

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.
2. 2.When an AI feature is used, the content required for that request is sent to the disclosed AI provider over TLS.
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 uses several service providers to host the application and operate requested features. Data locations can differ by provider and feature. Review the current subprocessor list for the verified role of each provider. Daylogue does not currently promise a single-region residency boundary to general customers.

Access controls

Entries are stored in readable form and can be accessed through authorized privileged paths needed to operate, secure, support, and comply with legal obligations for the service. Ordinary account access is restricted by per-user database controls. Privileged service, administrative, and background-job paths do not rely on those ordinary-user controls and must be separately restricted and reviewed. Daylogue is verifying logging and diagnostics coverage before making a blanket promise that sensitive content can never reach operational tools.

Incident response

Suspected incidents are reviewed, and notices are provided when required by applicable law, contracts, and the facts of the incident. A fixed deadline does not apply to every event or jurisdiction.

• A security alert or failed login is not automatically a reportable breach. Daylogue investigates scope, affected data, and legal notice requirements.
• When notice is required, it will describe the known facts, affected information, and practical steps recipients can take.
• 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 consumer self-reflection product, not therapy or a replacement for professional care. Daylogue does not claim HIPAA compliance, SOC 2 attestation, NIST alignment, or any other certification on this page.

The current public control statements are deliberately narrower:

• Synced entries are server-readable so requested narratives and pattern reads can run
• TLS protects data in transit
• Per-user database controls restrict ordinary account access
• Privileged paths require separate access controls and review
• Incident notices follow applicable legal and contractual requirements
• Account deletion follows the disclosed grace period and downstream retention limits

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 a fallible automated resource handoff. Daylogue is not monitored for emergencies and does not promise to detect or respond to a crisis.

Organization, coach, school, employer, team, and Collab roles do not all receive the same fields or use the same consent model. Daylogue is documenting those combinations separately before making broader institutional compliance claims. Employer-context dashboards are designed not to display individual entry text or member-level mood, energy, or stress scores; eligible aggregate self-reported trends appear only after the applicable contributor and suppression thresholds are met. Authorized service, security, support, legal-process, and separately consented sharing paths are different.