Signal Dataset annotation with `backend: gemini_batch` (2026-08-14)¶

Note

Read for the route, not for the configuration. This run used template caption.dense.v3, which existed on its date. Annotation was later reduced to one template, caption.declared.v1, and caption.dense.v3 is now refused at config validation. What this record establishes is that the snapshot route runs with backend: gemini_batch; copy the template id from Annotation templates, not from here.

The two gemini_batch combinations the snapshot route had never run: locally over a local path and a gs:// root, and submitted as a Dataproc Serverless batch. Three runs, six records each, all first-attempt successes.

Until this record, every recorded gemini_batch run was over a retained store, and the route’s own documentation had twice claimed a snapshot qualification that did not exist. These runs close that gap rather than restate it.

What was run¶

Project rf-foundation-models, region us-central1. Model gemini-3.1-flash-lite, inference.provider: gemini, template caption.dense.v3. A six-record snapshot generated from narrowband-baseline with the channel chain set to awgn_channel at 20 dB.

Run	`execution_mode`	`dataset_uri`	`run_id`	Result
1	`local`	local path	`gemini-batch-local-v1`	6 succeeded, 0 failed, exit `0`
2	`local`	`gs://`	`gemini-batch-gcs-v1`	6 succeeded, 0 failed, exit `0`
3	`dataproc_serverless`	`gs://`	`gemini-batch-dataproc-v1`	6 succeeded, 0 failed, `status: complete`

Run 3 used inference.api_key_secret (projects/rf-foundation-models/secrets/rfgen-gemini-key/versions/latest) and the image pinned at the time, sha256:2d104c1e…, and reached a result in ten polling cycles. An evidence record names the digest it ran rather than “the maintained pin”, because that pin moves. Every run published a dense set: {'success': 6, 'failed': 0, 'skipped': 0}.

Provider prose from run 3, verbatim:

The single emitter observed in this scene exhibits a continuous occupied interval across the entire channel and is characterized by strong SNR. This signal behavior is consistent with 64qam modulation.

and from run 1:

A single emitter is detected occupying the full observed frequency band for the entire observed duration, consistent with 64qam modulation. The signal maintains a strong snr throughout the continuous occupied interval, indicating stable and consistent transmission characteristics during the entire window.

Note

The occupancy wording is a fact-projection artifact, not a measurement. The caption facts normalize the frequency axis to the union of the record’s own bounding boxes, so any single-emitter scene reads as full-band whatever its real occupancy: this capture is 1 MHz of signal in a 2 MHz band. What this run evidences is that the route completed, not that the sentence is true.

What this found¶

A snapshot cannot be relocated with gsutil cp. Run 2 was first attempted against a snapshot copied from the local root with gsutil -m cp -r. Submission refused it before preparing any request:

{"error_code":"invalid_annotation_request","error_type":"CorruptDatasetError",
 "message":"GCS snapshot reference is missing a generation"}

A Signal Dataset root pins the object generations it reads, and a copy gets new ones. The refusal is correct and arrives before any paid work, but the message does not say what to do instead. To put a snapshot in a bucket, generate to the gs:// URI directly, which is what run 2 then did.

Boundaries¶

Six records, one model, one project, one region, one template. Evidence that the combinations work, not a throughput or cost measurement.
gemini_batch here is the Gemini Developer API batch endpoint with inlined requests, not Vertex Batch. Vertex Batch eligibility is a separate question and is unaffected by these runs.
Batch pricing was not measured. The roughly-half-price claim comes from the provider’s published rates, not from an invoice compared here.
Runs were first-attempt successes, so nothing here exercises gemini_batch resume or partial-failure handling on the snapshot route.