ASIF session examples¶

These are complete, synthetic ASIF documents. All conversation, tool activity and model context are authored examples; no real agent run, private transcript or user attachment is represented. The small media files are actual fixture bytes with matching lengths and SHA-256 digests.

For destination reconstruction, see the additional three portable-continuation scenarios: another computer/cloud runtime, another agent, and an unresolved remote operation. Each includes a separate, explicitly synthetic assessment report.

For the benefits behind these records, see use cases: moving work between computers and clouds, collaborating across providers, comparing approaches and handing a project to a teammate.

Example	What to inspect
Agents with different roles	Three fictional providers contribute to one session; writer, reviewer and editor contexts share the same brief while selecting different instructions and prior contributions.
Image and PDF	Ordered text/image/document parts; one image referenced twice; original PDF preserved while extracted text appears in the reconstructed model input.
Audio and transcript	A WAV stored as inline base64; a separate inline text annotation. The sample is 0.1 seconds of silence; the annotation explicitly says there is no speech.
Tool-generated files	Inline CSV input, correlated tool call/result, CSV and Markdown outputs referenced again by the assistant.
Attachment availability	Unavailable PDF, external video, deliberately excluded ZIP and uninspected image. The missing PDF is an explicit continuation prerequisite.
Redacted attachment	Original content marked redacted; a distinct sanitized resource with its own bytes/hash; loss report and explicit substitution in model input.
Compaction with an attachment	Original notes retained in history; a summary memory selected into a separate continuation context.
Awaiting approval	Tool call and approval request without a recorded answer or tool result.
Partial call → completed call	Two captures of the same invocation, preserving immutable partial arguments and stream bytes, then an amendment and a late result.
Task dependencies	Several branch selections show completion, reopened prerequisites, explicit dependent revisions, retirement and a dependency whose state exists only on another branch.
Partial task history	Known current revisions retain unavailable predecessors and unknown prerequisite state without inventing missing history.

Task revisions and dependencies¶

The task dependency example records write depending on task gather. The dependency string selects a task identity; its interpreted revision changes with the selected branch boundary.

Branch	Selected task state	Dependency interpretation
`baseline`	`gather` revision 1 and `write` revision 1 are completed.	`write` → `gather` revision 1 is satisfied according to the record.
`reopened`	`gather` revision 2 is pending; `write` revision 1 remains completed.	The prerequisite is now unsatisfied; the dependent is not silently reopened.
`main`	`write` explicitly reopens at revision 2; `gather` completes at revision 3.	`write` → `gather` now selects revision 3.
`retired`	Alternative `gather` revision 4 is superseded.	The prerequisite is unsatisfied; core semantics do not substitute a replacement task.
`dependent-only`	Only `write` revision 1 is selected.	`gather` exists in the capture, but no revision is selected on this branch. Its dependency state is unknown.

The partial-history example starts at gather revision 7 with predecessor 6 and write revision 3 with predecessor 2. The predecessor events are unavailable. Task coverage is explicitly partial and explains the gaps. The recorded task states are inspectable, but their preceding transitions cannot be reconstructed. gather has unknown status and an omitted dependency list, so neither completion nor absence of further prerequisites is assumed.

The shared task cases exercise both validators, including missing and external-looking IDs, selected cycles, branch isolation, replacement of dependency lists, partial-history gaps and terminal-task reopening. A source exporting unavailable or external task state must preserve evidence and disclose limitations; inventing observed task events is not a valid repair.

.venv/bin/python asif.py validate examples/task-dependencies.session.json
node asif.ts validate examples/task-partial-history.session.json

Tool-call progression across captures¶

The first capture ends at call-partial, with arguments_status: partial, one nonterminal stream segment, and call-1 marked outcome_unknown. The second capture retains that event, its stream, and its fragment resource unchanged. It adds call-complete, whose supersedes points to call-partial, followed by the terminal result-late for the same call-1. A new complete stream reuses the original fragment and adds the final bytes. The proposed context contains one completed typed call input and its result.

Both documents use session-call-progression; their capture IDs differ. The later capture's lineage names the earlier one. This is recorded knowledge of one invocation, not a second execution. A retry would use a new call ID. All evidence is synthetic; neither fixture authorizes execution or claims runtime continuation readiness.

The shared progression cases cover selected and historical branches, competing amendments, late amendment after a terminal result, partial/unknown argument refinement, retry identity, and external-predecessor refusal. Both reference test suites consume the same cases and verify that the earlier capture's events, resources, streams and contexts survive unchanged.

.venv/bin/python asif.py validate examples/tool-call-partial.session.json
.venv/bin/python asif.py validate examples/tool-call-completed.session.json
node asif.ts request examples/tool-call-completed.session.json context-completed

