Planned
Batch processing is designed, not built.
There is no queue to upload to yet. Rather than collect emails against a date we cannot name, here is the exact shape we specified, what runs today instead, and where the gap is.
Batch queueSGT-2608-E5B0 · 6 sourcesExample4 of 6 completePLANNED
SourceTypeStatusVerdictLikelihood
q3-report.docxTEXTDONEAI-GENERATED86 [79–93]
landing-copy.mdTEXTDONEHUMAN18 [11–27]
token-cache.tsCODEDONEMIXED55 [41–68]
example.com/blog/postURLDONEAI-GENERATED80 [72–88]
interview-notes.pdfTEXTRUNNING——
example-frame.pngIMAGEQUEUED——
Example report — fixed sample data, not a live analysis. No queue accepted these files; this is the view as specified, rendered from the same report parts the shipped modalities use.
What you can run today
- One file at a time, in the app
- Text and URLs return the full report — flagged spans, weighted signals, a confidence range. Code returns measurements without a verdict.
- Many files, through the API
- One request per file against POST /api/v1/detect, which is how volume works today. The report you get back is the same one the app renders.
- Image and video, one file at a time
- Both lanes run today. Image leads with a signed C2PA manifest and reads the pixels underneath it; video reports everything the file can prove and returns an uncertain verdict unless a manifest settles it. Neither is queued, because nothing is queued yet.
What the queue will do, when it exists
- One queue per upload, with per-file status and a report permalink for every finished row.
- The same report shape for every modality, so a batch mixing text and code needs no special handling.
- CSV export of the queue: specimen ID, verdict, point estimate and interval per row — never a bare percentage.
None of the three is built. When the queue ships, this page becomes the product page and this paragraph goes away — until then it is the honest status, and the detect endpoint is the thing you can actually build on.