Privacy Policy

Effective date: August 1, 2026

Last updated: August 1, 2026

This Privacy Policy explains how Matthew Riese, operating Bearing Time Management (“Bearing,” “we,” “us,” or “our”), collects, uses, discloses, and protects personal information when you use Bearing’s websites, mobile applications, browser and other software extensions, accountable browser, and related services (collectively, the “Services”).

Bearing combines task and commitment planning, calendars, screentime tools, fitness features, financial stakes, notifications, and optional AI assistance. The information we process depends on the features you choose to use and the permissions you grant.

Information we collect

Some of this information—including health information, journal content, precise location, financial information, and the content of communications—may be considered sensitive personal information under applicable law. We use sensitive information only to provide the feature you requested, maintain security, comply with law, or for another purpose disclosed to you with any consent the law requires. We do not use health or fitness information for advertising.

You can use many core planning features without enabling optional permissions or integrations. If you decline a permission, the related feature may not work, but unrelated features should remain available.

How we use information

We use personal information to:

• create and maintain your account;
• sync your information across your devices and make it available offline;
• provide tasks, routines, journals, calendars, screentime controls, accountable browsing, fitness tracking, financial stakes, notifications, and other features you request;
• authenticate connected services and import information you direct us to import;
• process payments, enforce stake rules, issue refunds, and maintain transaction records;
• operate optional AI features, including responding to requests, invoking app tools, finding media, and generating task images;
• personalize settings and calculate information such as local sunrise and sunset times;
• provide support and communicate about the Services;
• measure feature use and improve reliability without intentionally sending task text, journal text, AI chat content, fitness samples, screentime websites, or payment amounts to PostHog, and without using PostHog data for advertising or ad targeting;
• diagnose crashes and errors, monitor performance, prevent abuse, and protect the Services; and
• comply with legal obligations, enforce our agreements, and establish or defend legal claims.

Where applicable law requires a legal basis, we rely on performance of our contract with you, your consent, compliance with legal obligations, and our legitimate interests in securing, operating, and improving the Services. You may withdraw consent for future processing where consent is the basis, although that does not make earlier processing unlawful.

Account sign-in and communications

Bearing currently supports email-and-password authentication and Google sign-in. If you choose Google sign-in, Google provides an account identifier and email address and may provide your name, profile image, and other basic profile information made available through the openid, userinfo.email, and userinfo.profile scopes you approve. Supabase processes authentication credentials and stores the authentication account and information Google supplies. Bearing uses name information to initialize the encrypted first- and last-name fields in your Bearing profile.

We currently send authentication and account-related emails and daily-summary emails. Daily summaries can be turned off or paused in Settings or disabled through the unsubscribe link in the email. You cannot opt out of authentication, security, or other non-promotional messages that are necessary to create, provide, or protect your account.

We do not currently send promotional marketing emails. If we introduce them, we will provide any notice or consent required by law and a way to unsubscribe. Opting out of promotional emails will not stop necessary non-promotional messages.

If you use the in-app contact form, EmailJS processes the name, email address, subject, and message you submit to deliver it to us. The form does not currently accept attachments. If you contact us by email or another support channel, we and the relevant email or communications providers process the content and attachments you choose to send.

Tasks, journals, templates, and other user content

Bearing lets you enter or configure tasks, commitments, journal entries and prompts, journal, routine, and calendar or time-blocking templates, routine-step notes, schedules, goals, and related content. We refer to these categories together as “user content” rather than listing every underlying record or table. User content is generally free-form, and you decide what to enter. Bearing’s default tasks and general journal prompts are optional examples and are not intentionally designed to request health, religious, financial, or other legally sensitive information. Because you control the content, however, user content may contain sensitive information you choose to provide.

Selected user-content fields are protected with server-managed field-level encryption at rest. These currently include task and task-list names and descriptions; task abbreviations and video URLs; commitment names, rewards, and free-form commitment text; journal-template names and descriptions, journal prompts, and journal responses; routine-template names and descriptions and routine-step notes; and calendar-template names and descriptions. Journal prompt snapshots retain the encrypted prompt rather than a plaintext copy.

Field-level encryption does not cover every record or field and is not end-to-end encryption. Operational metadata remains readable to Bearing’s backend, including identifiers and relationships, content and commitment types, colors and emoji, statuses, archive and completion state, timestamps, schedules, durations, quantities, ordering, prompt and step configuration, and time-tracking and validation records. Short notes attached directly to individual calendar blocks are also currently stored without field-level encryption. Task-photo files and their URLs and metadata are not protected by this field-level encryption. Bearing’s systems can decrypt protected content when needed to provide requested features, such as displaying and syncing content, sending enabled reminders or summaries, or supplying context to an AI feature you use.

We do not routinely review user content. Access by Bearing personnel is limited to situations where it is reasonably necessary to provide support you request, investigate or address a security or service problem, protect the Services, comply with law, or establish or defend legal claims. Access should be limited to the information reasonably necessary for the situation.

