Compute
Run Compute over a BigQuery export
Bind a completed export or table snapshot identity, stage immutable files Compute can read, then load or commit results as a separate verified step you control.
What this connects
BigQuery tables you export yourself, in one direction. Lithi reads a finished export and writes an accepted result bundle back to result storage.
The conformance level is import_compatible, which means Lithi reads released open file formats under a published conformance matrix. Lithi does not run queries in your project and holds no BigQuery API compatibility claim.
Bind an exact input
Wait for the export to finish before you bind anything. A half-written export directory is a moving source, and a partial read is the defect that is hardest to see later.
Bind the completed export by its own identity plus the digest of its bytes:
"snapshot": {
"version_id": "<the snapshot or export identity your project recorded>",
"content_sha256": "<the digest of the exported bytes>"
}
Where the source is a table snapshot, use the snapshot's own identity. Where it is a scheduled export, use the export's completion identity. Either way the digest is what proves the run read those bytes. See how to pin a snapshot that cannot change.
Credentials
input.credential_ref names a credential you registered under sources. It is a reference, never a secret value, and you can test it, read it back and revoke it at any time.
Project credentials stay in your own tooling. Never place a service account key, a token or a signed URL in a work request, a support message or a shared example.
Formats and limits
Name a released profile in input.format, and name the row identifier in item_id_field. Nested and repeated fields need the profile checked first, because a struct where the workflow declared a flat field is refused rather than flattened for you.
The maximum item count for a workflow is stated on its descriptor and repeated on your quote. Read how a table should be prepared before a first large run.
Commit the output
Accepted rows are written to data/part-* and result-manifest.json is written last, binding every file, count and schema in the bundle.
You then have two honest choices, and they are different acts:
- Download the accepted parts and load them yourself, then compare your loaded row count against the manifest count.
- Register a destination, so delivery is verified before it is committed. Delivery moves
PLANNED,AUTHORITY_READY,WRITING,WRITTEN_UNVERIFIED,VERIFIED,COMMITTED, thenCUSTOMER_ACKNOWLEDGED.
Nothing is a completed load until you have reconciled a count you read against a count the manifest states.
What is not supported
Lithi is not a BigQuery client and claims no wire, SDK or endpoint compatibility with it.
Outside the adapter:
- Executing SQL, views or scheduled queries in your project.
- Reading a table directly while it is still receiving writes.
- Streaming buffers, or any export you have not confirmed complete.
- Any write into your project that bypasses your own access controls.
If a destination write conflicts, delivery reports COMMIT_CONFLICT with a next action rather than overwriting. Resolve the conflicting target, then retry the delivery without rerunning the job.