Every normative statement in this specification that can be checked has a requirement ID (see Conventions). Conformance is defined per class of implementation and checked by a validator and a corpus of fixtures. “Partial implementation” is not a conformance level.

​
Conformance classes

An implementation may belong to several classes; it conforms to each separately. ASR-650 A conformance claim MUST state:
  • the conformance class or classes, and the format versions;
  • for producers, converters and recorders: the profiles claimed and the extensions emitted;
  • for converters: each source format and agent version range qualified, with the losses declared for each;
  • for recorders and observers: the source protocol and version;
  • for readers: the major versions supported;
  • for exporters: the target formats with their companion document versions, and the redaction policies applied;
  • the tagged validator release, validator stamp and golden-corpus revision used to test the claim.
ASR-651 A claim covers every requirement that applies to its classes and claimed profiles. An implementation that fails an applicable requirement does not conform; it may not claim conformance “except for” some requirements. ASR-652 A converter’s claim for a source format and agent version MUST be backed by at least one sanitized fixture captured from that agent version. Synthetic fixtures alone do not qualify a version, and a known failing fixture for a version overrides passing ones. ASR-653 Recorder and Observer claims MUST name their source protocol and version, and their qualified agent versions. The ACP requirements apply only to ACP recorders. Observers follow the Producer requirements, distinguish coverage of events from coverage of payloads, and use capture scope for positional identities, not for every identity.
Design note. A support claim needs evidence from the real producer version it names: native formats change between releases, and a converter that passes on one version can silently misread the next. That is why qualification is per agent version and backed by real, sanitized sessions.

​
The validator

The reference validator checks streams and bundles against this specification. It applies the JSON Schema (schema.json) to single records, and stream-level checks to everything marked “semantic” in the table below. ASR-654 A validator MUST report schema errors, semantic errors, unsupported features or resource limits, warnings, and notices separately. Unknown optional extensions produce non-blocking notices. When required extensions are unsupported or resource limits are reached, validation is incomplete. Neither condition proves that a stream is invalid. Each result MUST name its requirement ID and, where it concerns a line, the 1-based line number. By default, a validator SHOULD group findings by severity, requirement, field and target session, with counts and a few line numbers. Complete findings MUST remain available in machine-readable form. Every warning group explains what to investigate. Run summaries MUST count errors, warnings and notices, including suppressed availability notices. ASR-658 A failure of a checkable MUST requirement is an error, regardless of other severity rules. Missing-manifest entries, losses and gaps never excuse failures to resolve required references, duplicate identities or conflicting inventory. Specific suspicious conditions that have no explanation produce warnings. Optional targets covered by a scoped gap produce notices. For external sessions that a bundle does not account for, the validator produces one notice per target, with reference counts. Standalone streams produce one summary notice: N references to M sessions outside this stream. Optional targets accounted for as missing or intentionally external produce no diagnostic by default, but the validator still checks and counts them; --all-diagnostics or --lint reports them. Unsupported optional extensions produce one notice per extension per run, retaining version and capability information. A permitted torn tail in a standalone stream is a notice; a torn tail in a bundled stream is an error under ASR-025. ASR-659 Every validation run and receipt MUST include a stamp naming the validator version, specification commit, dirty-tree state and digest of the actual implementation, schema, registry and specification bytes. Qualification reports MUST name a tagged validator release. The reference validator’s stamp also reports runtime.node and runtime.ajv. Both versions are inputs to ruleDigest, so identical source bytes on different runtimes can produce different digests. Receipts and cross-batch inventories can be reused only when the digest matches, which means the runtime versions must match too. ASR-660 Cross-batch indexes MUST bind identities to exact stream and capture digests and the rule digest. Capture-local identities MUST NOT resolve against another capture. Indexes establish inventory availability only; they are not semantic validation or trusted attestation. Conflicting captures MUST be reported, not silently selected. ASR-655 A validator MUST check every schema and semantic requirement that applies to a stream as declared (its format version and its effective profiles at each record), and MUST NOT report a stream as valid when any such check fails. ASR-656 For conformance fixtures, a validator MUST be able to emit its results as a JSON array of {"requirement": "ASR-NNN", "line"?: <n>, "severity": "error" | "warning" | "unsupported" | "notice", "message": "<text>"}, sorted by line and then requirement ID. Findings about target availability use ASR-079 and retain originatingRequirement, field, referencePolicy and targetSession. Findings about contradictions retain their own requirement ID. --all-diagnostics --format json supplies the full array; the default JSON report includes groups, counts and the validator stamp. Passing the validator does not make a file safe to share. Neither stream checks nor producer tests guarantee that every file is free of secrets or complete. Synthetic fixtures do not qualify a producer version (ASR-652). Fixture-checked requirements are covered by the golden corpus rather than by the validator. Every example in this specification is validated in CI.

​
Golden corpus