The Services do not currently provide a feature for sharing tasks, journals, or templates with other users, coaches, or accountability partners. This does not change the public-URL limitation for task photos described below. We do not use historical commitment-performance data for risk scoring or profile-based recommendations.

Connected calendars

Google Calendar is the only external-calendar provider Bearing currently supports. Outlook and Apple Calendar are not current integrations. We will update this policy and the relevant authorization notice before adding another provider or using connected-calendar information for a new purpose.

When you connect Google Calendar, Bearing requests the calendar.readonly and userinfo.email OAuth scopes and offline access. The calendar scope permits Bearing to view and download any calendar you can access in Google Calendar; Google authorizes the account connection, not an individual calendar. Bearing uses the email scope to identify the connected Google account. Bearing initially retrieves the list of calendars available to that account and stores each calendar’s provider identifier, encrypted name, color, and disabled status so you can choose which calendars to enable. Bearing synchronizes event content only from calendars you enable.

For an enabled calendar, the Google Calendar API can return a complete event resource. Depending on the event, that response may include identifiers, title, description, location, organizer and creator information, attendees and their responses, attachments, conferencing details, visibility and access settings, start and end values, time zone, all-day and recurrence information, color, and status. Bearing’s current request does not use a partial-response field filter, so the sync service may receive those fields transiently. The current adapter extracts the identifier, title, description, location, start and end values, time zone, all-day and recurrence information, color, and status and discards the other response fields. Bearing persists only the provider event, calendar, and account identifiers; an encrypted event title; start and end times; time zone; all-day and recurrence information; color; status; and synchronization metadata. Descriptions and locations are not saved to your account. The integration is read-only: Bearing does not create, edit, or delete an event in Google Calendar.

OAuth access and refresh tokens are encrypted with Bearing’s server-managed field-level encryption and kept in a server-only database table that is not synchronized to the app’s local database. Calendar names and event titles also receive field-level encryption. Provider account email addresses and calendar, event, account, timing, recurrence, color, status, and synchronization metadata remain readable to Bearing’s backend. Bearing uses offline access so it can refresh an access token and synchronize enabled calendars while you are not present.

Connected-calendar cache rows are not directly available to Bearing’s AI assistant. If you import an external event as a task, its title becomes the name of a regular Bearing task and its times become a Bearing plan entry. That imported task information may then be included in AI context when you use the optional assistant, as described in AI features. Bearing’s use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including its Limited Use requirements.

Disabling a calendar stops future synchronization for that calendar but does not delete information already cached or tasks you previously imported. The current in-app disconnect control does not revoke Bearing’s authorization at Google. To reliably stop future Google API access, remove Bearing’s access in your Google Account settings. To request deletion of Bearing’s cached copies, use account deletion or contact us. Imported tasks are ordinary Bearing content and remain until deleted with the account or in response to an applicable deletion request.

Payments and financial stakes

When you save a payment method, Stripe’s Payment Element collects and transmits the payment credentials directly to Stripe. Bearing’s servers receive a Stripe SetupIntent result and provider references, not your full card number or card security code. Bearing stores the Stripe customer and payment-method identifiers and limited display information such as card brand, last four digits, expiration month and year, default status, and creation time. Stripe separately processes and retains the payment credentials and the Customer, SetupIntent, PaymentMethod, PaymentIntent, charge, refund, dispute, and related records under its own privacy notice and legal obligations.

For a financial stake, Bearing stores the linked commitment, amount and currency, authorization and creation times, grace-period deadline, stake outcome, payment or refund amount and status, Stripe transaction identifier, and an idempotency key used to avoid duplicate charges. Bearing currently also stores the full Stripe PaymentIntent or Refund object returned to the charge or refund service in the corresponding transaction record. That transaction record is synchronized to the local Bearing database on devices signed in to your account. Bearing separately stores each verified Stripe webhook event it receives in a server-only inbox before processing it. Depending on the event, these Stripe objects can include provider and Bearing account or stake identifiers, amounts, currency, status and timestamps, failure or dispute details, limited payment-method or billing information, and other fields contained in the provider object. They do not include the full card number or security code.

Bearing uses this information to save a payment method for future off-session stake charges; obtain and record your stake authorization; apply the commitment, grace-period, free-pass, charge, and refund rules shown in the Services; reconcile Stripe events; show stake and transaction history; prevent duplicate processing; answer payment disputes; and meet accounting, tax, legal, and enforcement obligations. Bearing does not currently use payment-method details, monetary amounts, or provider transaction records for advertising, credit or service eligibility, personalized risk scoring, or AI processing. As described in Analytics, diagnostics, notifications, and website tracking, Bearing does record limited payment-method setup and stake-feature events without payment-method details or monetary amounts to understand whether those product flows work. Stripe may independently use payment and device information for payment processing, security, fraud prevention, legal compliance, and other purposes described in Stripe’s privacy notice.

Stake evaluation is automated and rules-based, not an AI decision. Bearing evaluates the evidence and commitment rule you configured, applies the stated grace period, and may submit an authorized off-session charge if a staked commitment remains failed. A recurring commitment template can create later staked commitments under the authorization recorded for that template. You can review the commitment and stake outcome and available transaction details in the app and contact us if you believe the evidence, outcome, or charge is wrong.

