# Concepts

> Source: https://pixelsystems.com/docs/concepts


Core entities in the Pixel Systems API and how they fit together in a verification workflow.

## Job

A **job** groups one or more files submitted for verification in a single unit of work. Each job has a unique `jobId` and optional `metadata`. The API returns a job as a single [`JobResult`](https://pixelsystems.com/docs/api/resources#jobresult) envelope: a job-level `status` (`processing`, `completed`, or `error`) derived from the results, and one [`FileResult`](https://pixelsystems.com/docs/api/resources#fileresult) per file in `results[]`, each carrying its own `status` and, once completed, its [`verdict`](https://pixelsystems.com/docs/api/resources#resultverdict) and dimensions.

The fastest flow is one call to [Assess a file](https://pixelsystems.com/docs/api/assess) (`/v1/assess`), which creates the job, uploads the file, and waits for the verdict. To read a result later, [poll the job](https://pixelsystems.com/docs/api/get-job) until its status leaves `processing`. For quick uploads without code, use [drag-and-drop in the dashboard](https://pixelsystems.com/docs/no-code/drag-and-drop), which creates the same jobs without an API key.

**Jobs are used to:**

- Group related files and shared metadata for a case or batch
- Track per-file analysis status and results

## File

A **file** is one uploaded asset on a job: an image or a PDF. Each file has an `id`, `name`, `type`, and `size`, and is analyzed independently.

The API accepts images in JPEG, PNG and [HEIC/HEIF](https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format) formats, and documents as PDF. An image must be at most 25&nbsp;MB, at least 768px on the shorter side, and at least 0.5 megapixels for reliable analysis; a PDF must be at most 2&nbsp;MB. Each application runs one [pipeline](#pipeline), which analyzes one kind of file, images or PDFs, and accepts only that kind. A file of another kind is refused with `unsupported_format`.

Files are analyzed independently, and the API reports one job-level `status` derived from the per-file results: a job stays `processing` until every file's analysis finished, then reports `completed` (or `error` if any file failed). Each file's entry in `results[]` carries its own `verdict`; there is no job-level verdict, because two files in one job can reach opposite assessments.

## Application

An **application** is a workspace inside your organization. It isolates jobs, files, API keys, and settings. Every API call is scoped to an `applicationId`. Team membership is managed at the organization level.

Organization admins create applications from the dashboard.

**Applications are used to:**

- Separate environments or client projects within one org
- Scope API keys and job history
- Carry the pipeline (set when the application is created) and application settings

## Pipeline

A **pipeline** is the set of checks Pixel runs on every file an application submits. Each application has exactly one, set when the application is created. To change it, contact support.

**The pipeline determines:**

- Which file types the application accepts
- Which dimensions appear on a result
- Which verdicts a job can return

**Three pipelines are available:**

- **AI detection.** Checks whether an image was generated or edited by AI. Returns AI generated, authentic, or inconclusive.
- **E-commerce.** Checks that a photo is an original camera capture rather than a screenshot, an image already published elsewhere online, or an AI generation. Returns verified, not verified, or inconclusive.
- **Document authenticity.** Checks PDF documents for signs of tampering and AI-written text, and reports what the document metadata says about its origin.

The dashboard shows which pipeline an application runs.

## Expert review

An **expert review** is a second opinion on a completed job from a Pixel verification specialist. It is enabled per organization. [Contact us](https://pixelsystems.com/contact) to add it to yours. When enabled, request one from the job in the dashboard, optionally adding a note for the specialist. Reviews your organization has already received stay visible either way.

The specialist can override the overall verdict, individual result dimensions, or both. The automated result is never modified: it stays stored and visible next to the specialist's findings, in the dashboard and in the API alike.

**Where the review appears:**

- **Dashboard.** The job shows the request's status and, once resolved, the specialist's findings alongside the automated results. When the specialist overrode the overall verdict, that verdict becomes the headline; findings on individual dimensions appear beside those results, with the automated value kept visible.
- **API.** In [Get a job's result](https://pixelsystems.com/docs/api/get-job) (`/v1/jobs/{jobId}`) and [Assess a file](https://pixelsystems.com/docs/api/assess) (`/v1/assess`) responses, the reviewed file's entry in `results[]` carries an [`expertReview`](https://pixelsystems.com/docs/api/resources#resultexpertreview) field with the request's status and, once resolved, the specialist's findings, confidence, and note. The result's `verdict` keeps returning the automated result, so existing integrations are unaffected. Read `expertReview.result` to apply the specialist's correction.

## API key

An **API key** authenticates server-side requests to the Pixel Systems API. Generate keys per application from the dashboard. API access is enabled per organization; see [Authentication](https://pixelsystems.com/docs/api/authentication#api-keys).

> **Keep API keys on the server**
>
> Never expose API keys in browser code or public repositories. Rotate keys if they are compromised.

Send the key as [`Authorization: Bearer <api_key>`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization) on every request, for example when submitting a file for assessment or reading job results.
