Also called: reading the destination, outcome verification
In plain words
Destination verification means you settle whether work happened by looking where it was supposed to happen. Whether a commit is on main is a fact about the repository. Whether a URL answers is a fact about the URL. Whether a budget moved is a fact about the ad account's own change history.
It's the opposite of self-report, where the thing being checked is also the thing doing the reporting. Tracing, logging and agent-side telemetry are useful, but they all describe the agent's point of view. Only the destination can say what's actually there.
How QED Proof uses it
It's QED Proof's first principle: evidence comes from the destination, never from the agent's report. Verifiers read destinations over access the customer grants read-only and can revoke. On GitHub, for example, that's the QED Proof GitHub App with read permissions and a short-lived token minted per check. QED Proof never writes to a destination.
A receipt records what the verifier read as facts (a commit SHA, an HTTP status) and fingerprints (hashes of content), never the content itself. That's enough for anyone to re-check the verdict without QED Proof keeping your code, posts or email.
Example
Verified today: GitHub (github.commit.push, github.pr.open, github.checks.pass), X (x.post.publish), Slack (slack.message.post) and any public URL (http.url.status). Meta and GitLab connect read-only now, with their verifiers next. See integrations.