Archiving a related task or commitment does not delete its stake outcome, and stake history remains visible in the app. Bearing has not adopted a fixed financial-record retention schedule. Under the current database design, deleting your Bearing account removes the account-linked payment-method, template-stake, stake, and transaction rows and clears the synchronized local database. The current deletion flow does not delete the corresponding Stripe Customer or Stripe’s transaction history, and server-side webhook-event records are not linked to the account-deletion cascade. Those provider and webhook records may therefore remain under the retention criteria and lawful exceptions described in Retention. Bearing does not currently provide a self-service export; you may request access to applicable payment and stake information as described in Your choices and rights.

Screentime and accountable browsing

Screen-time features are optional. Depending on your platform, Bearing may ask for access to app-usage, screen-activity, accessibility, browser-extension, or Apple Screen Time controls. On Android, Bearing reads the list of launchable apps on the device to display an app picker. That list is processed on the device, and Bearing syncs an app to your account only when you select it. Apple Screen Time supplies opaque authorization tokens for the apps or categories you select rather than a readable installed-app inventory.

For an app or website you add, Bearing stores its display name and platform identifier—such as an Android package name or domain—with server-managed field-level encryption. Bearing also stores a keyed fingerprint derived from the identifier so sessions can be matched to your selections without placing the observed identifier in plaintext session records. Fingerprints are not encryption and are not intended for display or recovery of the original value. Category names are encrypted as task names. Operational records such as fingerprints, app type, relationships, rules, device identifiers, timestamps, session status, source and end reason, and validation results remain readable to Bearing’s backend. Apple-issued Screen Time tokens are opaque but are not encrypted with Bearing’s field-level encryption.

Bearing stores session-level records for tracked app or website use, including start and end times. On Android, operating-system foreground and background events are processed on the device to create these sessions; the complete underlying operating-system event stream is not uploaded as browsing or app history. Raw app identifiers and bounded retry, session-ledger, and audit records may remain locally on the device. Diagnostic information sent in connection with an error or support investigation may also include recent screen-time identifiers or debugging context.

The accountable browser processes the current URL on the device to determine whether its host matches a website you chose to track. Ordinary synchronized session history uses fingerprints and does not intentionally include page paths, URL query strings, search terms, page contents, page titles, or video identifiers. The browser separately keeps the last full URL on the device so it can reopen the previous page. If you deliberately create a website exception—such as an allowed YouTube channel or video, subreddit, server, group, exact URL, or URL prefix—Bearing may sync the encrypted URL, display name, subtitle, title, channel name, and related metadata, together with fingerprints used for matching. These deliberate exceptions are not ordinary browsing history.

Bearing uses session and threshold records to show your activity, calculate usage, enforce blocking rules, and evaluate the screen-time commitments you configure. It does not use that activity history for advertising or profile-based recommendations. Bearing does not send session history, usage durations, launches, page visits, or browsing content to AI providers. If you ask the optional assistant to add or organize screen-time websites, apps, or categories, Bearing may send selected identifiers and category names to Anthropic. The assistant is instructed to ask for confirmation before reorganizing existing apps, but this in-chat instruction is not a separate stored permission and is not currently enforced for every screen-time tool flow.

Bearing’s browser extensions use information received through browser and Google APIs only to provide or improve their disclosed user-facing purpose of tracking and limiting website use for your Bearing commitments, to maintain security, or as the law permits. Bearing’s use of information received from Google APIs adheres to the Chrome Web Store User Data Policy, including the Limited Use requirements.

Screen-time commitment evaluation is automated and rules-based, not an AI decision. Bearing compares the recorded sessions or platform threshold events with the limits, schedules, and commitment rules you chose. The result can automatically mark a commitment fulfilled or failed, activate or release blocking, and affect a financial stake. If a staked commitment remains failed after its grace period, Bearing may charge the stake according to the terms shown when you created it; an available free pass or a corrected result may prevent a charge as the Services permit. You can review commitment and stake status in the app and contact us if you believe the underlying data or result is wrong.

You can stop future collection by disabling the feature, disconnecting a device or extension, or revoking the relevant permission in Bearing, your browser, or device settings. Doing so may prevent Bearing from validating a commitment or enforcing a block. Revoking access does not automatically delete sessions or configuration already synchronized to your account; use account deletion or contact us to request deletion.

AI features

AI features are optional, and you can use the non-AI parts of Bearing without using them. Opening the AI chat connects to Bearing’s Cloudflare service; sending a message starts Anthropic processing; and choosing an AI action such as generating a task image starts the processing described below. The current app does not have a separate stored first-use permission screen or a setting that disables all AI processing. You can stop future AI processing by not using those features, clear the ongoing chat as described below, or delete your account. Do not include information you do not want processed by the providers described here.

