Read an evidence bundle

An audit writes a directory of provenance-bearing artifacts. With inputs and run context pinned, the release artifacts are reproducible. This page explains the ones you will read most.

Key artifacts

Artifact	What it is
`evidence-pack.json`	The canonical record: components, dependency edges, evidence items, gaps, requirement assessments, vulnerabilities, provenance.
`cyclonedx-sbom.json` / `spdx-sbom.json`	Standard SBOMs derived from the observed composition.
`cra-coverage.json`	Per-requirement CRA-oriented coverage and gaps for the declared product class.
`issues.json` / `issues.md`	Evidence-gap issues suitable for a tracker.
`release-gate.json`	The pass/fail gate result and the reason.
`evidence-bundle.html` / `.json` / `.zip`	A portable reviewer/auditor handoff.
`audit-log.jsonl`	An append-only, hash-chained record designed to make later modification detectable.

Note

Release artifacts are reproducible when inputs and run context are pinned;
opt-in operational phase durations are excluded from determinism checks. The
bundle composes existing artifacts — it adds no authority or conclusion of
its own.

Reading the coverage picture

cra-coverage.json reports, for each in-scope requirement, whether evidence was observed and where gaps remain. A gap means evidence was not observed — it does not mean the requirement is unmet or that the product is non-conformant. A human reviewer decides.

Explaining a result

To understand why a specific gap, finding, or gate decision appears:

bash

sbomflow explain ./evidence --gap <gap-id>
sbomflow explain ./evidence --finding <finding-id>
sbomflow explain ./evidence --gate

Reviewing

Machine observation is not human review. To record review decisions and approvals, use the review workflow:

bash

sbomflow review ./evidence

See Observed vs reviewed for why this boundary matters.

SBOMFlow documentation. Engineering release-evidence support only — not a compliance or conformity claim, and not legal advice.