Data handling
Where requests go, what this service stores, and how retention works.
Request processing
The main Cloudflare Worker authenticates the caller, validates the request, and reserves credits in D1. It sends state, questions, the effective model and accepted extension fields to the operator's configured service: TypeSafe by default, or OpenRouter when selected. Native TypeSafe transport retains JSON values and exact numeric tokens, including nullable inputs supported by the maintained contract. Request content leaves our Worker for inference. The provider processes it under its own terms and data policies.
The upstream request uses the operator's credential. Client Authorization, Cookie and Origin headers and the user's idempotency key are not passed to the shared operator account. Authenticated GET /v1/models reads the real TypeSafe list without creating a decision record or reserving credits; anonymous UI uses public configuration instead.
System One does not promise that upstream providers retain nothing, run in a particular region, or use an identical data policy. The operator is responsible for choosing a provider and communicating any additional deployment-specific terms. Avoid sending content that your application is not authorized to share with that provider.
Decision storage
| Data | Application behavior |
|---|---|
| State, instructions, criteria and request extensions | Forwarded to the configured provider; not stored separately as prompts in decision records/logs. A provider can echo input into a cached response. |
| Request metadata | Request ID, account/key association, request hash, model, counts, status, credits, optional token counts, latency, error code, and timestamps. Retained for 90 days by the decision cleanup policy. |
| Successful answer without an idempotency key | Returned to the caller; no answer replay cache is written. |
| Successful answer with an idempotency key | A versioned envelope caches the response text, status and allowed headers for 24 hours from request creation, including unknown answer/root/usage fields and optional upstream tracking IDs. |
| API keys | Hash and display prefix retained for authentication and management. The full secret is shown only at creation. |
| Account, order, and credit-ledger records | Managed by TinyShip’s retained authentication and billing modules; the 90-day decision-log policy is not an automatic deletion policy for these records. |
An answer cache can contain sensitive output, echoed input, extension values or application-chosen identifiers. Using idempotency is a deliberate choice to retain the entire successful response temporarily, not just selected answers. Do not put secrets into identifiers or key names. Pre-upgrade records are served in legacy-cache mode and keep the existing expiry; their limitations are documented under idempotency.
Successful body fields named billing or request_id belong to the provider. Platform amounts and ledger IDs come from X-System-One-Credits and X-Request-Id, with X-Upstream-Request-Id for provider correlation. TypeSafe-native success text is preserved after validation. OpenRouter uses explicit adaptation and retains provider usage/cost/metadata rather than promising the same TypeSafe bytes.
Cleanup and visibility
The main Worker’s scheduled handler runs the cleanup job every 15 minutes. It refunds abandoned reservations eligible after 15 minutes, clears expired idempotency keys and answer data after 24 hours, and deletes settled decision metadata older than 90 days. Physical cleanup occurs on job execution; these are not promises of exact-to-the-second deletion from backups or provider infrastructure.
The console exposes the signed-in account’s last 30 UTC days of usage and latest 50 requests within that window. It does not expose other accounts’ metadata. Operators should retain the configured cleanup schedule and monitor failures.
Operational logs
Application decision errors log a bounded event name and request ID, not prompts or API secrets. Valid upstream JSON errors retain their original status and body, which may contain detail arrays or echoed input. The UI uses localized classifications from headers rather than displaying that provider text. Exact operator-credential matches trigger the documented safe replacement exceptions; that is not a general promise to detect every sensitive user value. Only documented response tracking/rate headers, Content-Type and Retry-After are forwarded, with secret-bearing values excluded.
These statements describe application code paths, not all logs an operator, SDK or provider could configure. In particular, do not enable SDK body logging or add raw request/error-body logging to proxies, Worker telemetry or support exports without considering its data impact.
The static documentation Worker has no account database, upstream credential, or inference handler. Documentation search loads a build-generated index of these public pages into the browser. It does not send search text to the Jev inference API.
See idempotency for response recovery and deployment for the operational configuration.