Pipelines are designed and accepted, but not live yet. This post describes where the product is going, not what it does today.
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:
| Part | What it is | For the budget example |
|---|---|---|
| Connector | a vetted, read-only connection to one destination | the Meta ad account, ads_read only |
| Trigger | the agent's claim, or a watch on the destination's own change history | both |
| Filter | conditions on the destination's own event fields | a budget change, on campaigns A or B, of $50 or more |
| Check | a published verifier profile, narrowed | the new budget matches the claim, made by the agent's app, within ten minutes |
| Outcomes | a receipt, and alerts where you already look | always a receipt; alert on a mismatch, a late change, or an unclaimed one |
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.