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

# Agent package conformance

> Check that a built agent package provably meets the agent spec — a fast, deterministic gate between Build and Dry Run that needs no API key.

Conformance checks that an agent package you've built meets the JoyStream agent spec (currently v0.5) before you run it against anything real. It reads your package, compares it against a vendored copy of the spec, and prints a list of flags: concrete, cited problems, each tied to a specific spec clause.

It is detection only. Conformance never edits your package and never blocks you outright. It tells you what's wrong, and you decide what to do.

## Where it fits in the lifecycle

```mermaid theme={null}
flowchart LR
    A[Plan] --> B[Build] --> C[Conform] --> D[Dry Run] --> E[Pilot] --> F[Live]
    style C fill:#FB6B36,color:#1a1714
```

* **Plan** — draft the agent spec with `jstm agent plan`.
* **Build** — compile the spec into a runnable package.
* **Conform** — prove the built package meets the spec with `jstm agent conform`.
* **Dry Run** — execute with no production side effects.
* **Pilot** and **Live** — limited, then full production traffic.

Conform is the cheap checkpoint right after Build. It catches a malformed manifest or a spec violation in milliseconds, before you spend time or tokens on a dry run.

## The three lanes

Every flag is tagged by the lane that raised it. Lanes differ in authority.

| Lane            | What it checks                                                                                                                                | Authority                                           | Default severity                          | Needs an API key |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ----------------------------------------- | ---------------- |
| `schema`        | Deterministic structure: manifest fields, enums, ranges, required sections, file references, JSONPath parseability                            | Authoritative, zero false positives by construction | `error`                                   | No               |
| `spec_conflict` | Known contradictions or stale residue in the spec itself, surfaced so canonical examples aren't mistaken for a clean oracle                   | Advisory                                            | `warning`, some rules override to `error` | No               |
| `judge`         | Semantic coherence: does the purpose match the skills, is the soul consistent, do triggers match skills. Each finding carries a spec citation | Advisory                                            | `warning`                                 | Yes              |

The CLI runs the two deterministic lanes, `schema` and `spec_conflict`, so `jstm agent conform` needs no API key and no network. The semantic `judge` lane is optional, runs only where a key is configured, and is intentionally omitted from the CLI today.

## What you get

A single merged report. Each flag carries:

* A stable id, so you can suppress it and it stays suppressed across runs.
* Its lane (`source`), `severity`, and `rule_id`.
* The target it lands on, such as `manifest.lifecycle`.
* A spec citation (`spec_anchor`) and a plain-English rationale.

The run ends with an exit code — `0` pass, `1` fail, `2` usage error — so the same command works for a person at a terminal and as a CI gate, with no rework.

## Spec packs are versioned and hashed

A spec version is its markdown corpus, examples, and rule catalog, identified by a content hash such as `v05@84aa360f…`. Conformance always checks against an explicit version (`--spec v0.5`), never an accidental "latest". When the vendored spec is refreshed its hash changes, which is how downstream acknowledgements know to re-evaluate. Checking a v0.5 package against a future v0.6 is a deliberate migration mode, never a silent drift.

## See also

* [Reading the flag report](/features/conformance/flag-report) — how to interpret the output.
* [Acknowledging flags](/features/conformance/ignores) — the ignore and allowlist workflow.
* [Conform an agent package](/guides/conform-an-agent-package) — task walkthrough.