Planned data handling

This page summarizes the proposed data handling in the supplied version 1.0 specification. It is not an adopted privacy policy for a live paid service. The console is an illustrative preview.

The operating entity, eligible jurisdictions, contact route, and applicable obligations must be resolved before paid access. The supplied materials do not establish those production details.

The pilot design calls for processing prompts without logging them. Implementation, access controls, and operational verification of that behavior remain part of the build gates.

The proposed service retains encrypted response artifacts for 24 hours so clients can recover results after a connection failure. That retention supports retry behavior without duplicate execution.

The brief proposes retaining billing metadata and proof bundles for 90 days by default. A documented privacy and accounting decision may change that policy before launch.

The intended pilot uses an EOA wallet to establish ownership and sign specific actions. Wallet keys must remain outside server and client logs. The preview does not request a real signature.

Public transfers reveal wallet addresses, amounts, and timing. A private receipt design does not make the funding and withdrawal activity anonymous.

Registry payloads are designed to contain batch commitments without customer content or customer wallet addresses. The private bundle provides the record and proof needed for checking inclusion.

Receipt verification checks a signature and committed record. It does not independently prove execution correctness, truthful metering, answer quality, confidential serving, or anonymity.

The proposed implementation requires owner-only reads, tenant isolation, redacted logs, private worker networking, and role-restricted operator controls. These controls require actual implementation and review.

The operations phase includes deletion jobs, content-leak checks, incident drills, and recovery evidence. Planned retention durations should not be presented as verified service behavior before those checks pass.

The initial scope is one region and vetted authorized workers. The production hosting region, processors, and supplier details must be documented before live customer data is accepted.

A production policy must identify the operator, processing purposes, applicable rights, retention rules, and a working contact route. This preview does not invent those legal or operational details.

Read the product overview and build brief for the proposed design. Their descriptions are product requirements, not evidence of a deployed service.

Product guide ↗ · Product overview PDF ↗ · Build specification PDF ↗