Pipelines are a design, not a shipped feature. Nothing on this page can be built or run yet, and there’s no
timeline to share.
The idea
Today, QED Proof proves the claims it was built to check: a commit landed, a PR opened, a URL answers. Pipelines are
meant to let you define proof around the actions that actually cost you money or trust — for example, “prove it
whenever my agent changes an ad budget,” not “prove every commit.”
A pipeline would be composed from four parts: a connector (a read-only connection to one destination), a
trigger (the agent’s claim, the destination’s own change history, or both), a filter (conditions on the
destination’s own event fields — event type, object, amount, actor), and a check (a published verifier, optionally
narrowed further) — producing outcomes (a receipt, and alerts on the verdicts you care about).
Rules the design holds to
- Facts still come only from the destination. A pipeline’s filter and check can only read what the connector
reads — never anything the agent reports about itself.
- Your own conditions can only narrow
verified, never widen it. A condition you add can turn a verified into
a mismatch; it can never turn a failed check into verified.
- The pipeline itself is part of the receipt. The exact pipeline definition that produced a verdict would be
fingerprinted and recorded alongside it — a pipeline digest — so anyone holding the receipt can see precisely what
was checked, not just the result.
None of this changes the invariants the product already holds to: evidence comes from the destination, and a
verifier error still means unverifiable, never verified.