Each assistant request sends Anthropic your new message and the existing ongoing conversation, including prior messages, tool calls, tool results, and generated or selected media information in that history. Bearing also automatically supplies your time zone; counts of active commitments, routine templates, and journal templates; and identifiers and names for items created or changed during the current AI session. Based on what you ask, the assistant may call a Bearing tool and receive additional data without a separate confirmation for each record. That data can include task-list and task names and relationships; selected task descriptions and other task fields; routine, journal, calendar, and commitment-template content; and selected screen-time app or website identifiers and category names. Calendar information is available to the assistant only after it has become ordinary Bearing task or template content; the assistant does not query the connected-calendar event cache directly. Current AI tools do not read completed journal entries, screen-time session or browsing history, health or fitness samples, current coordinates, payment-method information, payment records, or financial-stake records. A general description of Bearing’s stake features and your active-commitment count can still appear in AI context.

Cloudflare hosts the AI service and stores one ongoing per-user conversation in a Durable Object so it can persist and resume. Anthropic processes the system instructions, conversation, selected tool definitions, session context, and responses. Anthropic states that commercial API inputs and outputs are not used for model training by default and are normally deleted from its backend within 30 days, subject to different contractual terms and longer retention for safety-policy enforcement or legal requirements. Bearing has not yet completed a production review of every AI provider’s contractual, dashboard, feedback, retention, training, and regional settings.

When you request an AI-generated task image, Bearing decrypts the task name and description, combines them with any generation instructions you provide, and sends the resulting prompt to fal.ai. fal.ai currently stores API input and output payloads for 30 days by default; Bearing’s current integration does not disable that storage. Bearing downloads the generated image to Supabase Storage and saves generation metadata with the task-photo record, including the full prompt, prompt summary, generation mode, user goal, provider, model, file type, and image-size setting.

Web-image search is a separate user-initiated task-photo feature. After you select Search Web, Bearing derives a query from the task name and the beginning of its description and sends it to Serper, which returns Google image-search results. Bearing does not intentionally save an unselected web-image query or its result list in the application database, although Serper, hosting logs, and the image or thumbnail hosts may process requests under their own retention practices. If the assistant searches YouTube, the model creates a query from the conversation and task context. Bearing sends it to the Google YouTube Data API; the query and returned video identifiers, titles, channels, descriptions, thumbnails, dates, and URLs become tool results in the ongoing AI conversation. Bearing’s current application and API diagnostic logs also record the raw YouTube query. Only a video you choose to attach is saved as the task’s encrypted video URL outside the conversation and logs.

The assistant may suggest or prepare actions, but client-side app controls execute most changes. It cannot create a financial stake; it can only prefill a commitment form that you review and submit. Bearing does not currently use AI output to make legal or similarly significant decisions about you. Bearing does not routinely have a person review prompts, responses, or images. Authorized Bearing or provider personnel may nevertheless access limited information when reasonably necessary for support, security, abuse prevention, legal compliance, or the other purposes described in this policy.

The chat menu’s Clear conversation control deletes the message history for Bearing’s single ongoing Cloudflare conversation; Bearing does not offer per-message deletion or a list of separately deletable conversations. Account deletion also clears that Cloudflare conversation. Removing a generated task image deletes its Bearing task-photo row and attempts to delete Bearing’s Supabase Storage copy, but provider copies, logs, or an orphaned storage object may remain under the retention and deletion rules described in this policy.

Task photos and external media

Photos uploaded from your device and images generated through fal.ai are stored in Supabase Storage at a public object URL containing your account and task identifiers. The URL is difficult to guess, but anyone who obtains it can access the file without signing in. The database record and app access controls do not make that public object private. Selected external image URLs remain hosted by the third-party image source; viewing them contacts that source.

Bearing does not currently strip embedded metadata from every uploaded image. Images wider than the resize limit are re-encoded, which ordinarily removes metadata, but smaller images, GIFs, and some other files can be uploaded unchanged and may retain camera, device, timestamp, or GPS metadata. The storage filename can also include a sanitized form of the original filename. Do not upload a task photo that contains information or metadata you would not want accessible through its URL.

You can remove an individual uploaded, selected, or generated task photo in the app. For files in Bearing’s Storage bucket, Bearing deletes the database record and then makes a best-effort attempt to remove the storage object; a failed object deletion can leave the file at its existing public URL. Removing an externally hosted image from Bearing does not delete it from the source website, and deleting Bearing’s copy does not necessarily delete fal.ai’s request payloads or temporary media immediately.

Health and fitness information

Fitness features are optional and require the relevant device permission or connection. Bearing currently requests permission to read only step-count and heart-rate records from Apple HealthKit and Android Health Connect. Bearing does not currently request permission to write to, or write records back to, either health store. Bearing may also receive steps or heart rate from supported phone or wearable sensors and from a camera-based measurement you initiate.

Bearing synchronizes individual step and heart-rate samples to its local synchronized database and backend. A sample can include the value, observed, start, and end times, provider and source, source-device information, and identifiers used to prevent duplicate records. Bearing also derives 30-second records containing step totals or heart-rate sample counts, minimum and maximum heart rate, and the number of seconds at configured heart-rate thresholds. These health values and summaries do not currently receive Bearing’s additional field-level encryption, although they receive the transport, database, access-control, and other protections described in Storage, security, and international transfers.

