Proof, retest and report verification

A finding from a deterministic class carries a proof: the exact request that triggered it, any harmless test marker used, the validator that judged the response and a hash of the original response. Secrets in the stored excerpt are redacted.

For SQL injection, the strongest proof compares an always-true and an always-false condition against a stable baseline page. The finding is proven only when the true condition reproduces the page and the false condition changes it. An unstable page is never judged.

A retest re-sends the stored request and re-runs the same validator. A different rule matching is a new finding, not this one reproducing.

A finding that does not appear in a later run is reported as not observed. It might have been fixed, or the later run might have had less coverage or failed to sign in. Only a replay that observed the application can mark a finding verified fixed.

Send the pack fields to the public verification route. It confirms that the manifest folds to the pack root, that the signature verifies, that any supplied documents still match the manifest and that the signing key was issued by Pentriarch.

To verify offline, hash the ordered "kind:sha256" lines joined by newlines; the result must equal packRoot. Then check the Ed25519 signature over "pentriarch-pack/v1", reportId, status, generatedAt and packRoot, joined by newlines. A valid signature proves integrity and origin, not that findings are correct or that a system is compliant.