The golden corpus is the set of fixtures used to test implementations against this specification. It has two parts. Real sessions. Sanitized real sessions from at least ten harnesses, including Claude Code, Codex, Gemini CLI, OpenCode, Pi, Copilot CLI, Cursor, Goose, OpenHands, Cline and Zed. Each fixture records the agent version that produced it. Version 1.0 requires that two independent converters for the same five harnesses produce the same native destinations for the same qualified formats and mappings on the corpus. Adversarial fixtures. Constructed streams and native inputs that exercise the hard cases:
  • Active path and context view: linear sessions; mechanical siblings (parallel tool calls, split responses, concurrent attachments, retries after failures); real branches (edited prompts, regenerations, edits of the first prompt); rewinds, including to null; multiple heads; unknown predecessors; gaps and malformed lines on a path; predecessor cycles.
  • Revision chains: superseded results, plans, terminals, subagents and deliveries; entity refs and record-ID refs to revised entities; a record superseded twice (invalid); marked rewrites that move to a new branch, and a rewrite without supersedes (invalid).
  • Terminals and hooks: terminals outliving their creating call, read by later calls, with output in blobs; a background agent recorded as a subagent, not a terminal; hook runs with separate output streams and a setup hook.
  • Turns and triggers: a trigger on the first record of a turn, on a later record (invalid) and on a record without turnId (invalid); scheduled prompts whose author stays harness; turn links to another session, and a recorded link that does not resolve, kept with a warning; attempts, retries and usage-limit errors.
  • Messages: part-level author, origin and phase with and without message-level values; withdrawn queued input left out of the context view; inter-session messages with addresses scoped by a session; senders whose kind is unknown; a missing role with capture.role.
  • Approvals and questions: compact decisions on results, the same decision recorded both ways (invalid), separate reviews and resolvers, allow_session, decisions by another agent; questions with options, typed answers and answers given later as messages; a secret request whose value must not appear anywhere in the bundle.
  • Messaging: participants with a basis, senders by participant, conversations and platform IDs, deliveries that were sent, suppressed and failed, a message without a delivery, metadata-level streams with keyed identity digests.
  • Memory and configuration: memory writes from explicit events and from documented memory files, a requested forget without an outcome, configuration snapshots with absent members, a snapshot placed too early (invalid), capability changes.
  • Declarations: profiles added mid-stream, contentLevel tightening and an invalid loosening, roots declared late, writer handover.
  • Copies and wrappers: copiedFrom with each proof, copies within one stream, declared inherited prefixes, referenced and rendered inheritance, unknown originality; a wrapper stream with executedBy whose own records keep their originality; a mirror stream; wrapper and backing usage counted once.
  • Compaction: every kind; throughId with keptFromId and insertAt; ids overlays; retained records, some shortened, before a summary; an unknown replaced range; a branch_summary over an abandoned branch; failed compactions; destroyed history with a gap.
  • Tools: duplicate native call IDs, orphan results, dangling calls, unresolved permissions, provider identity forms on calls and results, calls requested by code with and without a recorded parent call.
  • Usage: each cache inclusion rule, cache writes by TTL, inconsistent native TTL counts (warning), invalid producer arithmetic checked against source fixtures, cumulative summaries, tree coverage, parent and child totals, quota windows, a model taken from the turn’s configuration.
  • Request context: prefix chains, a prefix that is missing or too short (invalid), an unavailable blob, and when a request may be shown as exact.
  • Physical format: incomplete final lines (torn tails), malformed middle lines, blank lines, non-consecutive seq, bundle manifests with missing sessions, wrong digests, unsafe paths.
  • Identity: session references with namespaces and percent-encoding, agent aliases, capture-scoped IDs.
  • Extensibility: unknown record types, members, enum values, content parts and extensions, including required extensions.
  • Privacy and security: metadata-level streams, per-record redactions, redacted roots, archive extraction attacks, oversized lines.

​
Fixture layout

Each fixture is a directory:
active-path.json and context-view.json are objects keyed by head ref ("default" for the default head). Each value is the array defined by ASR-376. For reader algorithms that cannot make an input stream invalid, fixtures use separate expected/rejected-views.json counterexamples. These are invalid reader outputs, not invalid input streams. Each semantic requirement has valid and invalid input fixtures, or a valid reader output and a rejected output when it specifies a reader algorithm. ASR-657 Producer qualification fixtures MUST compare raw native fields and registry destinations against the output, including fields a replay deserializer would drop. For ASR-283, stream checks cover answers marked as secret; source fixtures check that the known synthetic secret is absent everywhere, including native data and blobs. For ASR-568, stream checks cover digest syntax; source fixtures verify HMAC use and consistent identity mapping with a test key. For ASR-522 and ASR-422, stream checks cover rewrite and mirror shape; source fixtures establish the native rewrite and whole-stream copy evidence. For ASR-333, reader checks cover resolvable complete prefix chains; source fixtures establish that complete: true describes the whole native request. ASR-326 source fixtures check reported counts and producer arithmetic separately.

​
Requirement table

The table lists every requirement in this specification. “Check” is the check type defined in Conventions.