When you initiate a camera-based heart-rate measurement, camera frames are analyzed in memory on your device. Bearing does not save or upload photos or video from the measurement. Temporary color-channel samples are discarded after processing; the calculated heart-rate observations are converted into the heart-rate summaries described above and synchronized to Bearing.

If you enable sunrise and sunset display, Bearing asks the device for its current location and calculates the sun times on the device. Bearing does not request high-accuracy mode for this calculation, but the precision returned is controlled by your device and may still be precise. The coordinates are held temporarily in app memory and are not saved to your account, synchronized to Bearing’s backend, or used to create location history.

We use health and fitness information to show your progress, evaluate the fitness commitments and unlock rules you configure, determine the status of related financial stakes, and maintain the sync and audit records needed for those functions. Fitness evaluation is automated and rules-based, not an AI decision: Bearing compares the recorded step or heart-rate evidence with the thresholds, periods, and commitment rules you chose. A result can mark a commitment fulfilled or failed, unlock or keep restricted a feature, and affect whether a financial stake is charged. You can review the result in the app and contact us if you believe the data or result is wrong.

Bearing does not send health samples or camera-measurement results to AI providers. We do not sell health or location information or use it for marketing, advertising, product analytics, or product experimentation. Operational and diagnostic records may include connection state, permission state, sample or bucket counts, sync results, errors, and, when measurement diagnostics are enabled, calculated heart-rate values and signal statistics. Sentry may process those diagnostics when remote diagnostic logging is enabled. PostHog does not intentionally receive health samples, heart-rate results, or coordinates.

Bearing discloses synchronized health information to Supabase and PowerSync to store, secure, and synchronize the feature. Apple HealthKit and Android Health Connect are sources you choose to connect; Bearing does not currently write the synchronized copy back to them. Bearing may disclose the limited diagnostics described above to Sentry and may disclose information to professional or legal recipients in the circumstances described in When we disclose information. We do not allow a third party to collect consumer health data through Bearing over time across unrelated websites or online services.

For people covered by a consumer-health-data law, this section is also Bearing’s Consumer Health Data Privacy Notice. It describes the health-data categories, sources, processing, purposes, and recipient categories currently used by Bearing. We will not add a health-data category, recipient, or purpose where applicable law requires affirmative consent without first updating the notice and obtaining that consent. You can stop future collection by disconnecting the integration or revoking the permission in Bearing or your device settings. You can also exercise the health-data rights described in Your choices and rights.

Analytics, diagnostics, notifications, and website tracking

PostHog product analytics is currently enabled in configured production builds without a country or region gate. It begins with an anonymous analytics identifier and, after sign-in, Bearing identifies the analytics profile using your Bearing account identifier. Bearing’s app-defined events describe app opens, normalized screen views, authentication and feature-setup outcomes, commitment and stake-creation funnels without monetary amounts, bucketed quick-tracking and AI-message measurements, and limited AI tool outcomes. On supported native platforms, the PostHog SDK also records application-lifecycle events and SDK-supplied technical properties. Bearing’s analytics boundary is designed to reject free-form content and properties named for health data, websites, contact details, credentials, or encrypted values. These controls reduce risk but do not replace review of new analytics events. PostHog session replay is disabled.

We use PostHog only to understand product use and improve the Services. We do not use PostHog data for advertising, ad targeting, or cross-context behavioral advertising, and we do not sell it. If that practice changes, we will update this policy and provide any notice, consent, or choice required before the new use begins.

In the web version of the Bearing app, the current PostHog SDK stores analytics, device, distinct, and session identifiers in first-party browser local storage and a first-party cookie so it can recognize a browser and maintain analytics continuity. The SDK’s current default cookie lifetime is up to 365 days, although the information may be removed sooner if you clear browser data or Bearing resets the analytics identity. The native mobile apps use app or device storage rather than browser cookies for these identifiers.

Sentry is currently enabled in configured production builds for error and performance monitoring. After sign-in, Bearing associates Sentry events with your Bearing account identifier and email address. Depending on the event, Sentry may receive error messages, stack traces, console.error details, page and file URLs, breadcrumbs, performance spans, release and environment information, device, browser, operating-system and request context, and diagnostic tags or details supplied by app and native components. The app does not enable Sentry’s option for automatic collection of default personal information, but communications with Sentry necessarily involve network requests, and source-IP handling also depends on Sentry and project settings. Bearing has not yet completed a production-dashboard verification of IP storage and data-scrubbing settings.

Ordinary Sentry session replay is disabled. When an error occurs, the current production configuration samples one percent of eligible error sessions for replay. Replay is configured to mask all text and input values and block media before transmission. Masking does not guarantee that personal information cannot appear elsewhere in an error, URL, breadcrumb, console error, performance trace, or manually attached diagnostic field.

The current app does not provide a user-facing control to opt out of PostHog analytics or Sentry diagnostics. Notification settings do not disable either service. Where applicable law requires consent, an objection mechanism, or another choice for these activities, Bearing will implement the required control before relying on the affected processing.

