Evidence & Trust

QualityMax helps you inspect what was tested, what happened, and what evidence supports a result. A queued job, a generated test, a proposed repair, and a completed passing execution are different states. Check the completed result before treating work as verified.

Execution evidence

An execution can produce structured results, error output, screenshots, video, browser logs, or Playwright traces. Availability depends on the runner, test configuration, and workflow; every run does not necessarily contain every artifact.

When reviewing a result, check:

• The project, tested URL or environment, script revision, and execution time.
• Whether execution completed, failed, skipped, or returned an error.
• What the assertions actually checked and which paths were left untested.
• The artifacts attached to that execution, including any missing or inaccessible evidence.

A passing test supports the assertions it executed under those conditions. It does not establish that the entire application is correct. See the web quickstart and code review gates for execution and check-status workflows.

Verified-fix verdicts

The verified-fix workflow can return an Ed25519-signed verdict containing repository and commit identity, the outcome, and reproduction evidence: the same test failing against the base revision and passing against the proposed revision. Ordinary execution results should not be assumed to include this verdict.

To assess a verdict, first check its outcome and evidence, then verify that its repository, base revision, and proposed revision match the change under review. A result requiring human review is not a verified pass.

Use the published QualityMax verdict key and the offline verifier when checking a verdict. A public key bundled with an otherwise untrusted receipt does not establish who issued it; if you cannot establish the trusted key or verify the signed payload, treat the signature as unverified.

A valid signature establishes integrity of the signed record and its relationship to the trusted signer. It does not independently prove the accuracy of every observation or the completeness of test coverage. Inspect the underlying evidence as well as the signature.

Exposure receipts are a separate record

The qmax-receipt library records signed metadata about outbound exposures instrumented by an integrating application, such as destination, category, size, and payload hash. It is an integration library, not a passing-test certificate or an automatic inventory of all network traffic.

Verification can detect changes to the signed manifest. It cannot prove that the application recorded every outbound request. Destinations and other metadata can themselves be sensitive; review a receipt before sharing it.

Sharing and retention

Review screenshots, videos, logs, reports, and receipts for customer information before sharing. Use synthetic data for public examples. A shareable report is not automatically a public report: use the documented sharing action deliberately.

Availability, retention, and access depend on the workflow and your deployment. Agree any required retention period, export procedure, or assurance requirement with QualityMax instead of inferring a guarantee from the presence of an artifact link. See deployment options for the private-preview status of Sovereign deployments.