Kane CLI Evidence Pack Structure

A .evidence file is an ordinary zip file. Run unzip -l <pack> to list its contents, or unzip -p <pack> <entry> to print a single file without extracting the rest.

The layout

<execution_id>.evidence
├── run.yaml                          # Run manifest: title, status, started/ended, totals
├── failure.yaml                      # Run-level failure rollup
└── tests/
    └── <test-id>/                    # One directory per test in the run
        ├── test.md                   # The test definition
        ├── result.yaml               # Verdict, per-step outcomes, tags, executed-by,
        │                             #   share identifiers, environment (browser/OS/resolution)
        ├── logs/
        │   ├── meta.yaml             # Declares every log file below
        │   ├── tui.log               # Session narrative
        │   ├── <n>-run.log           # Runner log, one set per run index n (0, 1, …)
        │   ├── <n>-actions.ndjson    # Step-by-step actions the agent performed
        │   ├── <n>-console.ndjson    # Browser console output, attributed per step
        │   └── <n>-network.har       # Network traffic (HAR), attributed per step
        ├── steps/
        │   └── <ordinal>-<step-id>/  # One directory per executed step
        │       ├── screenshot.png    # The page as the agent saw it
        │       ├── annotated.png     # Same shot with the acted-on element highlighted
        │       ├── step.json         # Step metadata: kind, status, duration, url,
        │       │                     #   action id, click coordinates, element rect
        │       └── failure.yaml      # Failed/broken steps only: error, page state,
        │                             #   console/network references, triage
        ├── auteur/
        │   └── execution.json        # Full execution trajectory (step.json's action id
        │                             #   joins to operations in this tree)
        └── v16-trajectory/           # Per-run planning summaries and diagrams

In a testrun pack, each test in the suite (each member) gets its own tests/<test-id>/ directory under the same root.

The required files

A validation profile sets which files a pack must contain. L0 is the minimal profile, and it requires three files.

File	Role
`run.yaml`	The run manifest, which anchors the pack. A directory or zip is a pack only if it has a `run.yaml` at the top level. It holds the run’s identity, its lifecycle status, and the totals derived from the results. Being a pack does not mean the pack passes validation. See Validating packs.
`tests/<id>/test.md`	The test definition: what the agent was asked to do. The format treats it as opaque. It references and hashes the file but never parses it.
`tests/<id>/result.yaml`	The structured outcome of each step in that test.

Kane CLI packs validate against L1. Once the run is finalized, L1 requires four more artifacts: each test’s logs/ directory (with its meta.yaml), each test’s steps/ directory, a global coverage/ directory, and the failure.yaml at the pack root.

Reading a pack without unzipping it

The sealed zip is flat. Its entries are exactly the contents of the pack directory, with run.yaml at the root of the archive and no wrapping folder. Each entry is compressed on its own, so a tool can read the zip’s index (its central directory) and then fetch only the entries it needs. This is how the hosted viewer opens a very large pack after downloading only a few kilobytes.

Run status and test verdicts

The format tracks two separate things: where the run is in its lifecycle, and what each test concluded. Run lifecycle, in run.yaml.status:

Status	Meaning
`running`	The run is in progress. Its totals, `ended`, and definition hashes are not final yet.
`finalized`	The pack is sealed. Only this state is authoritative.
`aborted`	The run ended without sealing.

Test verdicts, used at both test level and step level:

Verdict	Meaning
`passed`	The test’s check (its oracle) was satisfied.
`failed`	The check ran and the product behaved incorrectly. This is a real defect.
`broken`	The check could not run because of an environment, infrastructure, or test fault.
`skipped`	Not executed.

The difference between failed and broken is central to the model. It separates “the product is wrong” from “we could not tell”. The lifecycle status is not a verdict, so a finalized run can still contain failed tests.

Next steps

Viewing evidence: open a pack in the viewer.
Validating packs: check a pack’s integrity.
The .evidence format: the profiles and the open contract.

​The layout

​The required files

​Reading a pack without unzipping it

​Run status and test verdicts

​Next steps

The layout

The required files

Reading a pack without unzipping it

Run status and test verdicts

Next steps