How Compute handles your data
What stays in your environment, what Lithi receives, and which policy sets how long your files, results and account records are kept.
When you use the Kit's supported local preparation helpers, they run in your controlled environment on a permitted working copy. The transformed copy and complete composed request are inspected and re-scanned before sealing. Your original data and reverse identity map stay there; an authorized transfer sends prepared, encrypted blocks and a content-free planning manifest. An assigned Mac reads only the piece it is granted.
For example, a preparation run may replace names with scoped references before sealing a file. The original values and the map back to them stay in your protected store, while the service receives only the prepared blocks needed for the approved task.
Account details, billing records, support messages, and provider telemetry follow separate paths. Their access and retention rules are not the same as those for encrypted task files.
Separate local assessment from a price preview
You may authorize local Lithi code to inspect and prepare input in your own environment. Give any AI tool only the access needed for that assessment. Its own provider terms still apply; local preparation does not prove that every other tool you use keeps data local.
Local preparation does not mean a cloud-hosted agent's context stays local: the agent may receive terminal output or files. Return only a safe preparation summary or opaque handle, and keep raw records, identity maps, and detailed diagnostics protected.
A price preview is not an input upload or permission to run work. Keep customer content, private filenames, paths, transcripts, source code, and secrets out of preview fields. Use the supported descriptive fields rather than pasting a sample customer record into an estimate request.
An access application or support form is another data path. It collects the contact and message information you submit. Do not use those forms to deliver private work files or credentials.
Match the input to its permitted profile
A data profile describes the data category and purpose the work may use. Public, properly deidentified, customer-approved, native-test, and synthetic data have different requirements. A profile label is not proof that the actual content qualifies.
Do not send credentials, prohibited regulated or secret material, or unsupported input through a shared path that refuses them. Customer approval does not override a prohibited category. Removing a name alone does not establish deidentification.
The data-profile reference lists the exact accepted and rejected outcomes. Keep classification separate from encryption, jurisdiction, credentials, execution admission, and destination permission.
Keep the identity map and preparation evidence local
When a workflow replaces real identities with scoped references, the mapping between a reference and the original value stays in your own protected store. It does not go into a provider-readable manifest, ordinary AI-agent context, logs, standard output, exception text, notebook cells, crash telemetry, or any public artifact. Restoration happens in your own environment, after you check the result, and only for the fields your output permits.
A preparation run's detailed transformation evidence — which fields changed and which decisions remain unresolved — stays in that same protected environment. A safe preparation summary, covering versions, counts, coverage, and decisions, is what may accompany a submission. Every preparation run ends as blocked, review_required, or eligible. Blocked and unresolved runs release nothing; eligibility allows sealing but does not itself approve transfer or execution. Your original input is never a fallback; see what leaves your machine for what each decision means.
Spread placement limits one owner's access
Under spread placement, Lithi plans work from sealed blocks and limits the share of input groups any one provider owner can reach in that run. The cap includes all of that owner's devices, verification, reducers, retries, and other combining steps. Your environment performs the final join; a network reducer receives only its declared scoped inputs, and every group it can read counts toward owner exposure. Read how your job is split across Macs for the exact rules, single-group limits, and key-release custody statement.
"No findings" and "not inspected" are different outcomes. A coverage statement names the languages, formats, and fields actually inspected, so you can tell them apart.
Follow processing and stored copies
| Data or stage | Boundary to review |
|---|---|
| Customer-local input | The authorized tools and people that can inspect the original and prepared copies. |
| Encrypted artifacts | The approved transfer, recipient, exact object, access expiry, and storage profile. |
| Ordinary control and relay services | Approved metadata and ciphertext only, not an alternate plaintext-processing bridge. |
| Network reducer, when used | Only the declared scoped inputs; every readable group counts toward its owner's exposure. |
| Admitted execution | Readable task data in the authorized executor's bounded memory or workspace. Ordinary provider memory is not confidential from every privileged host owner. |
| Customer-local final join | Your environment combines accepted pieces and restores only the identifiers and fields its authorization permits. |
| Results and destinations | Results encrypted before leaving the executor, followed by separately authorized storage, delivery, decryption, and later copies. |
| Account, support, billing, and receipt records | Their own minimum fields, access rules, purposes, and record-keeping requirements. They are not the encrypted task payload. |
A receipt or integrity digest links the evidence it covers. It does not disclose all processing history or prove every model answer correct. Keep private content out of metadata and diagnostic text rather than assuming artifact encryption covers them. These boundaries apply to the accepted run and its declared pieces; they are not a claim about an entire dataset across all time.
A task does not create standing reuse permission
Lithi processes permitted data you authorize for a task. It does not offer customer task datasets or contact lists for sale.
Running an original task does not by itself authorize indefinite retention, an exact-copy learning dataset, or model training. A secondary use needs its own stated purpose, permitted scope and applicable policy or agreement. Check the retention guidance and Privacy and data use for the policy that applies to the relevant data category; do not infer permission from the fact that the task ran.
Provider telemetry is separate from customer content
When a provider Mac participates, Lithi may process bounded operational telemetry for the provider path and impact reporting. This telemetry describes the machine, runtime, and measurement. It is separate from task inputs, outputs, and other customer content.
The standard path may process:
- a model identifier, SoC, and memory cohort;
- runtime and release information;
- bounded energy intervals, thermal state, and power state; and
- permitted coarse region evidence when the impact method requires it.
The standard path does not require a serial number, hostname, private application inventory, raw owner process list, customer content, or exact location. Provider telemetry does not grant access to task content.
Telemetry travels as a signed, schema-validated energy observation over the allowlisted provider control transport. Only that observation message is admitted on this path; arbitrary telemetry, task content, and owner process data are outside the allowlist. The gateway checks the device, provider account, admitted release, canonical payload digest, and replay and overlap rules before the observation is recorded. The observation payload has no task content field.
How readings become reportable
Stored observations and reportable values are separate. The available evidence is classified as:
| Evidence tier | Meaning |
|---|---|
lab_meter_direct | Lithi-controlled external whole-system metering. |
calibrated_device_telemetry | A gauge reading from a qualified device cohort inside its validation envelope. |
calibrated_profile | A model from a qualified profile when this device has no qualifying gauge. |
device_gauge_raw | Stored device evidence that is never reportable on its own. |
unavailable | No admissible evidence; coverage falls accordingly. |
Raw telemetry is retained as append-only evidence. Bounded retention or compaction requires separate authorization and must preserve the observation references used by filed reports. The Compute impact methodology explains how evidence, coverage, and unavailable values appear in a report.
This boundary supports transparent reporting. It is not independent assurance, a regulatory certification, an ISO certification, or a confidential-computing enclave claim.
Check location and retention separately
Source, local preparation, processing, storage, key custody, and destination can each have different location restrictions. Do not infer the complete path from one hosting region. An unknown or unsupported required jurisdiction is a reason to stop, not to pick a more convenient country.
Access expiry is not deletion. A removed download permission does not prove erasure of the object, a backup, temporary memory, or a destination copy. Retention commitments come from the applicable product policy and agreement for that data category.
Ask a data-handling question with the product, data category, required region or retention condition, and safe reference. Keep the dataset, bank details, private messages, and secrets out of the request.