Tarseek Legal Center

Data Practices & Retention

This page is a plain-language companion to the Privacy Policy. It describes how Tarseek intends to handle different classes of data. It is a specification of target practice, not a claim that every control is live.

1. API requests

Target policy: API prompt and output content should not be retained long-term by Tarseek by default. Usage metadata may be retained. Temporary content retention may be required for debugging, abuse, security, or delivery, and should be time-bounded and access-controlled.

By default, Tarseek stores usage metadata but not API prompt or output content. If a project owner explicitly enables model-improvement sharing, future API inputs and outputs are copied to a separate improvement dataset until sharing is turned off. Disabling sharing affects future requests; account deletion removes retained samples unless preservation is legally required.

Optional response caching and session affinity

When a caller enables response caching, Tarseek stores encrypted response content for the requested lifetime (1 second–24 hours; default five minutes). Prompts are hashed rather than stored in cache entries. Expired entries cannot be replayed and the worker removes their encrypted bytes. No-collection requests and requests with files or media bypass response caching. Provider prompt caching is separate and follows the selected provider’s terms. Session affinity stores scoped hashes rather than raw session identifiers.

Optional alerts and trace delivery

Managers can configure external request traces and signed alert webhooks. Project members receive a high-signal default set of project email categories at their own verified address and may change or disable those categories per project. These send operational metadata, not inference prompts or completions, to the chosen destination. Alert payloads remain eligible for delivery for seven days and delivery history remains for 30 days. Disable a destination to stop future delivery; already-sent data remains subject to the receiver’s practices. Signing secrets are encrypted and excluded from data exports.

Optional Tarseek communications

Account communication preferences are stored separately from project notifications and essential account mail. Product updates and news currently default on; tips and education, and research, events and offers default off. Future optional communications are intended to come from updates@tarseek.com and include a preference or unsubscribe mechanism.

2. Chat

Hosted Chat history may persist because storage is an explicit user-facing feature. Users should be able to delete Conversations. [TBD: exact chat retention.]

3. Memory

Memory is separate from Chat history. Personal memories are visible only to the user who created them and may follow that user across projects. Retrieved memories are treated as potentially stale background context rather than instructions.

4. Files

Uploads may be transmitted to the Model Provider selected for a request. Reusable API files expire after 30 days by default and callers may select an earlier expiry. Chat attachments and generated files stay with the Conversation until the user deletes the file, Conversation, or account. Provider-side copies remain subject to the selected provider's disclosed practices.

Uploaded files may be subject to validation and automated security checks. Some security-scanning controls depend on the production environment and configuration and may not be active in every development or testing environment. Users should not upload malicious files or content intended to interfere with the Service or other systems.

Native batch processing

Submitting a batch explicitly requests asynchronous processing and temporary content retention. Tarseek stores encrypted work and results while processing and for seven days after completion, then removes their content. The original uploaded file follows its separate expiry and deletion settings. Project members can download results during that period. Account deletion requests cancellation of unfinished batches and clears completed batch content; work already submitted may need to settle before its content can be cleared. Operational metadata may be retained longer.

Hosted tools and shared secrets

Tools send the arguments needed for an action to their configured destination. Search queries may be sent through our self-hosted search service to upstream search engines; web-reader URLs are fetched by Tarseek; and weather place names, coordinates, dates, and hours are sent to our configured weather and geocoding provider. Date and time lookups are computed locally from the runtime timezone database. Fetched pages and tool results may be included in the selected model's context. Those external services have their own data practices. Public tool definitions are discoverable, but project connections and credentials are not public.

Account deletion disables owned tools and connections, erases saved credentials and tool definitions, and removes reusable policies. Operational execution records may remain for security. Use trusted tools and destinations. Disabling a connection or secret prevents future dispatch but cannot undo an external action already sent. Search results and citations can be incomplete or inaccurate; a citation does not guarantee that a source supports a claim.

5. Usage metadata

Tarseek may retain limited request and usage metadata, such as the model used, token usage, latency, request status, request identifiers, and estimated usage information, for operating, securing, debugging, and improving the Service. Prompt and response content is not stored as part of the standard inference usage record. Until an automated retention period is implemented, this metadata may remain stored for operational purposes. Tarseek intends to introduce an automatic retention period and will update this policy when that becomes effective.

6. Security logs

Tarseek may generate and retain security-related records necessary to protect accounts and the Service, including records relating to authentication attempts, account changes, credential activity, abuse prevention, suspensions, and security incidents. Retention periods may vary depending on the type of record and the security purpose for which it is maintained. Tarseek does not currently represent that all security events are retained for a fixed 90-day period.

7. Backups

Tarseek may maintain backup copies of service data for security, reliability, and disaster-recovery purposes. Where backups are maintained, deleted data may remain in backup copies for up to 30 days before being overwritten or deleted through the normal backup lifecycle. Backup copies are not intended to be used as active user storage. If no backup copy exists at the time data is deleted, this additional retention does not apply.

8. Account deletion

When an account is deleted, access is disabled and associated account data is scheduled for deletion from active systems. Some deletion tasks may be processed asynchronously. Residual copies may temporarily remain in backups, logs, or systems where immediate deletion is technically impracticable, subject to the applicable retention periods described in this policy. Tarseek does not currently provide a user-facing guarantee that every background deletion task has completed at a particular time. Provider-side copies may remain under provider policies.

9. Zero Data Retention

Zero Data Retention (ZDR) means a Model Provider is represented as not retaining prompts/outputs beyond fulfilling the request. Offering ZDR as a user control requires verified provider metadata, routing enforcement, and honest labeling. Unverified endpoints must not be marked ZDR.