That sentence is doing a great deal of load-bearing work. Dashboards count it. Alerts stay quiet because of it. Some teams now pay agents, or pay for agents, on the strength of it. And it comes from the one party with no way to be independent about the answer: the agent itself.

Self-report fails in boring ways

The failures that matter aren't dramatic. They're the ones where the agent is sincerely wrong:

• It committed to a local branch and the push failed on authentication. The log line says pushed.
• The CI run it waited on was a different commit's.
• The post API returned 200 and the platform rejected the media afterwards.
• It edited the budget on the wrong campaign.

In each case the agent's own trace looks like success, because the trace records what the agent did and believed, not what the destination holds. Tracing and observability tools are genuinely useful — they just answer a different question. They tell you what your agent said. They can't tell you whether it was true.

The only record that settles it

Whether a commit is on main is a fact about GitHub, not about the agent. Whether a URL answers is a fact about the URL. So QED Proof has one rule it never bends: evidence comes from the destination, never from the agent's report.

When a claim arrives, QED Proof waits until the work should be visible, then reads the destination itself over access you grant read-only. It compares what it finds with what was claimed and decides one of five verdicts: Verified, Failed, Mismatch, Late, or Couldn't check — the five verdicts.

Failing in the safe direction

The last verdict is the most important design decision in the product. A verifier can fail for reasons that say nothing about the agent: a timeout, a revoked permission, an action nobody has built a verifier for yet. In every one of those cases the verdict is Couldn't check — never Verified.

A trust product that passes something that didn't happen is finished. One that occasionally says "I couldn't see" is merely honest. So the code is written so that there is no path from an error to a green tick, and "Couldn't check" is shown as QED Proof's limitation, not the agent's failure.

Then make the verdict hold on its own

A verdict you have to take our word for would just move the trust problem one step along. So every verdict becomes a receipt: signed with Ed25519, appended to a Merkle log that can't be edited, and anchored on-chain. Anyone holding the receipt can check all three with the open-source checker and a public RPC — no QED Proof account, no QED Proof API. How that check works is a post of its own.

What this covers today

QED Proof verifies GitHub (a commit is on the branch, a pull request is open, CI passed on a commit), X posts, Slack messages and any public URL today. Meta and GitLab connect read-only now, with their verifiers next. The integrations page keeps that list honest, because a page about false "done" claims shouldn't make any.

It carries three proofs. Each answers a different question, and each can be checked on its own.

1. The signature: did QED Proof issue this, unchanged?

The receipt is canonicalised — serialised to exactly one byte sequence — and signed with Ed25519. The signing key lives in a cloud KMS and can't be exported. The public keys are published at https://api.qedproof.site/.well-known/poaw-keys.json.

Checking it proves two things: this receipt came from the key it names, and not one byte of it has changed since. Edit the verdict, the evidence or the timestamp and the signature stops verifying.

What it can't prove on its own: that we didn't quietly issue a different receipt for the same claim, or backdate one. That's what the next two proofs are for.

2. Inclusion: is it really in the log?

Every receipt becomes a leaf in an append-only Merkle log. The receipt comes with an inclusion proof: the short list of sibling hashes that combine, level by level, from its leaf up to the log's root.

Recomputing that path proves the receipt is part of the log at a specific position. And because the log only ever appends, anything already in it can't be edited or dropped without changing every root after it.

3. The anchor: when did that log exist?

The log's root is published on-chain through the Ethereum Attestation Service (EAS) on Base, every ten minutes. Once a root is in a block, it can't be moved.

Checking the anchor proves the log — and therefore your receipt — existed in that state no later than that block. Not even QED Proof can backdate it afterwards. (Today the log is anchored on Base Sepolia, Base's test network; mainnet is the next step.)

Running the check

The checker is part of Proof of Agent Work, the open-source spec behind QED Proof. Point it at a receipt, the published keys and any public Base RPC:

$ uv run check.py receipt.json poaw-keys.json \
    --rpc https://sepolia.base.org

signature   ✓
inclusion   ✓  leaf 8 of 9
anchor      ✓  block 47,309,207
trust level 2  proven by 21:38:22

Nothing in that path touches a QED Proof server. If we disappeared tomorrow, every receipt we had issued would still verify.

What a receipt deliberately leaves out

A receipt records fingerprints and the facts a verifier read — a commit SHA, an HTTP status — never the content itself. You can share a receipt link publicly without sharing your code, your post or your email. The proof is about what happened, not about what it said.

QED Proof's first verifiers prove things we chose: a commit landed, a pull request opened, a URL answers. They're useful, and they're the easiest place to start. But the actions that actually cost a business money or trust are more specific than "a commit", and they differ from team to team.

Take a marketer whose agent manages an ad account. They don't want a receipt for everything the agent touches. They want proof only when it changes a budget. They want to know the change really landed, at the value claimed. And above all, they want to hear about any budget change the agent didn't report.

A pipeline is a rule, built from our parts

A pipeline has five parts:

You write it once — in a form, or as JSON through the API; one schema, two editors.

Rules that keep it honest

Letting people define their own proof is exactly where a verification product could go wrong, so pipelines keep the invariants that make a receipt worth anything:

• Facts only ever come from the connector. No step can take a fact from the agent or from its claim. The claim says what to look for; the destination says what happened.
• Your conditions can only narrow a Verified, never create one. A condition that fails turns the verdict into a Mismatch. It can't turn a failed check into a pass.
• The rule is recorded in the receipt. The pipeline is hashed and its version travels with every verdict, so whoever holds the receipt can see exactly what was checked. Editing a pipeline makes a new version; old receipts keep the old one.
• No custom code, yet. Pipelines are assembled from our reviewed parts only.

The case logging never catches

The most valuable output isn't a receipt for a claim at all. In watch mode, QED Proof reads the account's own change history and matches every change against open claims. A change inside your filter that no claim explains is an unclaimed change: an agent that did something and didn't say so. It becomes a signed entry in the same log, and an alert.

That is the failure plain logging can never surface, because the agent that didn't mention the change didn't log it either.

Where it starts

The first connector is Meta Ads, where the account's activity log records budget and bid edits with their old and new values and the app that made them; Google Ads follows. Meta already connects read-only today — see integrations. When pipelines ship, this post will say so at the top.