This page follows one short coding session: a user asks an agent to fix a failing test, the agent runs the tests, edits a file, runs the tests again and commits. The session was converted from a harness’s native log, so the record also shows what a converter declares about its own losses. The tour is illustrative. Some records are omitted for brevity, and the specification is normative wherever the two differ.

The header

Every stream starts with a session header on line 1.
  • Identity. The session key is agent plus sessionId, the harness’s own ID kept verbatim. Its session reference is claude-code:0f3c2a7e-91b4-4d0e-8f43-2b6c1d7a9e10. See Identity.
  • Provenance. producer.method is converter: a third-party tool read the native log. lossy declares that reasoning signatures were not carried over. There is no trust or fidelity score; provenance comes from the method, from per-field capture states and from per-facet evidence.
  • Lineage. "root": true is an explicit claim that no other session spawned or forked this one. An absent lineage would mean unknown, not root.
  • Workspace roots. Later records refer to files as {root, path} relative to root r1, so the absolute path can be redacted in one place.
  • Profiles are promises about what the producer records. Claiming coding means the producer emits file_change and vcs records whenever edits and commits happen, not that this session contains any.

The prompt and the first model call

  • role says which side of the conversation a message is on; author says who actually wrote it, and origin says how it entered the session. A harness-injected reminder would be role: user with author: harness.
  • An inference record is written only when the source identifies a model call. It is never synthesized from message boundaries. Its usage covers only this call, with cache reads and writes reported separately. See Inference.
  • Records produced by the call carry its inferenceId. The reasoning part keeps its text; the header declares the missing signature as a loss.
  • Order is seq, not ts. Timestamps are optional and are never fabricated; only the user message had one in the source.

A tool call and its result

  • A tool_call means the model requested a call. Its outcome is a separate tool_result, paired by callId. linkage: "exact" says the pairing came from a native ID; a converter that had to guess would say derived or ambiguous.
  • content is what reached the model. Here the harness truncated a 48 KB output before showing it to the model, so the capture state is truncated and the full output is kept as a content-addressed blob.
  • A call with no result is dangling, and its outcome is unknown. A reader never assumes it succeeded. See Tool calls and results.

An edit

  • The file_change record states the effect of the edit separately from the tool call that caused it. precision is required: hunks means the record identifies the changed regions but does not contain the whole file before and after the edit.
  • The tool input still contains an absolute path. Root substitution covers structured paths only, not paths inside tool inputs, commands or output text, which matters when redacting a record.
  • A change made by the user in an editor would have cause: {"actor": "human", "observed": true}. See Coding profile.

The commit

  • evidence: "parsed_output" says the converter learned of the commit by parsing the tool’s output, not by observing the repository. A session that merely mentions a commit did not necessarily produce it.
  • This record is what lets a commit be traced back to its session. The integration companion defines the Agent-Session commit trailer, which points from the commit back to its session.

The end of the turn

  • state records lifecycle transitions when the source emits them.
  • usage_summary carries an aggregate that the harness itself reported, with its scope and coverage. A reader uses either this aggregate or the per-call inference records, never both.

What is not in this record

A reader learns as much from what is absent:
  • There are no subagent, compaction or rewind records, so the active path consists of every message, tool call and result in seq order.
  • There are no participants, conversations or delivery records, because one person is working with a coding agent. An assistant in a group chat would declare the people in the chat and record whether each reply was delivered; the white paper has an example.
  • Some timestamps are missing. They are unknown, not zero, and no converter fills them in.
  • Nothing in the record says whether the session is safe to share. contentLevel: "full" says how much of the session is disclosed, not whether it is safe to share.
To go further, read the specification overview, or the guides for harness authors and tool builders.