Skip to main content
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

  • 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. 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