Software verification evidence
Keep a reviewable record of what was checked, what ran and what remains unknown. Use Zof’s portable evidence tools alongside your release review process.
For release owners, QA leads and security reviewers who need more than a green status. Evidence should connect a specific change to checks, results and the limits of those results.
What Zof does
A portable evidence format
Zof’s released evidence specification defines structured records for verification. Its validator checks the record’s shape and consistency; it does not authenticate the producer or prove that a check ran.
Reports from your tools
The CI evidence adapter normalizes supported JUnit XML, generic test JSON and documented static-analysis JSON. Artifact metadata can include relative paths, sizes and SHA-256 digests.
Platform evidence review
The platform evaluation should establish how evidence connects to change records, approvals and control decisions in your deployment. Local JSON is not automatically a hosted evidence bundle or a signed approval.
From a change to a review decision
- 01
Collect the inputs
Keep the source revision, runner details, tool versions and original reports. Identify which checks ran, which were skipped and which failed to complete.
- 02
Normalize and validate
Use the released adapter for a supported report format and validate the resulting evidence record. Keep the original reports and artifacts available for inspection.
- 03
Review and retain
Compare the evidence with the release criteria, record approval separately, and retain the records under your organization’s access and retention rules.
What evidence you get
Results with scope
Portable records distinguish static analysis from test execution. A static pass with an empty tests array is not evidence of passing runtime tests.
Incomplete work stays visible
Partial evidence may be structurally valid. The released validator accepts its partial fixture while returning authenticity: not-verified. Schema validity is not a release verdict.
Artifact references
A path and digest help identify an artifact you retained. They do not upload it, preserve it indefinitely, prove its origin or make a record tamper-proof.
Prerequisites and limits
- Use supported reports and the runtime requirements documented by the pinned packages. Retain original producer output to investigate conversion gaps.
- The released adapter does not ingest trace ZIP archives. For Playwright, preserve traces and HTML reports separately; only supported report formats can be normalized.
- Hosted acceptance, signatures, identity verification, approval enforcement and retention must be verified separately for your deployment.
- Evidence can support a compliance review. The format alone does not provide a certification, prove compliance or establish software correctness.
Review the evidence contract
Start with the released schema and its passing, failing and partial fixtures. Decide what evidence your release policy needs before adding a gate.