Cookie Policy

This Cookie Policy explains how Coul's website and web application store information on, or read information from, a browser or device. It covers HTTP cookies and similar technologies such as localStorage, sessionStorage, IndexedDB, Cache Storage, service-worker caches, pixels, SDKs, and device identifiers. The Privacy Policy separately explains how Coul processes personal data after collection.

The inventory below reflects a review of the Coul web source available on July 23, 2026. That review did not find code that sets a Coul first-party HTTP cookie, sends a Set-Cookie response, or loads an advertising pixel. It did find the browser storage described below, Google reCAPTCHA Enterprise on the enabled public waitlist, and a consent-gated PostHog product-analytics SDK. A deployed build, hosting layer, tag manager, payment page, social provider, embedded resource, or later release can differ from source, so this snapshot is not a substitute for a production network and device-storage audit.

This policy does not describe server logs, application databases, vector stores, uploaded-media storage, or provider records as cookies merely because they contain identifiers. Those practices belong in the Privacy Policy, although a browser identifier can connect a device to a server-side record.

An HTTP cookie is a small value a website asks a browser to store and return with later requests. A cookie can be first party, meaning associated with the service you visit, or third party, meaning associated with another service loaded or visited through that experience. A session cookie normally expires when the browser session ends; a persistent cookie remains until its configured expiry or deletion.

Other browser technologies can perform similar storage or access functions without using an HTTP cookie. localStorage can persist values after a tab or browser closes; sessionStorage is generally scoped to a tab session; IndexedDB stores structured data; Cache Storage keeps response or asset copies; and a service worker can support offline or performance behavior. Privacy rules in some regions apply to these technologies as well as conventional cookies.

Coul groups device storage by purpose. A technology can have more than one purpose; when it does, Coul must apply the strictest relevant consent rule and explain each purpose. A category label does not make a technology legally exempt. The exemption analysis depends on the exact purpose, configuration, jurisdiction, and whether the technology is essential to provide a service the person requested.

• Strictly necessary: sign-in and session security, OAuth state and callback handling, fraud or security controls, a user's consent record, and storage essential to deliver a feature the user expressly requests. These cannot be switched off through the optional-category control, but Coul must still minimize and disclose them.

• Preferences and functional: optional convenience or customization beyond what is essential for a requested service. In the reviewed build this category gates theme persistence, optional offline/PWA storage, session and persistent performance caches, and the optional cache service workers described below. These start off unless a current choice permits them.

• Analytics: optional measurement of visits, interactions, campaigns, diagnostics, or product usage across a site or over time. In the reviewed build this category gates the first-party local error-logs entry and PostHog page and explicit product-usage events. The SDK is configured without session replay, autocapture, surveys, automatic client-exception capture, web-performance capture, or feature-flag requests. Product records and aggregate server metrics are governed separately and are not automatically device-access technologies.

• Advertising: pixels, identifiers, audience matching, retargeting, attribution, or cross-context behavioral advertising. The reviewed source does not currently enable these technologies, and Coul states in its Privacy Policy that it does not sell personal data or share it for cross-context behavioral advertising.

None were found in the reviewed application source. Coul's current sign-in implementation uses first-party browser storage instead of a Coul-set authentication cookie. Accordingly, this policy does not invent cookie names, providers, or expiry periods that the code does not use.

A hosting provider, reverse proxy, security service, experiment platform, tag manager, or production-only integration could still set a cookie outside the reviewed source. Before launch and after infrastructure changes, Coul must inspect response headers, requests, frames, scripts, service workers, and device storage in representative browsers and regions. Any discovered technology must be classified, gated where required, added here with its real provider and duration, and removed if unnecessary.

The current web implementation uses the following first-party keys for sign-in, connection security, and privacy choices. Values can be personal data when they identify an account, social connection attempt, device choice, or security event.

• coul.auth.session:v2 — localStorage; contains Coul access and refresh credentials plus bounded account/session information. It persists until logout, explicit cleanup, browser clearing, account action, or replacement. The server-side refresh credential is configured for a limited period, currently generally 30 days and configurable within the reviewed 30–60 day range, but server expiry does not itself erase a stale browser copy.