Agents with different roles¶

The multi-agent review session follows a workshop organizer working with three agents. The writer proposes a plan that exceeds the time limit, the reviewer identifies the error, and the editor revises the plan. All provider names and outputs are invented.

Context ID	Participant	Selected inputs, in order
`writer-context`	Writer, `example.provider-a`	Writer instructions; shared brief
`reviewer-context`	Reviewer, `example.provider-b`	Reviewer instructions; shared brief; draft
`editor-context`	Editor, `example.provider-c`	Editor instructions; shared brief; draft; review

Each context contains an identical shared-brief input referencing the same workshop-brief resource. Role instructions are separate, declared configuration records and are explicitly included once in each context. The later inputs reference the earlier contribution events, so you can see what the reviewer and editor were given.

Participants retain distinct IDs and provider labels. Executions bind each participant to its input context; event actor_id and execution_id attribute each response. Writer, reviewer and editor are job assignments expressed by instructions, while their messages all use role: assistant. Execution status remains unknown because no actual runtime lifecycle was observed.

Inspect the proposed inputs with either CLI:

node asif.ts validate examples/multi-agent-review.session.json
node asif.ts request examples/multi-agent-review.session.json writer-context
node asif.ts request examples/multi-agent-review.session.json reviewer-context
node asif.ts request examples/multi-agent-review.session.json editor-context

Replace node asif.ts with .venv/bin/python asif.py for Python. These commands run from the repository root and produce neutral JSON projections. They do not contact providers. The example records a sequential collaboration; scheduling agents, enforcing permissions and coordinating concurrent writes belong to an integrating application.

Attachment representation¶

There are three layers:

A message part refers to a resource and fixes its place among the message's other parts.
The resource identifies the content, media type, purpose, availability and, for embedded content, bytes and digest.
A context input records whether the original attachment, a derivative, or neither was selected for the model.

For example, these are actual excerpts from the image/PDF example, not stand-alone session documents:

{
  "kind": "resource",
  "resource_id": "document",
  "description": "One-page invented meeting notes."
}

The original resource has media_type: application/pdf and path: assets/meeting-notes.pdf. Its extracted text has a separate resource ID, document-text, and provenance naming document. The context explicitly selects that derivative:

{
  "kind": "resource",
  "resource_id": "document-text",
  "description": "Text extracted from the PDF."
}

The input also records the transformation. Preserving a PDF therefore does not imply the model received its original bytes or saw every visual feature in it.

Storage and availability¶

Form	Example	Interpretation
`text`	Input CSV, extracted PDF text, sanitized text, summary memory	Hash the exact UTF-8 encoding, including newlines.
`data`	Inline WAV	Strictly decode base64, then verify length and digest.
`path`	PNG, PDF, output CSV/Markdown, original notes	Resolve relative to the session document's directory; verify before exposing content.
`external`	Video locator	Record location only; this example must not fetch it. The `.invalid` host is deliberately nonfunctional.
`unavailable`	Missing PDF	A reference exists but the source bytes could not be recovered.
`excluded`	ZIP	Deliberately omitted from the export.
`redacted`	Original contact document	Original content is withheld; a sanitized derivative is a different resource.
`unknown`	Uninspected image	The exporter did not establish availability.

Content type does not determine storage: an image could use either base64 or a file path. Original names are descriptive metadata, not automatic extraction destinations. Referencing a resource twice does not duplicate its payload. Different transformed bytes must not reuse the original resource identity.

Physical attachments¶

color-grid.png: synthetic 16 × 16 RGB grid.
meeting-notes.pdf: one-page synthetic text document.
totals.csv: generated-output fixture with total row.
summary.md: generated-output report fixture.
project-notes.md: notes retained after context compaction.

To copy an example elsewhere, copy its JSON document and all resources referenced by path, preserving their relative paths. Inline resources need no extra files. Apart from the explicitly related tool-call captures above, the examples have distinct session IDs and no implied relationship.

Checks and regeneration¶

From the project root:

.venv/bin/python tests/check_schema.py
.venv/bin/python tests/check_examples.py

The second check validates all twelve documents against the schema, verifies embedded resource bytes and references, and checks selected event/branch/context relationships. It also checks that corrupt digests, missing resources and unsafe paths are rejected by the fixture checker. Run .venv/bin/python tests/check_reference.py and npm test for the shared tool-call progression and task cases. These are not complete ASIF conformance or interoperability tests.

python3 examples/build_examples.py deterministically rebuilds the six attachment examples, their five file assets, and the collaboration example. It does not replace the existing approval example, the two hand-authored tool-call captures, or the task examples. All contexts remain explicitly reconstructed; none claims a real provider request or successful continuation.