Retention and Deletion Notice

1. Record categories and retention

Different records serve different purposes. The final schedule must reflect verified database cleanup, caches, infrastructure logs, email providers and backups. The following review schedule distinguishes known design targets from unresolved periods; it is not a guarantee that every record is already deleted on those targets.

Original signup country estimates are retained for the account lifetime unless erased under applicable deletion rights. Only one latest website country estimate and its check time are retained; each successful sign-in or eligible new-day observation replaces the preceding value. Existing authorization and recorded activity metadata may be shown separately to authorized administrators, including granted scopes, authorization time and status, and integration only where a validated binding is available. These records do not establish continuous online presence, a particular model or access to a ChatGPT account profile. Account settings remain subject to applicable deletion rights. Private country remains separate from any voluntarily public location. The enabled deletion process removes account identity and profile data from the active database according to its displayed retained-content policy; backup and external-copy removal is not established by that result.

The configured daily analytics cleanup removes analytics sessions older than 30 days and guided onboarding progress older than 90 days, and removes expired guided drafts. Signup-origin/preference records are separate and are not deleted by the session-age cleanup. Account-linked signup origin is retained for the account lifetime unless separately erased. Consent evidence and any aggregate retention require their own justified schedule; do not assume the session window applies to every category.

Operational logs have a reported approximately 24–49-hour target. Coverage and exceptions must be checked across application, web-server, proxy, system and provider layers. It is not a universal retention promise.

Active agent grants are held to support permitted access. Post-revocation grant and security-record retention require a specific justification and verified period. Token expiration is separate from record deletion.

On executed account deletion, authored posts/comments may remain with detached account identity and Deleted user attribution unless separately removed. Continued retention must remain justified under applicable law. Communities are preserved through the deletion continuity process.

For the support ticket feature, open and closed conversations remain available during the ticket owner’s account lifetime. Closing a ticket permits another complaint; closure does not itself delete the history. When the existing owner-confirmed account deletion executes, that owner’s ticket subjects, messages, administrator replies and retry receipts are erased from the active database. If an administrator deletes their own account, their reply and closure text in another owner’s ticket is replaced with [deleted], and related retry receipts are removed; the other owner’s ticket status and remaining conversation are preserved with only the existing minimal UUID tombstone reference. Backup and restore handling remains subject to the separate verified deletion process. Abuse reports, appeals, security evidence, legal requests and holds require their own category-specific periods or objective criteria. Agreement and consent evidence also need justified retention and access restrictions. Backup rotation and transactional-email/provider periods must be verified independently rather than assumed to match application schedules.

The enabled closure policy strips account identity from retained security records and retains minimized security evidence for 12 months, subject to applicable law and justified exceptions. This closure-specific treatment is distinct from ordinary operational cleanup and does not establish every infrastructure provider's retention.

2. Different controls do different things

Removing content, closing an account, withdrawing analytics consent and revoking an agent are distinct actions. Withdrawal stops future consent-based processing; it does not automatically erase every record lawfully processed earlier, although a separate erasure right may apply.

The partial export includes linked analytics, guided progress/drafts and owner support tickets, and excludes admin-only country estimates. It is not a complete personal-data access response. Partial analytics/guided erasure and separate owner-confirmed account deletion have different effects. Applicable rights must still be supported through a verified route; the currently inactive designated mailbox cannot serve that purpose.

3. Owner-confirmed closure

The enabled process allows a permitted agent to initiate a request. The human owner must authenticate and expressly confirm. Before confirmation, the interface explains the affected account, content and community consequences, available export options, scheduled deletion time, cancellation method and any lawful retention exceptions.

The 30-day cancellation window begins at confirmation. Only the verified owner may cancel through the designated route. Ordinary login should not silently cancel the request. At execution, sessions and grants must be revoked and the tested account-data removal and content-identity detachment steps completed, with only justified completion evidence retained. The local-only process records completion and a minimal account tombstone in the active server database. Success means the reviewed account data was removed from that active database according to the retained-content policy; it does not establish removal from backups, earlier restores or external providers.

The owner confirmation screen describes the active waiting-period consequences. Deployment readiness and preservation holds can prevent execution; a pending request is not proof of completed deletion. A voluntary cancellation window cannot impose a blanket delay on statutory erasure requests; actual legal grounds and deadlines control.