• coul.auth.cleanup:v1 — localStorage; a timestamp and nonce used to coordinate sensitive cleanup. The source does not apply a standalone time expiry, so it remains until replaced or browser data is cleared.

• coul.oauth.attempt:v1:<state> — sessionStorage; OAuth state, proof-key and related connection-attempt data; consumed or rejected after approximately 10 minutes and otherwise normally removed when the tab session ends.

• coul.oauth.callback:v1 — sessionStorage; a bounded social-provider callback result; consumed or treated as stale after approximately 10 minutes and otherwise normally removed when the tab session ends.

• coul.consent:v1 — localStorage; optional-category choices, policy and inventory versions, privacy-signal status, save time, expiry time, and a universal prior-choice rule. It expires after 180 days, earlier if the policy or inventory version changes, or when you clear site data. It contains no advertising identifier and is treated as strictly necessary to remember the choice.

The source contains first-party localStorage for product continuity and offline or diagnostic behavior. Some entries appear only after a person opens or uses the related feature. Unless a duration is stated below, the reviewed code has no uniform time-based expiry; data can remain until overwritten, a feature-specific action removes it, browser/site data is cleared, or Coul implements the cleanup control required below.

• futuristic-ai-workspace:v1:<project> — node-canvas data such as graph state, viewport, and selected node; localStorage; currently time-indefinite for continuity of the requested workspace feature.

• coul:analyze-profiles:v1:<encoded-account-id> — account-scoped social-profile analysis workspace data; localStorage; verified after each write and currently time-indefinite. The earlier social_profiles_v1.0.0 and social_profiles_history_v1.0.0 keys are legacy and are no longer read by the Analyze workspace.

• detail-<contentId> and creation-<timestamp> — content-modal drafts; localStorage; currently time-indefinite. Abandoned creation keys can accumulate until a cleanup control or browser clearing removes them.

• theme-preference — display choice; localStorage; written and read only with preferences consent, until changed, reset, consent is withdrawn, or browser clearing, when the relevant calendar theme feature is mounted.

• error-logs — client-side diagnostic records; localStorage; written only with analytics consent, limited to the latest 50 entries but not otherwise limited by time, and removed when analytics consent is rejected or withdrawn.

• PostHog runtime state — memory-only in the reviewed integration; pseudonymous device/session context lasts only for the current page runtime and is not written to ph_ localStorage or sessionStorage entries. Coul removes legacy ph_ entries before activation, identifies a signed-in person with the stable internal Coul user ID only, and does not attach an email or username.

• coul.posthog.consent — localStorage; the PostHog SDK's capture-preference marker. Coul's versioned coul.consent:v1 record remains the source of truth. The marker exists only while analytics consent is active and is removed on rejection or withdrawal. It contains no account contact details, prompt, caption, upload, or provider credential.

• offline-content and sync-<tag> — offline content or background-sync data; localStorage; read or written only with preferences consent and removed when that consent is rejected or withdrawn. In-memory fallback can continue for the current page without device persistence.

• cache_<dynamic key> — short-lived sessionStorage performance entries; read and written only with preferences consent, generally limited to the tab session and each entry's configured time-to-live, and removed when that consent is rejected or withdrawn.

The source also contains structured browser databases and Cache Storage paths. Availability in source does not prove that every visitor receives or activates them; the relevant feature, browser support, and service-worker registration matter.

• IndexedDB CalendarCache / entries — preferences-consent-gated performance cache with configured purposes and maximum ages: calendar data about 2 hours, content about 24 hours, media about 7 days, and optimization data about 30 days, subject to successful expiry checks and cleanup. Rejection or withdrawal stops reads and writes and requests deletion of the database.

• IndexedDB DataGridStorage / data — structured product persistence; no uniform expiry was found. Its actual keys and values depend on features that use the persistence layer.

• Cache Storage calendar-content-v1 — cached or synthetic calendar content used by offline/PWA code; preferences-consent gated, removed on rejection or withdrawal, and otherwise without a uniform time expiry in the reviewed source.

• Service-worker Cache Storage calendar-assets-v1 — application assets for performance/offline behavior; preferences-consent gated and removed on rejection or withdrawal, and otherwise without a uniform time expiry. The source contains registration and caching logic, but production activation must be verified.

