Audit proof contract
The properties a result must satisfy before it can support a production finding or remediation claim.
Proof is narrower than confidence
A polished report is not evidence. The product must be able to identify what was acquired, which protocol ran, what it observed, how the finding followed, and what a later scan would need to observe to clear that finding. That trail is the deliverable: verification proof — whatever the outcome — a client or finance team can audit line by line.
How the bundle digest is computed
The digest is SHA-256 over the bundle's canonical JSON form: object keys recursively sorted lexicographically, no whitespace, UTF-8 — computed over the full bundle with the bundleSha256 field itself removed. An in-browser digest checker (no authentication of who produced the file) is available at /verify.
The proof properties
- 01
Content-addressed evidence
Every authoritative bundle has a canonical SHA-256 identity. Artifact hashes declare whether they cover a full body or a bounded prefix.
- 02
Immutable persistence
A completed scan stores one evidence bundle per schema version. A conflicting retry is rejected instead of silently replacing audit history.
- 03
Typed execution state
Required work is recorded as SUCCEEDED, FAILED, ABSTAINED, or NOT APPLICABLE. Missing protocol evidence cannot silently become zero, false, stable, or pass.
- 04
Evidence-linked findings
A production finding must reference known protocol executions and observations. Experimental evidence cannot create a production blocker.
- 05
Finding-specific verification
A rescan compares the same target, compatible profile, protocol set, and the original remediation outcome. The result is VERIFIED, NOT VERIFIED, or INDETERMINATE.
- 06
Public-safe result projection
The customer surface exposes bounded diagnostics, remediation, limitations, and hashes without returning captured page bodies or secret-bearing headers.
What does not count as proof
- A unit test passing without the corresponding runtime and persistence path.
- A synthetic fixture standing in for representative real URLs.
- A marker, log line, or score that is not backed by a completed evidence record.
- Two similar totals without finding-specific protocol comparison.
- A successful browser render treated as proof of every crawler or provider path.
How verdicts are decided
- An open production blocker is decided first: if any production blocker is open, the verdict is FAIL — even when some required checks never completed.
- Otherwise, if any required check did not complete, the verdict is INCOMPLETE. Missing evidence is never converted into a pass.
- Otherwise the verdict is PASS.
- The execution state is a separate field recording whether every required check completed (FAILED, PARTIAL, or COMPLETE). FAIL and PARTIAL can appear on the same result — for example, when robots.txt blocks a required AI actor (a blocker) while the other required actors could not be measured at all.
How to inspect one result
- 1Confirm the audit profile, protocol-set version, target URL, timestamp, and execution state.
- 2Check that every required protocol succeeded — or that an open production blocker (verdict FAIL) or missing required evidence (verdict INCOMPLETE) explains why one did not.
- 3Open each production finding and read its linked limitation and remediation.
- 4After a change, inspect the remediation verification—not an aggregate score delta.
- 5Use the bundle identifiers and hashes to distinguish the baseline from the candidate evidence.
Remediation evaluator coverage
Every remediation code defined under protocol set gm-ai-consumer-compat/4.0.0 either maps to an automated verification evaluator or carries an explicit no-evaluator registry note.
The proof contract does not establish indexing, ranking, citation, model training, semantic understanding, or provider compliance. Those outcomes require different evidence.