Data retention and deletion

Retention and deletion in Ethen must be evaluated by data store, product, and external provider. No platform-wide schedule, universal deletion workflow, or public backup policy is currently established. Use this page to separate those domains and to avoid promising that a delete action reaches every copy immediately.

The manifest marks this page as generally available, but its operational claims remain under legal, privacy, infrastructure, and security review. No fixed duration or deletion SLA should be inferred from the examples below.

Retention model

A workable retention model begins with an inventory of the places a record can exist. For one request, those places may include the primary product store, an operational log, an observability summary, a local file, a browser state, a backup, and an external provider.

Retention should be described per category rather than as one number:

Production and staging Supabase projects, migrations, RLS, storage buckets, backups, and ownership decisions remain external setup items. A deployed retention policy must account for those choices.

Retention decisions also depend on purpose. A short-lived request cache, an operational error record, a customer project, and an incident artifact may have different legitimate uses. The absence of one universal period does not mean that data should be kept indefinitely; it means the deployer needs an approved schedule tied to each purpose and store.

Record the event that starts the retention period. Creation time, last use, project closure, account termination, credential revocation, and incident closure are not equivalent triggers. Without an agreed trigger, a duration cannot be applied consistently.

Ownership of the schedule

A retention schedule needs an accountable owner for each data class. Product engineering can describe where a record is created, infrastructure can describe the configured store and backups, legal and privacy reviewers can approve the governing obligation, and operations can verify that deletion or archival actually occurs.

When those owners disagree, the strictest approved requirement should govern until the conflict is resolved. Do not choose a period because it is convenient for the interface or because another product uses it.

Deletion

Deletion can refer to removing a visible record, removing the durable primary record, revoking access, deleting a provider copy, or purging a backup. Those outcomes are different and may occur through different systems.

Before documenting or executing deletion, identify the record type and its owner. A project record may have related usage events, logs, assets, credentials, or provider artifacts. Removing one row or interface entry does not prove that every derivative record is gone. Likewise, revoking a credential prevents future use but does not erase historical provider requests.

No universal self-service deletion control or guaranteed completion window is established. Product pages should describe only the deletion behavior implemented for that record. Where a capability is absent, direct the administrator to the approved Help or Contact route without promising a response time.

Customers should avoid claiming completion until they have checked the primary store, dependent records, local copies, and applicable provider procedures.

Deletion stages

A defensible deletion workflow can be divided into stages even when timing is not yet approved:

1. authenticate the requester and confirm authority over the record;
2. identify primary and related records;
3. revoke active credentials or sessions where continued access is possible;
4. remove or anonymize the primary data using the product’s supported mechanism;
5. address derived logs, artifacts, local copies, and provider-side data according to their own contracts;
6. record what was completed, what remains in backup, and what could not be verified.

Do not report “deleted” when only visibility changed. If a product lacks a supported deletion mechanism, record the limitation and use an approved support path rather than modifying the backing store manually without an operational procedure.

Example: closing a provider-backed project

Closing a project that used a hosted provider can require several independent actions. First, remove user and service access to the project so new requests cannot be created. Next, identify Ethen-side project records, credentials, generated outputs, usage events, and logs. Then determine which provider account received the requests and whether the provider exposes its own deletion or retention controls.

A customer may choose to revoke the provider key before deleting historical records. That sequence limits new use while preserving time to investigate the existing data. It does not remove prior provider content. Conversely, deleting a visible Ethen project first may make it harder to identify the provider requests that still need attention.

Local and browser copies deserve their own step. Downloaded files, exported output, local runtime data, and developer fixtures are outside a central deletion action unless the product explicitly manages them. Record any copies that remain and the owner responsible for removing them.

The final status should use precise language: access revoked, primary record removed, provider request submitted, backup copy pending expiry, or local copy unverified. Avoid one global “complete” state when the underlying systems have different outcomes.

Backups

Backup policy is an infrastructure decision that is not defined as a public commitment in the current repository. Supabase-oriented persistence may be compatible with provider backup features, but repository schemas and server modules do not prove that backups are enabled, how often they run, how long they are retained, or whether restores are tested.

A production review should document:

• which stores are backed up;
• who configures and monitors the backup;
• recovery-point and recovery-time objectives, if approved;
• encryption and access for backup media;
• how restore testing is performed;
• whether deleted records remain in backups;
• when backup copies are eligible for purge.

