Skip to main content
A claim is an agent’s statement of what it did. QED Proof treats every claim as untrusted input: it never becomes a verdict on its own, it only tells QED Proof where and what to check.

​
Fields

A claim (POST /v1/claims) has these fields:
​
string
required
Your idempotency key. Submitting the same client_claim_id again returns the existing claim rather than creating a new one.
​
string
required
An identifier for the agent that did the work. Opaque to QED Proof.
​
string
required
What kind of outcome to check, in <domain>.<object>.<event> form — for example github.commit.push. See connectors for the actions QED Proof can check today.
​
string
required
Where the work should have landed, in the form the action expects — a owner/repo slug for GitHub actions, an https:// URL for http.url.status.
​
object
Action-specific parameters (for example sha and branch for github.commit.push). Limited to 4096 bytes of JSON. Params end up in a permanent, public receipt, so they should never contain content bodies — use a fingerprint instead (see receipts).
​
string
required
An RFC 3339 timestamp, with a timezone, for when the agent says the work happened.

​
What happens after you submit

QED Proof never asks the agent to justify its claim further. Instead it reads the destination directly — GitHub’s API, or the target URL — and compares what it finds against params. That comparison produces a verdict, which QED Proof signs into a receipt. If the outcome can be decided the moment you submit, the response to POST /v1/claims already carries a receipt_id. Otherwise QED Proof keeps re-checking the destination until the claim’s deadline, at which point an outcome still not found becomes failed (if the destination was readable) or unverifiable (if it wasn’t).