Skip to main content
Use kane-cli evidence validate to confirm that a pack is intact and complete:
The target can be any of these:
  • an execution id, which Kane CLI looks up in the project store,
  • a live pack directory,
  • a sealed .evidence file.
Exit codes: 0 valid, 1 invalid, 2 not found. Combine --json with the exit code to gate a CI job or script on the result.

​
Gating a pipeline

​
What validation checks

What gets checked depends on the run status. For a pack that is running or aborted, the validator checks structure only. For a finalized pack, it also runs the full seal checks. Structure checks, for every run status:
  • the run manifest run.yaml and its identity fields are present,
  • each test’s recorded id equals its tests/<id>/ directory name,
  • every test directory has a result.yaml, and where a result.yaml declares a definition path, the file at that path exists,
  • a declared definition path stays inside the pack: no leading /, no .., and no way to point outside it,
  • step ordinals (the step numbers) are unique and strictly increasing. Gaps are allowed.
Full seal checks, for a finalized run only:
  • ended and totals are present, and ended is at or after started,
  • totals matches the per-test verdicts added together, and the test count equals the sum of the verdict buckets,
  • every declared definition carries a hash, and the hash matches its file,
  • at L1, each test has a logs/ directory whose meta.yaml declares at least one log, and a steps/ directory; the pack has a global coverage/ directory and the finalize-generated root failure.yaml.
If a test is marked passed but contains a failed or broken step, the validator reports a warning, never a failure. The test verdict is written by the tool that produced the pack, so the validator flags the mismatch but does not overrule it.

​
Profiles

Kane CLI packs include the captured artifacts, so they validate at L1, which is this command’s default.
A missing per-step screenshot is a warning, not an error. Not every framework captures a frame per step, and not every step needs a folder.

​
When a pack will not open

If a pack does not open in the viewer, validate it. An unsealed pack, for example from a run that was force-killed, gets the structure checks only, so it can still report as valid. A truncated pack cannot be read at all, so validation fails before it reaches a verdict.

​
Next steps