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.

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

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.