Interface BulkIngestionJobStatusResponse

Number of provider batches still in flight (created, submitted, or awaiting result reconciliation). THE deferral signal: work is draining through a provider batch right now exactly when this is positive — unlike providerBatchIds, which keeps terminal batches, and unlike transport, which is descriptive metadata. Optional on the wire: consumers must tolerate its absence.

Progress counters aggregated from the job's files and logical requests.

Per-file status, one entry per staged context (bounded by the job's file cap).

The lanes a 'batch' job ROUTES inline — at the synchronous price, within minutes — rather than onto a provider batch: embeddings, whose batches are too small for the discount to beat the queue tail. Absent when every lane batches, and on a 'sync' job (every lane of which runs inline). The job's routing policy, not a record of what ran: a lane handed to the inline transport by a cancelled provider-batch tail executes inline without being named here. Descriptive metadata, like transport.

Coarse answer to "what is this job doing right now": awaiting-provider-batch while the PROVIDER is working — an intent or submitted batch (deferred OCR included; it wins whatever stage the files carry) or batch-route work still queued for submission — extracting while files still await or undergo extraction with no submitted batch, and indexing otherwise (inline/flex requests executing, ended batches' results being absorbed, contexts being written — our own work, however long it takes). Present only while the job state is running; the other non-terminal states (finalizing, cancelling) already name what the job is doing. Optional on the wire: consumers must tolerate its absence.

Per-batch detail for every provider batch of the job, so a caller can tell a healthy wait on a submitted provider batch from a stall — and see since when. A SUPERSET of providerBatchIds, not index-aligned with it: an intent batch appears here with no providerBatchId while that list omits it. Optional on the wire: consumers must tolerate its absence.

Provider batch ids created for this job, across every batch state — including already-drained ones.

Provider-side progress of the job's batches, so a saturated in-flight budget the provider is draining reads differently from one it completes nothing in. Present only while a 'batch' job is running. Optional on the wire: consumers must tolerate its absence.

The job's lifecycle state (e.g. running, completed, failed, cancelled).

The job's execution transport: 'batch' rides provider batches (half price, tails up to 24 hours), 'sync' executes inline within minutes. Decided at staging from the job's size, with one transition — a defer-eligible job whose OCR routing lands on the provider batch is promoted 'sync' to 'batch' — and held from then on. Descriptive metadata ONLY: it says how the job runs, never whether a batch is draining right now, so it must not gate any wait/timeout policy; that is activeProviderBatchCount. Optional on the wire: consumers must tolerate its absence.