Skip to main content

​
Per-verdict output rules

When a job finalizes, what lands at the tgt location depends on the verdict: Leaving PASS at its default (write a copy of the original) lets a downstream pipeline proceed off tgt alone, regardless of verdict.
Safety principle (fail-closed) — when a masked file can’t be rebuilt safely, the file is treated as BLOCK. A failed job writes nothing, and tgt writes are finalized atomically (a half-written file never appears). In other words, a file that arrives at tgt is always “either it passed inspection, or it’s fully masked.”

​
Supported file formats

  • The formats actually allowed are decided by project settings (the table above is the full supportable range). Formats outside the settings are rejected or excluded from inspection per the project’s unsupported-file handling policy.
  • Disguised files — where the extension and the actual content (file signature) disagree — are rejected.

​
Limits

File-size and text-length limits follow the project’s configured values, and enforcement is at a single point: the Guardian — the same limits apply not just to the top-level file but to text extracted from it and to archive contents. Exceeding a limit finalizes the job as failed with FILE_TOO_LARGE / TEXT_TOO_LONG (see Batch errors). Because input arrives by bucket reference, there’s no file in the request body — so the inline API’s intake ceiling doesn’t apply. Size control collapses to a single knob: the inspection limits.

​
Processing order

Batch jobs are processed in intake order (FIFO). There is no priority tier, and concurrency scale and queue caps are operational values.

​
Data retention

  • No content retained — originals and output content are handled only during processing and never stored in the job record. The job record carries metadata only: paths, verdict, detections, error.
  • Job records are short-lived — the job record backing the status API is a short-term record for operational queries and src-search recovery; retention and cleanup cycles follow operational policy.
  • Long-term history lives in Opticon — batch processing is recorded as Opticon traces too, carrying the intake details (job_id · src_s3_url · tgt_s3_url · process_type) along with the verdict and any error. When you need to look up past jobs, Opticon is the surface.