OneSignal supports Bearing’s push notifications and daily-summary emails. When initialized and associated with a signed-in account, OneSignal can receive your Bearing account identifier, a OneSignal user and subscription identifier, push token, email address for enabled daily summaries, permission and subscription status, timestamps, app version, platform, device model, language, time zone, country derived from network information, IP address where processed under OneSignal’s settings, and other SDK technical information. Notification requests also contain delivery and routing data and the message itself. Depending on the reminder you enable, that message can reveal task or routine names, commitment status or results, times, durations, quantities, screentime or fitness-sync status, and related deep-link identifiers. Notification previews may therefore reveal sensitive information to OneSignal, Apple or Google push infrastructure, and anyone who can view your device’s lock screen.

Current notifications are transactional, user-requested product reminders, summaries, results, warnings, synchronization messages, and tests; they are not promotional. You can opt a device out of OneSignal push delivery and disable or pause notification categories in Settings or device settings. Daily-summary email has a separate Settings control and unsubscribe link. Turning delivery off does not, by itself, delete previously transmitted messages, delivery records, or OneSignal’s existing user or subscription record. If Bearing later sends promotional notifications, we will separate them from transactional settings and provide any notice, consent, and opt-out required by law.

The public landing website does not currently run PostHog, Sentry, OneSignal, an advertising pixel, or another analytics script and does not set an advertising or analytics cookie. It uses local storage only to remember whether a site notice was dismissed, loads fonts from Google, and produces ordinary hosting and content-delivery logs. Google and the hosting provider receive the network and device information ordinarily included with those requests. This description concerns the public landing website; the web version of the signed-in Bearing app uses the services described above.

When we disclose information

We disclose information only as needed for the purposes described in this policy:

We may also disclose information in connection with a merger, financing, acquisition, reorganization, bankruptcy, or sale of assets. We will not disclose more information than reasonably necessary for the transaction, and the recipient will be subject to confidentiality or applicable legal obligations.

We do not sell personal information, including for money or other valuable consideration, and we do not share personal information for cross-context behavioral advertising. We do not use advertising SDKs or retargeting pixels, upload user lists to advertising platforms, operate advertising offer walls, or disclose personal information for affiliate advertising. Other than the recipients and circumstances described in this policy, we do not currently exchange personal information with business partners. We also do not knowingly sell or share personal information of people under 16 for those purposes.

Local storage, cookies, and similar technologies

The Services use authentication storage, local databases, device preferences, and similar technologies to keep you signed in, support offline use, remember preferences, prevent abuse, and measure product use. The landing website uses local storage for the limited preference described above and loads web fonts from Google, but does not currently use analytics or advertising cookies. The web version of the Bearing app uses the first-party PostHog local-storage entry and cookie described above; these are analytics technologies, not advertising cookies. The mobile apps use PostHog identifiers in app or device storage. Our infrastructure may use other identifiers or similar technologies to provide security and requested functionality.

We do not use advertising cookies. Browser settings can restrict cookies or local storage, but doing so may prevent authentication, synchronization, or preferences from working correctly.

The Services do not currently read or act on browser “Do Not Track” or Global Privacy Control signals. Bearing does not sell or share personal information for cross-context behavioral advertising, so there is currently no sale, sharing, or targeted-advertising opt-out for those signals to perform. If our practices change, we will update this policy and implement legally required preference signals before the new practice begins.

Storage, security, and international transfers

Bearing stores cloud data primarily through Supabase and feature-specific providers. PowerSync copies synchronized information to a local SQLite database on devices where you use the app. On the web, local app data can also be kept in browser-managed database and storage facilities. AI chat history is stored in a per-user Cloudflare Durable Object. The public-URL and metadata limitations for task photos are described in Task photos and external media.

We use administrative, technical, and organizational safeguards designed to protect information. These include transport encryption, access controls, provider authentication, row-level database authorization, secure token handling, logging controls, and encryption of selected sensitive fields at rest using server-managed keys. On supported native devices, Bearing stores the authentication session and issued content-encryption key through operating-system secure storage. The local database as a whole is not separately encrypted by Bearing; protected fields remain encrypted within it, while other synchronized fields rely on platform and device-storage protections. This is not end-to-end encryption, our server can decrypt protected fields for limited product operations, and not every field, local record, backup, or file is covered by field-level encryption. No system can guarantee absolute security.

Our providers may process information in the United States and other countries. Those countries may have different data-protection laws from your location. You may contact us for information about safeguards relevant to an international transfer of your information.

Retention

Most account, profile, user-content, session-history, calendar, derived-fitness, stake, and other feature records are retained for the life of your active account because they provide your history, settings, synchronization, and requested features. Bearing does not currently close inactive accounts or automatically expire most of those records after a fixed period. Information that you remove through an available permanent-deletion control is handled as described below; archiving is not deletion.

