ASR has to evolve without breaking archives. The rules on this page follow lessons from the Model Context Protocol (MCP) and the Agent Client Protocol (ACP): namespaced extension data instead of new root fields, open enums with a reserved vendor prefix, a short and explicit rule for what enters the core, and a deprecation lifecycle that never makes old files unreadable.

What the core includes

The 0.1 draft is fitted to four priority tools: Claude Code, T3 Code, Codex and OpenClaw. A field or record type is in the core when at least two of these tools record the fact it holds. A fact that only one of them records is in the core only when it is the only way to keep a concept ASR already has, and the reason is written below. Every other fact a source records has a documented destination in the agent’s registry entry: a _meta key on the nearest record (preferred), or a vendor record type. Each registry entry lists, in a table of native facts without a standard field, the native name and its destination. Nothing a source records is dropped for lack of a field. Redaction (ASR-559) and the rules that keep secrets out of records (ASR-283, ASR-189, ASR-712) still apply to these destinations. Features that are not ready are left out of the specification, not marked experimental. The Overview lists them. ASR-618 A converter MUST put native facts at the destinations documented by the agent registry. A native fact the registry does not list goes under the agent’s reverse-DNS namespace at the registry’s remainingFields destination, or in a vendor record with native.record or native.blob. Bookkeeping about how the data was acquired, and losses that are specific to one converter, go under the producer’s namespace. Two converters of the same qualified source format and mapping use the same native destinations; their bookkeeping need not match.

_meta

Vendor data goes in _meta, an object whose keys are namespaced.
ASR-600 _meta, where present, MUST be an object. It MAY appear on a record and on any object this specification defines. Each key MUST be either a reserved key (ASR-601) or a reverse-DNS name (ASR-056) followed by / and a name matching ^[A-Za-z0-9][A-Za-z0-9_.-]*$. ASR-601 The keys traceparent, tracestate and baggage are reserved for W3C Trace Context values, as in MCP and ACP. They MUST appear only in a record’s top-level _meta, and their values MUST be strings in the W3C formats. ASR-602 Reverse-DNS prefixes whose second label is agent-session (for example org.agent-session/…) are reserved for this specification. Vendors MUST NOT use them. Values in _meta can be any JSON value. They are claims made by whoever wrote them and carry no authority (ASR-521).

Vendor record types

A vendor record type is a reverse-DNS name, /, and a name: dev.zed/agent_switched (ASR-101). Vendor types are audit-only (ASR-114). Readers that do not recognize one skip it, and storage tools preserve it (ASR-113). A native producer (one that writes its own log directly in ASR format, adoption level L2) uses vendor types for anything it does not want to normalize into ASR’s standard types and fields, rather than writing a second log.

Enums

Every enum in this specification is open: values beyond those listed may appear. ASR-619 A field is an open enum only when ASR defines values that consumers interpret as categories or states. A field that carries the source’s vocabulary without such ASR meanings is a native string. Producers MUST preserve native strings verbatim. When normalizing to an ASR enum, producers MUST preserve the original native value in native or a documented _meta destination. They MUST keep an unmapped native value in native or a documented _meta destination; they MUST NOT invent a vendor value by adding _ to it. A documented vendor enum mapping remains allowed. state.stopReason, state.error.class, checkpoint.status, permission.status, decision and option kinds are open enums with the meanings defined on their pages. compaction.reason, inference.stopReason, permission.reason, reviewer verdict, participant identity basis, config_change.effort, mode, permissionMode, sandbox.mode, tool names, memory store names, model and provider names are native strings. Lists of examples for native strings do not constrain their values. ASR-603 Vendor enum values MUST begin with _ and SHOULD have the form _<reverse-dns>/<name>, as in ACP v2, so that ACP vendor values pass through unchanged. ASR-604 Producers MUST NOT write an enum value unless it is defined by the declared formatVersion or begins with _. Such values are reserved for future versions. ASR-605 Readers MUST NOT reject a record because an enum value is unknown. They interpret an unknown value as the field’s “unknown” or “other” meaning where it has one, and storage tools preserve it unchanged.

Extensions

The header’s extensions array (amended by declaration) lists the extensions a stream uses. An extension is a set of vendor record types, _meta keys, enum values or profiles, documented and versioned by its owner.
ASR-606 Each extension entry MUST contain id, version and required. ASR-607 A producer MUST declare an extension with required: true when a reader that ignores it would misinterpret core records. It SHOULD declare every extension whose types or keys it writes. ASR-608 A reader that does not implement an extension declared with required: true MUST report that it cannot fully interpret the stream. It MAY still display the stream. A feature moves from an extension into the core only under the rule in What the core includes.

Profiles

A profile is a promise: whenever this kind of event happens in the source, the producer emits the corresponding record, or an explicit capture state, gap or declared loss. It is not a claim that such records are present: a session with no commits can still claim coding, and a session that received no chat messages can still claim messaging. A profile never asks a producer to record a fact the source does not record. context is not a profile in this version. instructions, config_change, permission, input_request, plan, terminal, hook and inference.context are optional: a producer that emits them follows their requirements, without claiming a profile. ASR-609 A producer that claims a profile MUST, whenever the source records an event the profile covers, emit the corresponding record, or record the loss with a capture state, a gap, or a declared loss category. ASR-610 Vendor profile names MUST begin with _.

Requirements by profile

Requirements for readers, exporters and storage tools apply by conformance class (see Conformance). For producers, a profile claim brings in these requirements:

Versioning

formatVersion is MAJOR.MINOR. A minor version only adds optional fields, record types and enum values. Anything else (a new required field, a changed meaning, a removal) is a major version.
  • This draft is 0.1. Version 1.0 is the first stable major; a central, tested migration tool will convert 0.x streams.
  • The specification document has its own revision, separate from formatVersion. Editorial changes do not change the format version.
  • One JSON Schema is published for each format version: schema.json. Every feature in this specification is in it. There is no experimental tier and no second schema.
  • While the format is a 0.x draft, any feature may still change, and 0.x streams may need migration (see Overview).
ASR-611 Readers MUST declare which major versions they support, and MUST fail explicitly on a stream of any other major version rather than interpret it. ASR-612 Readers MUST accept a stream of a supported major with a higher minor version than they implement, handling unknown members, types and values by the preservation rules below.

Deprecation

Features move through three states: Active → Deprecated (for at least 12 months, listed in the specification’s deprecated-features list) → Removed. “Removed” means writers stop emitting the feature. Archival readers keep accepting it. ASR-614 Writers SHOULD NOT emit a deprecated feature, and MUST NOT emit a removed one. Readers MUST keep accepting removed features in streams whose formatVersion defined them.

Reader and storage obligations

A session record passes through more tools than a wire message: converters, storage, redactors, indexers, viewers. Tools that store or rewrite streams in ASR format must not lose what they do not understand. ASR-615 Storage tools (tools that store or rewrite streams in ASR format) MUST preserve unknown members, record types, enum values, content parts, _meta entries and native members unchanged, except where a redaction policy removes them (ASR-560). ASR-616 Storage tools MUST keep streams of unsupported major versions as opaque bytes, and MUST NOT drop or rewrite them. ASR-617 Renderers and exporters to other formats are not storage tools. They MAY drop what they do not understand, but an exporter MUST NOT claim the output is a complete representation of the stream when it dropped content.