# What each record proves
> What a claim, a check, a decision and a payment receipt each prove on IXO, who has authority at every step, and what can still fail after each one.
IXO records each step of a piece of work separately: the ask, the claim and its evidence, the
decision, and the payment. Each record proves one narrow thing. Read this page before you rely on
any of them for a decision of your own, because the gaps between them are where money and trust get
lost.
## Four things to keep apart
1. **A signed claim is an assertion.** It shows who said what, and when. It does not show that what
they said is true.
2. **A passed check is a match against rules.** It shows the evidence met the rules as written. It
does not show the result is correct.
3. **A decision is not permission to pay.** It says what the rules concluded. Payment needs someone
with authority over the money to have allowed it.
4. **A payment receipt is not money received.** It shows a payment was sent on some rail. Whether
the recipient has it is a separate fact.
On asks.world a claim is called a completion, and a decision oracle is called a verifier. This page
uses the protocol's names, because that is what the records themselves say.
## Step by step
| Step | Record | Made by | It proves | It does not prove |
| --- | --- | --- | --- | --- |
| Ask | The posted terms | The poster | These terms were published by this account | That the terms are clear, fair or achievable |
| Action | A claim, signed and stored by its content hash | The person who did the work, or their agent acting as them | This account submitted exactly this content | That the content is true, or that the work was done |
| Evidence | Files and form answers attached to the claim | The person who did the work | Which content the check read, identified by its hash | That a photo is genuine, or that the evidence is complete |
| Check | A set of named facts, frozen before the decision | The decision oracle | These facts were produced for this claim, and nothing changed them afterwards | That each fact is right. An AI check can be wrong |
| Decision | A receipt signed by the decision engine, and a record on chain | The decision engine, then the oracle | These rules, applied to these facts, gave this result | That the result is correct in the world, or that anyone will pay |
| Payment sent | A settlement or payout receipt | The payer's facilitator | The payer's service sent this amount on this rail | That the recipient has the money |
| Payment received | The recipient's own account | The recipient's bank, wallet or mobile money provider | The recipient has the money | Nothing further |
Two details make the middle rows stronger than they look.
The decision engine checks that the content an oracle sends is the claim's own content. An oracle
that was hired to check a claim cannot swap in different answers. If the content does not match, the
engine refuses and the claim fails.
After the facts are frozen, nothing downstream reads the network, the clock or a model. The same
facts always give the same decision, which is what lets someone else replay it.
## Who has authority
A record says what happened. Authority says who was allowed to make it happen. On IXO, authority is
given in writing, to a named party, for a named action, and it can end.
| Action | Who may do it | How they get the authority | How it ends |
| --- | --- | --- | --- |
| Post an ask | The account that signs it | Their own sign-in and tap | |
| Record a decision on chain | A decision oracle | A grant on chain from the collection's owner, naming the oracle | The owner revokes the grant, or it runs out |
| Pay what a collection promised on chain | The chain, when an approval or a rejection is recorded | Payment terms the collection's owner set in advance, capped by the oracle's grant | The collection's account runs short, or the grant ends |
| Review a claim held for a person | A reviewer the collection's controllers have authorised | A grant issued by a current controller | The grant is revoked, or its issuer stops being a controller |
| Give the final OK on a completion | Whoever the poster chose: by default the poster | Their own tap on asks.world | |
| Charge for a decision | The facilitator, on the payer's behalf | A payment delegation the payer signs once. It names the facilitator, a spending cap and the oracles it may pay | It expires, its cap is used up, or its signer no longer owns the organisation |
| Pay a company's payees | The company's own payouts facilitator | Rules the company sets: which oracles it trusts, the most one payout can be, and the amount above which a person approves | A team member pauses payouts, or the rules change |
| Approve a company payout above the threshold | A person on the company's payout team | A role given by the controllers of the company's domain, who are always admins | The role is removed |
An AI agent never holds more than the person it acts for. On asks.world it cannot tap, approve or
confirm for them.
## What can fail, and what happens then
These are the cases the system names today. Each one stops short of the happy path at a different
point.
| Case | What it means | What happens |
| --- | --- | --- |
| Could not establish | An oracle could not produce a fact: a photo has no location, a file is unreadable, a source refused | The fact is recorded as an error, never as "false". The rubric says where an error goes, usually to a person |
| Held for a person | The rules could not decide, and the decision names tasks for a reviewer | Nothing is decided until a reviewer answers exactly those tasks. A payment reservation can be held for up to 30 days meanwhile. On a company's ask, a completion nobody reviews within 48 hours is turned down |
| Unusable | The engine could not match the rubric to the claim form | No result for the claim, and nothing to record on chain. The decision fee is still charged, because a decision was delivered. Fix the rubric before sending more claims |
| Content mismatch | The content an oracle sent is not the claim's own | The engine refuses, the claim fails, and the oracle's operator is alerted |
| No decision arrives | The oracle never returns a receipt | The payment reservation lapses 24 hours after it was made. Nothing is paid |
| The collection cannot cover its payments | The collection's account does not hold what recording the decision would draw: the decision fee, plus the payment for an approval or a rejection | The decision is made and kept back from the chain. It is recorded when the account is funded again |
| Expired or used up | A payment delegation has run out or reached its cap | Nobody can pay. The oracle pauses that organisation's collections until someone signs a new delegation |
| Revoked | A grant was withdrawn, or the person who issued it lost their role | A reviewer's answer is refused and nothing is sent. Decisions cannot be recorded without a live grant |
| No payee, or an unusable amount | The claim does not say who to pay, or the amount cannot be read | The claim is still decided, and nothing is paid. With no payee, the receipt carries no payment instruction. With an unusable amount, it carries one that is declined, with a reason code |
| Untrusted oracle | A decision came from an oracle the payer has not chosen to trust | The payer's facilitator does not pay on it |
| Payout failed | The rail refused or lost the payment | On a cash-out, the person can retry or ask for the amount back |
| Disputed claim | Someone challenges the party who submitted a claim, or the party who evaluated it | Anyone with a registered DID can file a dispute on chain by locking the collection's dispute deposit. An adjudicator the collection has approved decides it. See [How claim disputes work on chain](/guides/dev/claim-disputes) |
## What the chain records about a claim
The IXO Protocol gives every claim an evaluation status. The values come from the Claims module.
| Status | Meaning |
| --- | --- |
| `pending` | Submitted, and not yet evaluated |
| `approved` | Evaluated and approved. Payment terms set on the collection for an approval apply |
| `rejected` | Evaluated and rejected. Payment terms for a rejection apply, if the collection set any |
| `flagged` | The evaluator declined to make a final call. No payment fires. An authorised evaluator can later move the claim to approved, rejected or invalidated |
| `invalidated` | Final, with no payment |
| `disputed` | No longer given to new evaluations. Older claims keep it as history |
A dispute is a separate record. It has its own status (`OPEN`, `AWARDED` or `DISMISSED`), and it
does not change the claim's evaluation or reverse a payment. What changes hands is the disputer's
stake and the losing agent's performance deposit.
[How claim disputes work on chain](/guides/dev/claim-disputes) explains who can file, who decides
and who is paid.
"Disputed" also appears as a state in the decision oracle's reference. There it describes a
disagreement over which company a data source belongs to. It is not a dispute about a claim.
## Two payments that are not the same
A piece of work can involve two separate payments. Mixing them up is the commonest mistake in
reading a record.
| | Fee for the decision | Payment for the work |
| --- | --- | --- |
| Who is paid | The oracle that checked the claim, with a share to IXO or the network | The person who did the work |
| Who pays | Whoever commissioned the check | The poster, or the company's own payouts facilitator |
| When it is due | When a decision is delivered, whatever the decision is | Only when the claim is approved |
| Documented in | [How payment works](/payments/facilitator) and [Charge for decisions](/payments/charge-for-decisions) | [Post your first ask](/guides/users/post-an-ask) and [Host your own payouts facilitator](/payments/self-host-payouts) |
A rejection is still a delivered decision. The decision fee is due, and the worker is paid nothing.
## Payment sent is not payment received
The payment records report sending. They report it in stages, so read the stage.
- A settlement answers `settlement_pending` until the money has moved, then `success` with a
transaction. Before that, nothing has been paid.
- USDC on Base counts as paid once Base marks the block `safe`.
- A card payment is a hold first, and a capture after the decision. A hold with no decision is
cancelled.
- A company payout over Stripe is a transfer to the payee's Stripe account, and then a payout to
their bank. Those are two steps.
These docs do not yet say which of the two Stripe steps a payout receipt records, or how to check
a payout against the recipient's bank. Until they do, treat a payout receipt as proof the money
was sent, and confirm arrival with the recipient.
## Check a record yourself
- **A decision.** The receipt is public at the decision engine's `/v1/receipts/:cid`. The record on
chain carries the same receipt identifier as its proof.
- **A settlement.** Send the identical settle request again, or read `GET /settlements/:id` on the
facilitator, to see whether it is still pending.
- **A payouts facilitator.** Run its `trust-check` command. It performs the same check from public
data that an app runs before sending it payouts.
The commands and fields are in [Charge for decisions](/payments/charge-for-decisions),
[Host your own payouts facilitator](/payments/self-host-payouts) and the
[decision oracle API reference](/build-an-oracle/decision-oracle/api-reference).
## Related
The loop these records belong to, in one example.
Which parts are live, which are sandbox only, and which are not available.
The terms on this page and how they relate.
How to write rules whose decisions deserve to be relied on.