Where a fixed period is not stated, we use the following criteria to determine how long information remains necessary: whether the account or feature remains active; whether the information continues to provide history, synchronization, commitment validation, stake correction, support, security, or fraud-prevention functions; whether you can delete it yourself; its sensitivity and volume; provider capabilities; and legal, accounting, payment, dispute, audit, and enforcement obligations. We are developing a more specific internal retention schedule. These criteria do not authorize us to retain identifiable information after its disclosed purpose and any legal obligation end.

Screen-time session records are currently retained at session level under these general criteria; Bearing does not currently replace them with only hourly or daily aggregates or automatically delete them after a fixed screen-time-specific period. Device-local screen-time retry, ledger, and audit records use bounded files but may persist until overwritten or local app data is cleared. We intend to adopt more specific retention periods as our operations mature and will update this policy when we do.

Bearing has not adopted a fixed retention period for payment methods, template stake authorizations, stake outcomes, transaction records, full Stripe response objects, or webhook events. Archiving a task does not delete its stake or transaction history. Account deletion currently removes the account-linked structured payment, authorization, stake, and transaction rows and their synchronized local copies, but it does not call Stripe’s customer-deletion API and does not delete the server-only webhook inbox. Stripe and Bearing’s webhook records may remain for payment processing, refunds and disputes, accounting or tax support, security, audit, legal compliance, or establishing or defending claims. Bearing is reviewing which minimal records are necessary for each purpose and does not intend this statement to authorize indefinite retention after the purpose and any legal obligation end.

Bearing’s current fitness sync process prunes individual raw health samples from the synchronized local database after three days, and a backend cleanup is scheduled to delete raw health samples older than 30 days. Cleanup may occur later on a device that has been offline or unable to complete synchronization. Derived 30-second step and heart-rate summaries are marked non-recent after 14 days and stop synchronizing back to devices, but they are not currently deleted from the backend on a fixed fitness-specific schedule. Account deletion and the legal or operational exceptions below still apply.

Calendar metadata, synchronized event cache rows, synchronization state, imported-event mappings, and encrypted OAuth access and refresh tokens do not currently have a fixed calendar-specific expiration period. Disabling a calendar does not delete its existing cache or reliably delete or revoke the stored token. Account deletion is the current reliable self-service path for deleting account-associated calendar records from Bearing, subject to the exceptions described below; you may also revoke Bearing in your Google Account and contact us with a deletion request.

The single ongoing AI conversation remains in Cloudflare’s Durable Object until you clear it or delete your account. Uploaded and generated task media and Bearing’s associated generation metadata do not expire automatically; they remain until you remove the photo or delete the account, although failed object cleanup can leave an untracked storage copy. Anthropic’s standard commercial API retention and fal.ai’s current default input/output retention are described in AI features. Bearing does not yet have an approved retention period for encrypted AI routing summaries, usage metrics, AI and search diagnostics, generated-image metadata, Serper processing, or provider and hosting logs.

Bearing has not yet adopted fixed retention periods for PostHog analytics or Sentry diagnostic records or verified the production projects’ retention, IP-storage, and deletion settings. OneSignal states that records for messages sent through its API are typically deleted about 30 days after delivery, while user, subscription, and other records can remain until they are deleted through OneSignal or Bearing’s OneSignal provider project is deleted. Turning off a notification does not delete those records. EmailJS states that request activity and metadata for an active account can be retained for 30 days; the delivered support message and our reply can remain in the connected email systems under the support criteria below. Provider practices and lawful exceptions may change, so Bearing must also maintain its own provider settings and deletion procedures.

Bearing has not yet adopted fixed periods for authentication, security, API, hosting, encryption-key audit, or ordinary server logs, and not every production provider’s log and backup settings have been verified. We retain or direct providers to retain those records only while reasonably necessary to operate and secure the Services, diagnose failures, prevent abuse, investigate incidents, comply with law, or establish or defend claims. We are reviewing those settings as part of the retention schedule described above.

We may retain support messages, attachments, associated contact and account information, and our replies for as long as reasonably necessary to answer the request, maintain useful support history, investigate problems, resolve disputes, protect the Services, and comply with legal obligations. Copies may remain for a limited period in email-system or provider backups. The in-app contact form logs delivery success or an error but is not designed to place the message body in Bearing’s application logs.

Archiving is not deletion. Most tasks, completed journal entries, and journal, routine, or calendar templates cannot currently be permanently deleted individually through the app; archived records remain associated with your account and are retained under this policy. You can remove individual task photos, discard an unfinished journal draft, and clear the message history for the single ongoing AI conversation. Bearing does not provide per-message AI deletion or separate saved conversations. To delete the remaining account-associated content, use account deletion or contact us with a deletion request. Legal or operational exceptions described in this policy may still apply.

When you delete your account through the app, the automated flow deletes the authentication account, database records configured to follow account deletion, persistent AI chat history, and the app’s synchronized local database. A deletion request does not necessarily erase every provider, backup, security, transaction, webhook, or audit record immediately. Bearing does not currently maintain a separate offline production backup program, and the aging periods for all provider-managed backups have not yet been verified. Some information may remain only when and for as long as retention is reasonably necessary for security, fraud prevention, accounting, payment disputes, legal compliance, or establishing or defending claims. We may retain de-identified information that can no longer reasonably be linked to you.