Theme, drafts, client diagnostics, offline content, service-worker caches, data-grid persistence, and some performance systems are conditional in the source. Coul must test whether each is actually mounted, registered, and written in the deployed public, authenticated, onboarding, research, calendar, analytics, editor, and workflow routes before treating it as active or inactive.

For this build, Coul treats authentication, OAuth, consent, user-created canvas state, locally requested drafts, social-profile workspace persistence, and DataGridStorage as necessary or requested-service storage rather than optional preference storage. The optional gate instead covers theme persistence, offline/PWA storage, performance caches and cache service workers; local error diagnostics use the analytics gate. Coul must document and approve that classification per technology and region rather than classifying every product feature as necessary. If the deployed facts or local analysis do not support an exception, Coul must reclassify and gate the use before launch.

When you leave Coul for a provider page, that provider can set or read technologies on its own domain under its own notice and controls. Coul cannot read, delete, or guarantee the duration of another domain's cookies. Blocking them can affect the provider flow, but rejecting optional Coul categories does not itself clear a provider's existing off-site data.

• Google reCAPTCHA Enterprise — the enabled public waitlist loads Google's score-based abuse-prevention script and frame before an address can be submitted. Google receives the short-lived security token and associated browser/security signals under its own terms; Coul sends the token, registered site key, and expected action to Google Cloud for assessment. This is classified as strictly necessary for protecting the requested submission flow, not analytics or advertising.

• PostHog — when analytics consent is active, the browser sends scrubbed pageview and selected product-lifecycle events to https://us.i.posthog.com. Query strings and URL fragments are removed before sending; automatic UI text/click capture, replay, surveys, exceptions, performance capture, and feature-flag requests are disabled. PostHog can process pseudonymous identifiers and the stable internal Coul user ID under its service terms and data-processing arrangements.

• Social platforms — Meta properties, TikTok, X, and any later supported provider can use their own cookies or SDK storage when you visit their authorization domain or use their service. Coul's reviewed callback code stores its own short-lived state as described above; it does not make the provider's off-site cookies Coul first-party cookies.

• Stripe — a checkout or billing-portal redirect can allow Stripe to use its own necessary, security, fraud-prevention, preference, or other technologies on Stripe-controlled pages. The actual checkout configuration and Stripe notice at the time of payment control those provider-side details.

• Hosting, security, media, or content providers — if production infrastructure later injects scripts, headers, media, or frames, Coul must name the provider and technology here, verify its contract and transfer terms, and obtain prior consent whenever the use is non-essential.

On a browser without a current choice, Coul presents Reject all and Accept all with the same visual class, weight, and interaction cost, alongside Customize. Optional preferences, analytics, and advertising start off. Strictly necessary storage remains available because the service cannot reliably remember a choice, secure a sign-in, complete an OAuth request, or deliver a requested feature without the relevant storage.

Customize provides separate switches for preferences and functional storage, analytics, and advertising. Save choices applies only the selected categories. The manager writes the minimal coul.consent:v1 record with the posthog-product-analytics.2026-07-22 inventory version, exposes category state for code-level gating, dispatches a change event to active adapters, and asks again after 180 days or a policy- or inventory-version change. The current choice authorizes only the PostHog configuration and purposes described here; it does not authorize a later analytics or advertising vendor, a new identifier, or a materially changed purpose.

The current theme, optional offline/PWA, session and persistent performance-cache, cache-service-worker, local error-diagnostic, and PostHog paths consult the corresponding gate; the gate defaults to false before the React application mounts. PostHog is not initialized and sends no request before analytics consent. Every later optional script, pixel, SDK, iframe, service worker, identifier, or storage call must use the same fail-closed rule. Coul must test pre-consent network requests and storage writes, rejection, granular choice, withdrawal, expiration, version changes, failure to access localStorage, and browser privacy signals before launch.

Choose Cookie settings from the public site footer or the workspace Account settings at any time to reject all optional categories, accept them, or save granular choices. Withdrawal applies to future optional access from that browser. Coul must make withdrawal take effect without requiring account closure and without degrading a paid service beyond functionality that genuinely depends on the withdrawn technology.

