PRIVATE PILOT · SEPTEMBER 2026

Your data,
in plain sight.

Where processing happens

The console and queue run on the Prism server. For Ministral and Mistral, request content is sent to OpenRouter and the model provider it selects. For Qwen 3.8 27B, encrypted requests are queued on the Prism server and sent to a temporary GPU worker on Modal; outputs return to Prism. This pilot does not promise regional routing, zero retention or a data processing agreement. Use non-sensitive test data.

What is saved

Request and response content is encrypted in private files on the Prism server in Germany. Accounts, workspace memberships, job metadata, token usage and billing records are stored in PostgreSQL on Supabase in Paris. Job and file names are metadata too: do not put sensitive information in them. Encrypted recovery copies are also kept in private Supabase Storage in the same Paris project. The archive decryption key is held separately by the operator. API keys are stored as hashes; the owner bootstrap key remains in a file readable only by its owner.

Retention and deletion

The worker requests deletion of upstream batch data and clears local request and response content after seven days, or earlier when you select “Delete saved content”. If the upstream deletion fails, the request remains pending and is retried. Provider-side retention beyond the batch API is governed by that provider’s terms. Backups may retain earlier copies until rotation: seven business snapshots on the server and thirty verified business archives in external storage. Separate encrypted identity and configuration recovery kits retain seven daily versions. Optional operator workstation copies retain thirty business archives. The Qwen queue has separate encrypted storage with seven-day content retention and supports deletion through the same client action. Its recovery currently depends on the server disk; it is not included in the offsite business archives. Operational and accounting metadata remain. Keep the worker running for cleanup to occur.

Authentication and payments

Google and GitHub sign-in, when enabled, use Supabase Auth. Your name, email address and identity identifiers are used to create your account and control workspace access. Each new account starts with its own workspace and no funded credit. Browser authentication uses a short-lived HttpOnly session cookie and a CSRF token. No analytics or advertising cookies are installed by this application. Stripe, when configured, hosts the payment form; Prism does not receive card numbers. Only Stripe test payments are supported in this pilot.

Your account and data rights

In Account & security, you can correct your display name, download retained personal-workspace records, revoke browser sessions, request access, rectification, objection, restriction, erasure or portability, and close your account. Requests receive a tracking record and response deadline. You can also contact the operator through your pilot invitation channel. No marketing emails are sent.

Two-factor authentication is optional. Authenticator secrets are encrypted and recovery codes are stored as hashes. Recovery codes are single-use and still require sign-in with your original Google or GitHub account. Application API keys cannot change your personal security settings.

Account closure immediately revokes browser access and relevant keys. Shared-workspace ownership must be transferred first. Personal-workspace content is scheduled for deletion; running batches and provider failures can delay completion. A private receipt tracks upstream deletion. Pilot account metadata is removed 90 days after deletion completes. Earlier backups expire through the rotation described above. This pilot accepts no real customer payments; production accounting retention must be defined before real payments are enabled.

Before a public launch

This is an operator-managed prototype. Google and GitHub sign-in are available when configured. Encrypted backups, offsite collection, operational alerts and a restore drill are in place. Cloud monitoring checks the worker heartbeat and public HTTPS access independently of the server and operator’s workstation. Encrypted archives are sent directly from the server to private cloud storage and checked after upload. A Supabase outage also affects this monitor and access to that storage. Broader launch still requires independent custody of recovery keys, an end-to-end identity recovery rehearsal, provider agreements and production payment configuration.