> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Output rules & limits

> Per-verdict tgt outputs, supported file formats, inspection limits, processing order, and retention for Starfort batch S3 jobs (Starfort v1.4 docs)

## Per-verdict output rules

When a job finalizes, what lands at the `tgt` location depends on the verdict:

| Verdict    | Meaning                                             | What's written to `tgt`                                                                                |
| ---------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| **PASS**   | Nothing detected (or only passing policies matched) | A copy of the original — skippable with `options.on_pass: "skip"`                                      |
| **MASK**   | Maskable items detected                             | **A masked file rebuilt in the same format as the original** (e.g. a `.docx` becomes a masked `.docx`) |
| **BLOCK**  | A blocking policy matched                           | Nothing — the blocking reason is available via [job status](/en/v1.4/api/batch/jobs)                   |
| (`FAILED`) | Inspection not completed                            | Nothing — partial outputs are forbidden                                                                |

Leaving PASS at its default (write a copy of the original) lets a downstream pipeline proceed off `tgt` alone, regardless of verdict.

<Note>
  **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."**
</Note>

## Supported file formats

| Category                | Formats                                                                                                               |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Documents               | `.pdf` `.docx` `.xlsx` `.pptx` `.txt` `.md` `.csv` `.tsv` `.html` `.json` `.rtf` `.odt` `.ods` `.odp` `.epub` `.hwpx` |
| Images                  | `.png` `.jpg` `.gif` `.bmp` `.tiff` `.webp` `.avif` `.heic` — masked by covering detected regions at the pixel level  |
| Archives                | `.zip` — each inner file is inspected and masked, then re-packed into a zip                                           |
| Images inside documents | Images embedded in documents are inspected and masked too                                                             |

* 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](/en/v1.4/api/multimodal).
* **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](/en/v1.4/api/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](/en/v1.4/admin/monitoring-opticon) 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.