Your choices and rights

Depending on where you live, you may have the right to request access to, correction of, a copy of, or deletion of personal information; to object to or restrict certain processing; to withdraw consent; or to appeal our response. You may also have the right to complain to your local data-protection authority. We will not discriminate against you for exercising a privacy right.

You can manage many choices directly:

• edit tasks, journals, schedules, preferences, and other content in the app;
• disable screen-time features, disconnect a participating device or extension, or revoke related permissions, understanding that already synchronized records remain until deleted;
• disable a connected calendar, revoke Bearing’s Google authorization in your Google Account settings, or disconnect a fitness integration, understanding that revocation stops future provider access but does not by itself delete information already synchronized to Bearing;
• revoke camera, health, location, notification, or other permissions in device settings;
• turn off or pause optional daily-summary emails in Settings or use the unsubscribe link in a daily-summary email;
• opt out of push notifications in Bearing or your device settings;
• clear the ongoing AI conversation from the chat menu, or stop future AI transfers by not using AI chat or AI image generation;
• review your stake history in the app and contact us to question a stake outcome or transaction; and
• delete your account from Settings in the app.

Bearing does not currently offer a switch to opt out of PostHog product analytics or Sentry diagnostics. Notification controls do not affect those services. You may contact us to object to or request restriction of this processing where applicable law provides that right; we will evaluate the request and any legal or operational basis for continuing the processing.

See our account deletion instructions for the in-app flow and an email option if you cannot access your account. To make another privacy request, email matt@deloreanhovercraft.com. We may need to verify your identity before fulfilling a request. An authorized agent may submit a request where applicable law permits, but we may require evidence of the agent’s authority and direct verification with you.

Bearing does not currently provide an automated self-service account export. Where applicable law gives you a right to access or receive a portable copy of your personal information, you may request it by email using the address above. We will verify and respond to the request as applicable law requires, subject to lawful exceptions.

For health information, you may also request a list of the categories collected, sources, purposes, and recipient categories; confirm whether Bearing is collecting, sharing, or selling your health information; access or request correction of that information; withdraw consent for future collection or sharing where consent applies; and request deletion, including deletion from archives and backups where applicable law requires it, subject to lawful exceptions. Revoking a device permission stops future access by Bearing but does not automatically delete information already synchronized to Bearing; use the account-deletion flow or contact us for deletion.

If we deny a privacy request that applicable law allows you to appeal, you may appeal by replying to our decision or emailing matt@deloreanhovercraft.com with the subject “Privacy Appeal.” We will review the appeal and provide the result and any available method for contacting the relevant regulator or attorney general as applicable law requires.

United States privacy disclosures

The table in Information we collect describes the categories of personal information we collect and their sources. The sections How we use information and When we disclose information describe our business purposes and the recipient categories to which information is disclosed. Depending on the law that applies to you, you may have the rights described above, including rights concerning sensitive or consumer health information.

Bearing does not use or disclose sensitive personal information to infer characteristics about you for advertising. We use it only to provide requested features, maintain security, process payments, comply with law, and for other purposes permitted without a right to limit under applicable law.

Children

The Services are designed and marketed for adults and are not directed to children under 13. We do not intentionally market Bearing to minors. We do not currently ask for a date of birth or use automated age verification at general account signup. Bearing does not offer parent-managed child accounts, and parents or guardians should not create Bearing accounts for children.

Financial-stake and payment features are intended only for people who are at least 18 and otherwise legally able to enter the applicable transaction. We do not knowingly collect personal information directly from a child under 13, or from a person otherwise below the minimum age at which they may lawfully use the Services without required authorization. If we learn that such a person has provided personal information, we will take reasonable steps to stop further collection and restrict or close the account, delete the information as required, and retain only information that we are legally permitted or required to keep. If we learn that a minor is using financial-stake or payment features, we may restrict those features and take appropriate steps concerning pending transactions and legally required records.

A parent or guardian who believes a child has used Bearing or provided personal information improperly may contact us at the address below. We may request limited information needed to verify the requester’s identity and authority before disclosing or deleting account information.

Changes to this policy

We may update this policy as our Services, providers, or legal obligations change. We will update the date at the top for each revision. If a change materially expands the personal information we collect, how we use or disclose it, or reduces a choice or right described here, we intend to notify account holders by email at least 14 days before the change takes effect when reasonably practicable. We may give shorter or immediate notice when a change is required for security, fraud prevention, legal compliance, or another urgent reason. We will request new consent before the change when applicable law requires it.

We do not plan to maintain a public archive of prior versions. We retain internal copies of policies that were in effect so we can identify the terms that applied at a given time. Material changes will apply prospectively unless the law permits or requires otherwise.

Contact us

Questions, requests, or complaints can be sent to:

• Matthew Riese
• Bearing Time Management
• matt@deloreanhovercraft.com
• 3251 Hidden Valley Dr, Santa Rosa, CA 95404, United States