Inference data handling policy — draft
Draft document. The operating entity is not yet formed; public contact channels are not yet set up; this policy has not been finalized. It is an accurate, plain-language description of how data moves through the pilot service today.
Read together with the privacy policy and terms of service.
1. Zero data retention
Our zero data retention policy prohibits persistent storage of prompts and completions. Transient in-memory processing and prompt caching support inference. Necessary account, security, and usage/accounting metadata is retained separately.
2. Content is transient
- In transit: requests and responses travel over TLS (Cloudflare-terminated ingress).
- During inference: requests are processed in memory and responses are returned without persistent content storage.
- Prompt caching: transient in-memory tokens and KV state may be reused to reduce repeated prompt processing. This does not create a persistent prompt archive or guarantee instantaneous memory erasure after each request.
- No training: customer content is never used to train, tune, or evaluate any model — ours or anyone else's.
3. Policy scope
Zero data retention applies to inference content, not the operational metadata described below. This draft states our operating policy; it is not an independently verified infrastructure certification. Infrastructure data-handling review remains part of policy finalization.
Rented GPU hosting must undergo a data-handling review before traffic is routed there, and this policy must be updated to reflect the actual processing providers.
4. Consistent handling
The same content-handling policy applies to every request we serve. Processing infrastructure must meet this policy before it can serve customer traffic.
5. Metadata that is retained
Four categories of non-content records persist. They do not contain prompt or completion text.
| Category | What is stored | Purpose |
|---|---|---|
| Account | Name, email, hashed password, role, status, timestamps, hashed session tokens, hashed one-time invite/recovery tokens (expiring) | Identify who may access the service; sign-in; invitations |
| API keys | Hashed key material, name, prefix, created/last-used/revoked timestamps, owning account | Authenticate API calls; attribute usage per account and key |
| Usage / accounting | Request ID, timestamps, model, backend and fallback flags, HTTP status, error type, token counts (prompt/cached/completion), timings, finish reason, retry count, computed revenue/cost | Usage dashboards, operations, abuse detection, future billing, business economics |
| Security | Authentication and authorization events with timestamps | Detect and investigate unauthorized access |
Internal logs follow the same rule: metadata, never content. Raw keys are shown once at creation and are never stored in plaintext; hashed session tokens are used instead of readable session IDs.
6. Retention periods
Prompt and completion persistence is prohibited. Sessions expire after twelve hours or are invalidated by logout, password reset, or account suspension. Invitation and recovery links are single-use and expire. Account, security, and accounting metadata remains in the operational database; an automated metadata deletion schedule is not implemented. Access and deletion requests are reviewed manually, including any legal or accounting retention requirements.
7. Where metadata lives
- PostgreSQL — durable accounting and account records on an operator-managed database host.
- Redis — ephemeral coordination state (concurrency slots, circuit breakers, traffic counters, and short-lived sign-in throttling counters). It does not store inference content or raw credentials.
- Operator infrastructure — application logs hold metadata only.
8. OpenRouter distinction
When OpenRouter distribution goes live, requests from OpenRouter users arrive at this gateway through OpenRouter's platform. OpenRouter is a separate company: its privacy policy and terms govern its relationship with its users, and our content-handling rules in §2 apply to every request we serve regardless of channel. Direct pilot customers have their own accounts and dashboards; OpenRouter users do not get dashboard accounts here.
9. Requests for deletion or information
Invited customers can revoke their own keys and request account information or deletion through the contact route. Revocation is not deletion: key metadata remains for usage attribution and security history. The operator will explain which requested records can be removed and which must remain.
10. Changes
Draft v0.1, September 2026. This policy will be versioned; the finalized policy will be published by the operating entity once formed, before the service is offered beyond the invitation-only pilot.