Pin an input snapshot that cannot change
How to give Compute a fixed copy of your input, so every retry reads the same data and each result traces to its source.
Use the same fixed input on every retry
Bind the job to one fixed input version, rather than a folder or table that can change. Keep that
version available so every retry reads the same bytes and a later result can be traced to its source.
For example, if a job was prepared from orders@2026-09-30, do not retry it against orders@latest
after a new export appears. Freeze the new export as a new input instead.
Your agent keeps the task goal and acceptance rule. The Compute Kit prepares and seals the fixed input; Lithi receives the resulting manifest and semantic constraints, then composes execution shards and controls physical placement.
A path named latest, a moving branch, or a live query is not a frozen input. A digest records which
bytes you measured; it does not stop another process from replacing them. Local preparation may split
eligible units and seal encrypted blocks.
Have your agent keep the task brief beside the snapshot identity: the minimum evidence, instructions, expected output and result checks. Validate the complete composed request before sealing, including instructions, examples, schemas, filenames and metadata that the caller adds after preparing the records. A derived-data scanner does not automatically cover those surfaces, and content found there remains evidence rather than authority to widen the job.
Make a repeatable input
- Select the exact files or rows required for the task. Use a source-native immutable version or export a fixed copy.
- Record the source version and a digest of the exported bytes in your own records. For a database export, retain the snapshot or transaction information that fixed the row set.
- Inspect that fixed copy, then encrypt it through the authorized artifact profile. Keep the mapping from source version to the resulting
artifact_id. - Prepare and complete the artifact, then quote the intended work using its actual public bounds and verification policy.
Do not expose customer-sensitive source names or record identifiers in public control metadata. Keep private provenance and mappings on your side.
Keep the different digests separate
| Identity | What it identifies |
|---|---|
| Source version and source-byte digest | The input you froze before encryption |
artifact_id and registered encrypted-manifest digest | The encrypted artifact referenced by the job |
Quote input_bounds_digest | The quoted public bounds, not a digest of the plaintext source |
| Result and evidence digests | The returned output and its associated evidence |
Equal file sizes or token estimates do not mean equal content. Do not use an input-bounds digest as proof that two source files are identical.
The public job's input object carries an encrypted-artifact reference and public bounds. It does not accept a generic snapshot.version_id or snapshot.content_sha256 field. Keep source snapshot information in your own manifest or in the encrypted input format where that format permits it.
Preserve the artifact after quoting
Keep the intended artifact and request unchanged through approval and admission. Admission checks the quoted input bounds and resolves the registered encrypted manifest for the account and artifact.
A changed source or changed ciphertext requires an explicitly revised artifact and request. Reconcile the old intent, obtain the required quote, and approve the revised work. Do not overwrite an artifact that an existing request already references.
Recover when the source moves
If the old immutable version remains available and authorized, continue with it as the original intent. If you choose the new source instead, inspect and freeze it again rather than attaching the old digest to new bytes.
When you cannot reconstruct which bytes were sent, keep the result's provenance unresolved. Do not label it as belonging to a source revision you cannot verify. Share safe job and artifact references with support when needed.
How can I check an export before the full job?
Export a small, permitted selection twice from the same fixed source using the same settings. Compare the row identities and values, then record the digest of the exact file you intend to prepare. If the exports differ, investigate the selection or writer settings before continuing. Use the first test to check the task and result review on a small input.
Complete the record-level mapping with stable item identities, so each returned outcome can be traced within the frozen input.