Rejecting or withdrawing the current preferences category removes theme-preference, offline-content, sync-* and cache_* entries, deletes the named optional Cache Storage entries and CalendarCache database, and unregisters the identified optional cache service workers; the relevant read and write paths remain gated. Rejecting or withdrawing analytics stops capture, stops any recording defensively, resets the PostHog device and user identity, removes legacy ph_ and __ph_opt_in_out_ analytics storage and cookies, removes the SDK consent marker and error-logs, and stops new analytics persistence. Cleanup is best-effort when a browser blocks an API, and it does not erase necessary/requested-service storage or events PostHog lawfully received before withdrawal.

Withdrawing browser analytics consent applies prospectively. To request access to or deletion of analytics data already held by Coul or PostHog, use the separate Data Rights process so Coul can authenticate and coordinate the request. Browser controls can also delete Coul site data, block cookies, clear IndexedDB and caches, or use a private session, but doing so can sign you out, remove drafts and offline data, reset preferences, and cause the consent manager to ask again.

Account deletion and browser-site-data deletion are different. Clearing a browser does not delete account, upload, billing, social-platform, or back-end records. Deleting an account does not necessarily clear every copy stored in each browser you used. The Data Rights & Account Deletion page explains the coordinated request process.

The consent manager detects an enabled Global Privacy Control signal and conservatively keeps optional analytics and advertising off for that browser. Coul does not currently sell personal data or share it for cross-context behavioral advertising, but a covered business must treat GPC as a valid opt-out from sale or sharing where applicable. GPC can be device- or browser-specific, so a different browser may require its own signal or choice.

Coul also treats a recognized Do Not Track value as a privacy preference that keeps optional analytics and advertising off. Do Not Track is not a uniform statutory consent standard in every region; honoring it here is a product choice and does not replace any stronger signal or local right.

Coul uses a universal prior-choice approach: optional categories remain off before a choice rather than attempting location inference and showing weaker controls elsewhere. Local exemptions and definitions still vary. Nothing in this policy reduces rights under ePrivacy, PECR, the GDPR or UK GDPR, the CCPA/CPRA, or another applicable law.

The duration stated for each technology is the reviewed maximum or current behavior, not permission to keep information when it is no longer needed. Coul must remove stale keys, cap drafts and histories, expire caches reliably, coordinate browser and server deletion, avoid storing sensitive values in diagnostics, and review retention after feature or vendor changes. A browser can also evict data earlier because of settings, storage pressure, private mode, or user action.

Browser storage is scoped by origin but is not a secure vault. Someone with access to the device profile, a malicious extension, injected same-origin script, compromised dependency, or successful cross-site scripting attack may access readable values. Coul uses access controls and technical safeguards appropriate to the data, but no browser storage is risk-free. Never place passwords, third-party secrets, private keys, or unrelated sensitive data into a prompt, draft, template, title, or diagnostic field.

The Security/Trust page describes the current security posture without promising unverified certifications. Security incidents and legally required notices are handled under applicable law; a Cookie Policy is not a warranty that storage cannot be accessed, lost, or attacked.

Before publishing this policy as a complete production inventory, Coul must run an authenticated and unauthenticated crawl of the deployed service across representative devices, routes, regions, choices, social connection and Stripe flows. It must inspect headers, requests, redirects, scripts, frames, pixels, localStorage, sessionStorage, IndexedDB, Cache Storage, service workers, and tag-manager containers; verify providers and durations against contracts; remove dormant code; and keep an auditable inventory owner and review cadence.

Coul must also implement time-based cleanup for entries currently described as indefinite, make browser cleanup coordinate with logout and account deletion, verify that rejected optional technology never runs, validate PostHog's production retention and data-processing configuration, and ensure every later tag or vendor passes privacy, security, transfer, retention, and consent review before release. Material changes to an optional purpose, provider, or technology require an updated policy and a fresh choice before activation.

Coul will show the effective and last-updated dates on this page. Before launch, it must verify the operating entity, geographic address, monitored privacy contact, response process, and any required regional representative. Until then, privacy@coul.app is a proposed contact only and must not be represented as a verified monitored rights channel.