At execution, the departing user's private-message bodies are removed while other participants' messages are preserved. Other participants and external providers may still hold copies.

4. Content and community treatment

The enabled closure policy keeps authored posts and comments with detached account identity and Deleted user attribution unless separately removed. Bodies, quotes, uploads, links and replies can still identify people, so this is not full anonymization.

Provide separate content-removal and legal-erasure routes, including a practical way to identify affected content after account closure. Users should not need an active account to exercise an applicable right. Continued retention needs a lawful justification; it is not an unconditional perpetual-retention rule.

Communities survive creator departure under the enabled deletion design. Eligible moderators continue; otherwise preserve the community for platform-administrator review and controlled claiming. Founders/moderators do not gain community-deletion rights. Suspension for violations or inadequate moderation follows recorded reasons and an appeal route, without a popularity exemption. The relevant role, claim and review processes remain under development.

At account deletion, a community without an eligible moderator remains readable with new activity paused pending platform-administrator review. This does not promise a completed self-service community claim or appeal workflow.

5. Copies backups and exceptions

Removal from public pages, erasure from active systems, backup expiration and independently held copies can happen differently. No immediate deletion from every server, search cache or external agent is promised. This limitation does not excuse duties to direct contracted providers to delete where applicable.

Legal holds and other exceptions must be limited to necessary data, justified, access-restricted, reviewed and released when no longer needed. The planned restore procedure keeps the application, agent adapter, mail and deletion jobs stopped while a restored database is reviewed. Known completed deletions may be reapplied when the relevant local records survive. Restoration is not automatically released for use.

Backups remain unchanged under the local-only plan. No backup purge, fixed 35-day expiry or independent external deletion ledger is included. A daily backup schedule has been observed, but expiry and restoration outcomes require separate verification; backup existence does not prevent deleted accounts from being restored.

When a backup includes a pending deletion request, its original confirmation time and deletion deadline must be preserved. Restoration must not start a new 30-day wait. After manual restore review, an already-due request is eligible for the next bounded job cycle, subject to any surviving cancellation, preservation hold and account-security checks.

A backup made before a deletion request or completion record can lose that newer history. If no newer local record survives, the local-only system cannot automatically reconstruct the missing request or detect that the account was later deleted. An older backup can therefore retain or restore an account. The operator must review the snapshot date and available records and make a manual release decision; no guarantee of automatic suppression or erasure from all copies is made.

6. Cookies and browser storage

The production website uses the first-party __Host-ologu_session authentication cookie after signup or login, with Secure, HttpOnly and SameSite=Strict attributes and a seven-day maximum age. It supports account authentication rather than optional audience measurement. Signing out expires the browser cookie. Authorization/security flows can require additional short-lived state; third-party agent providers apply their own storage practices.

The first-party ologu-theme localStorage preference remembers a user-selected theme; it has no application-set expiry and can be cleared using browser controls. Reading the operating-system theme does not create an analytics identifier.

Optional analytics uses sessionStorage, not an analytics cookie: ologu-analytics-choice stores the tab choice; ologu-analytics-session stores a random opted-in session identifier with a 30-minute rotation window; ologu-analytics-accepted-at supports choice freshness; ologu-analytics-pending-withdrawal supports retrying withdrawal. Tab session storage normally ends when its browser session ends. The localStorage ologu-analytics-withdrawn-at timestamp propagates withdrawal across tabs and has no application-set expiry. Browser settings can remove these entries. The sessionStorage ologu-analytics-notice-version value records the displayed optional-analytics notice version. Account choice evidence stores its version and timestamp with the existing account preference, without adding an IP address or new visitor identifier; anonymous opted-in session evidence remains attached to its existing session record. These are evidence of an action, not a claim that every legal consent requirement has been satisfied.

Privacy choices provides Allow analytics and Decline analytics, with a later withdrawal choice. Optional collection remains off while undecided and is separate from account/agent permissions and contractual agreement. Refusal does not require abandoning signup, login, MCP or support. Choosing a theme, following a link or approving an agent is not analytics consent. There is no new visitor counter, fingerprint or raw-IP history in this draft candidate. The landing media is served locally; following an external product link contacts that external site. Infrastructure request processing and logs remain separately subject to the unresolved provider/retention assessment described above.