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

# Concepts

> Understand controlled assessments, evidence-backed findings, and durable Run workflows.

These are the terms used throughout the Developer Docs.

## Assessment and Run

An **assessment** is the authorized intent: an organization, one or more approved targets, a model,
optional Skills, and Guardrails. A **Run** is its durable record, holding lifecycle state, ordered
events, guidance, and findings.

One assessment should serve one coherent objective. A Run can cover several approved targets, but
combining unrelated objectives makes its evidence harder to review and assign.

## Target and Guardrails

A **target** identifies a system to assess. Antigen approves targets per organization, and approval
is evaluated when a Run is created.

**Guardrails** are natural-language scope instructions passed to the model with the Run. The
distinction matters: Guardrails shape how the agent works, while the approved target list is the
enforced boundary. Guardrails alone do not authorize anything.

Resuming a stopped Run does not re-evaluate target approval. Confirm the scope still applies before
resuming, and cancel the Run to withdraw a target from work already under way.

## Skill

A **Skill** is a Markdown document supplied with a Run as additional application input, named and
passed through to the model. The SDK's Agent facade and the CLI read Skills from local paths; the
HTTP API and `runs.create` take their content inline.

Treat Skills as reviewed application input. They are not a security boundary, so keep credentials
out of them.

## Event

An **event** is one ordered observation of a Run, carrying a monotonic `sequence`, a `summary`, a
timestamp, and a type: progress narration, a recorded finding, a lifecycle transition, or an error.

The `sequence` is the checkpoint your client persists. Store it only after handling the event, and
resume strictly after the last one you finished.

## Finding

A **finding** is a durable result bound to one Run. It carries severity, title, description,
remediation, and available evidence.

Findings support evaluation and prioritization; they do not replace a human risk decision. A
completed Run with no findings is a valid outcome.

## Lifecycle

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
creating -> running | failed | cancelled
running  -> stopping | completed | failed | cancelled
stopping -> stopped | failed | cancelled
stopped  -> resuming | cancelled
resuming -> running | failed | cancelled
completed, failed, cancelled -> terminal
```

`stopped` is resumable. `completed`, `failed`, and `cancelled` are terminal, and `failed` differs
from `cancelled`: one is an execution outcome, the other a decision someone made.

Stopping is cooperative rather than immediate. The request asks the Run to wind down and snapshot its
work, so a Run sits in `stopping` until that completes. If the stop cannot be delivered, the Run stays
in `stopping` and the service keeps working on it: an undeliverable stop is not reported as `failed`,
because that would turn a transient problem into a terminal state and lose the ability to resume.

## Authorization

A Run ID is a locator, not a credential. Every request is evaluated in the caller's organization
context, so holding an ID grants nothing on its own. This is why the correct response to a
permission error is to fix the permission, never to create a second Run.