A screenshot of a successful page is hard to interpret on its own. A commit alone doesn't describe what was verified either. When someone asks what was tested before a release, the useful answer keeps three things together: the test that ran, the environment it ran against and what happened.
What to keep with a result
- The outcome the reviewer cares about. "Refund button is only visible to admins" is reviewable. "Billing tests passed" isn't.
- The test definition and environment. A result means little if you can't see what it checked or where.
- The release context. Record which release or commit the environment was serving when the test ran.
What a run can establish
A run shows the steps and assertions executed against an environment at a particular time. Explain the actual assertion and its scope when you hand the record to a reviewer, and don't let one passing flow stand in for controls outside it.
What Zerocheck gives you, and what it doesn't
Open a run to see the YAML that ran, the environment, each step's result, screenshots and errors. The CLI's --json option writes the run record to a file if another process needs it. A CLI run record doesn't carry the repository or commit, so note what was deployed yourself.
Zerocheck doesn't supply SOC 2 control mappings, compliance scores, audit evidence packages or policy-based retention, and it isn't a certification. Whether a test record is relevant to a particular review is for the people responsible for that review to decide. Keep audit mappings and approvals in your existing process, and don't promise retention periods without an agreed policy.