Do not describe a backup as an archive, an audit log, or an immediate recovery guarantee. Backups are also not a substitute for product-level export or durable event ingestion.

Any published timing, recovery, or purge statement requires infrastructure and legal approval.

Restores can reintroduce records that were deleted from the primary store after a backup was taken. A production policy therefore needs a method for handling deletion markers or reapplying deletion after restore. That behavior is not established in the current platform evidence.

Backup access should be narrower than ordinary application access because a backup can contain many customers and historical versions. The policy must also distinguish disaster recovery from routine export. A customer-facing export is not a backup, and a backup is not an audit record.

Logs

Logs and observability records have their own retention and access needs. Gateway logs, platform logs, request metadata, errors, traces, usage events, and audit records are not interchangeable.

The current /audit-log route uses sample fixture data. Observability can mix bridged, fixture, and unavailable metrics. Those records help demonstrate interfaces and intended fields, but they do not establish a production log-retention schedule.

For a live runtime, document whether the log contains content, metadata, identifiers, provider details, or errors. Restrict access according to the sensitivity of those fields. Redaction should occur before storage where possible; deleting a source record later may not remove data that was copied into an earlier log.

A retention decision should balance investigation needs against privacy, secret exposure, and storage risk. The current implementation supplies no fixed period that can be applied safely across all log types.

Metadata can remain sensitive even when prompts and outputs are excluded. A request ID, provider, model, repository path, error code, timestamp, or actor identifier can reveal usage patterns and system structure. Log design should therefore define both content and access.

If an investigation requires longer preservation than the ordinary operational period, the exception should be documented and scoped. No central legal-hold or exception workflow is proven, so the organization must decide how such preservation is authorized and later ended.

An administrator should also decide whether a log is operational, security relevant, financial, or diagnostic. That classification affects who may view it and whether a shorter period is appropriate because the record contains content or identifiers. Current product surfaces do not supply a universal classification, so record it in the deployment register.

Customer responsibilities

Customers should maintain a deployment-specific retention register instead of relying on the manifest maturity label. The register should identify the product, data class, owner, primary store, external provider, backup treatment, access group, and deletion path.

When offboarding a user or project, revoke active sessions and credentials before addressing historical data. Review local devices and configured endpoints as well as hosted stores. For BYOK, follow the provider’s revocation and deletion procedures in addition to any Ethen-side cleanup.

If a product is marked Preview, Private Alpha, Sample, Fixture, Demo-only, or Setup required, confirm whether its records are suitable for long-term operational use. Avoid using a fixture-backed audit view as the system of record for a regulatory or incident requirement.

Customers must also preserve data that they are legally required to retain. This documentation does not determine those obligations.

During project closure, customers should review more than the project page. Check provider credentials, local runtime caches, downloaded exports, attached files, generated assets, workflow records, usage events, and any external provider account that received data.

Keep the evidence of completion proportionate to the sensitivity of the data. For a low-risk test project, a simple administrative record may be enough. For regulated or contractually restricted data, an approved retention and deletion procedure is required before production use.

Policy links

The approved legal references are the Privacy Policy and Terms of Service. They remain authoritative for published privacy and service statements.

Pending routes for data retention, BYOK data handling, security, enterprise security, and cookies are not approved as live documentation links. Their absence means this operational page must not fill the gap with invented periods, deletion promises, provider guarantees, or backup commitments.

For a deployment-specific question, use the public Help or Contact surface and describe the product, record type, provider, and requested outcome. Do not assume that a support request itself creates a deletion SLA.

This page remains a draft until retention, backup, and deletion contracts are approved and verified against production infrastructure.

Questions that still require approved policy

Before this page can move beyond draft, an approved policy must define which data classes receive a retention period, the event that starts each period, the treatment of backups, the scope of customer deletion requests, provider-side dependencies, and the evidence used to confirm completion.

The policy should also explain exceptions for incidents, disputes, or legal obligations without turning those exceptions into indefinite retention. Operational documentation can then reference the approved rule instead of repeating an unverified estimate.

Until that work is complete, administrators should use a deployment-specific register and avoid publishing universal timeframes.

A deployment should record who approved its temporary schedule and when it will be reviewed. That note prevents an interim operating choice from being mistaken for a published Ethen retention commitment.