A verified claims workflow takes a claim about delivery, eligibility, compliance, performance or impact from submission to a decision on record. On IXO, the claims of one type made against one domain are held in a claim collection. Plan a workflow when other people have to rely on such claims, and they need to see who made each one, what evidence backs it, and how it was decided. This page helps you design it for one type of claim.
This is a design guide. It helps you plan, and it gives you nothing to run. For paths you can follow to a working result today, see Choose your path.
| You end with | A design for one claim type: what the claim is about, who may submit it, the evidence it needs, how it is checked, the states it moves through, and what follows an approval or a rejection. |
| Who decides | You write the rules. A decision oracle produces the facts and the IXO decision engine decides each claim. A person answers what the rules send to review. |
What you are designing
Claims often live in spreadsheets, emails, documents and screenshots. A reviewer cannot see who made a claim, what evidence supports it, who had authority, or why it was decided. The workflow you design links each claim to its evidence and resolves it through states that anyone with access can check.
For example, an implementer submits a claim that a milestone was completed, with the evidence attached. A decision oracle checks the evidence against the programme's rules, and the decision engine decides the claim. If the rules cannot decide, the claim is held for a person. The workflow moves on from the decision.
Design steps
Start with one claim type.
Name what the claim is about
Name the domain the claim is made against: the project, the site, the service or the programme. Then write the claim in one sentence, in the words of the person making it.
Say who can submit
List who may submit this type of claim, and what they must hold before they can.
List the evidence
Write what evidence each claim must carry. A claim with no stated evidence requirement cannot be checked.
Say how it is checked and who reviews
Write the rules the evidence is checked against, and name who reviews a claim the rules cannot decide. Design an evaluator turns the rules into gates, facts and review tasks.
If an AI agent helps, say what it may treat as decided and what is only submitted. An agent is useful here only when it can tell the two apart.
List the states
Write the states a claim can move through, from submitted to its final result. The chain gives every claim an evaluation status of its own, listed under What the chain records about a claim.
A dispute is a separate record with its own status. See How claim disputes work on chain.
Decide what follows each result
Write what happens when a claim is approved and when it is rejected. If an approval should pay someone, that is set in advance as payment terms on the claim collection. What each record proves lists who may set them.
What a claims workflow does not do
- It does not make a claim true. A signed claim shows who said what. A passed check shows the evidence met the rules as written. See What each record proves.
- It does not pay by deciding. A decision is not permission to pay.
- It does not let an agent's summary stand in for a decision. An agentic oracle can review evidence and flag risks. The decision comes from the rules.
Where it is built
Where claim operations run, with the message that submits a claim.
Design an evaluatorPlan the rules, facts, review tasks and tests that decide your claims.
IXO ProtocolThe protocol behind claims, credentials and domains.
Core conceptsClaim, evidence, claim collection and decision, and how they relate.