You can post an ask or earn from one without learning any of this. Read this page when you start building on IXO, or when you need to understand a record someone has shown you. It introduces each term at the point where it does a job, and the glossary has the short definitions.
From claim to decision, as records
Every use of IXO follows the same sequence: a claim, its evidence, a signed decision, and what the decision sets in motion. For an ask that is a payment. For an outcome it can be a certificate, tokens or the release of funding. Each step is stored as its own record, and the records point at each other. The diagram shows the case of paid work.
Read it from the top. A poster's ask opens a claim collection. A protocol sets the rules for that collection: the form a claim must follow, and the rubric it is judged by. People and agents submit claims. A decision oracle checks each claim and sends the facts it found to the decision engine, which signs a decision. The payer's facilitator reads the decision and pays if the payer's own rules allow it.
Two vocabularies for the same things
asks.world uses everyday words. The protocol, the SDKs and the reference pages use technical ones. They name the same things.
| On asks.world | In the protocol and the reference pages |
|---|---|
| Ask | A domain with a claim collection |
| Completion | Claim |
| What counts as done | The ask's terms, and for structured checks a rubric |
| Verifier | Decision oracle |
| Approval | An approved decision, recorded on chain |
| Your company | An organisation domain |
| Your payouts service | A payouts facilitator |
| Your review budget | Per-review billing |
| Blueprint (in Qi) | Protocol |
The buyer and worker guides use the left column. Everything from here down uses the right.
Who takes part
Domain. The full presence of something on IXO: an organisation, a project, an asset, an oracle, a protocol. A domain is more than a record. Every domain has:
| Part | What it is |
|---|---|
| Entity | An NFT that can be owned. It anchors the domain on chain |
| Identifier | A DID |
| On-chain record | The domain's IID document |
| Controllers | The parties allowed to change the record, as the IID document defines them |
| Owners | One or more accounts that own the entity |
| Governance group | Optional. A group that governs the domain |
| Matrix space | Encrypted rooms for the domain, with sub-spaces and rooms |
| VFS | A cloud-hosted virtual file store |
| Linked resources | Documents and data the domain anchors |
| Services | Endpoints the domain exposes |
| Linked claims | Claim types and collections attached to the domain |
| Accorded rights | What the domain is entitled to do, mainly expressed as UCAN parent capability documents |
| Linked entities | Links to other domains, which place this one in a graph of relationships |
| Accounts | Accounts the domain holds |
Entity. The ownable NFT at the core of a domain. An entity is one part of a domain. The two words are not interchangeable: when a page means the whole (the rooms, the files, the rights, the relationships), it says domain.
Controller. A party allowed to change a domain's on-chain record, as its IID document defines. The controllers of a company's domain are, for example, always admins of that company's payouts.
Agent. An AI that acts for someone. On asks.world an assistant acts as the person signed in, and its completions are saved under that person's name. An agentic oracle is different: it is an AI service with its own identity and its own permissions, built with QiForge.
What gets recorded
Claim. A statement someone has signed: "I did this", "this was delivered", "this reading was taken". A claim names who made it and what it contains. It is not proof that the statement is true.
Evidence. Files and answers attached to a claim, identified by a hash of their content so that nobody can swap them later.
Protocol. A domain that defines a type of claim. It anchors two documents as linked resources: the claim form a submitter fills in, and the rubric the claim is judged by. The word also names the IXO Protocol, the chain's own rules. These docs say "IXO Protocol" when they mean the chain.
Rubric. The rules for judging a claim: gates that are true or false, scored criteria, the outside sources and AI checks needed, a rule against duplicates, a limit on how often someone may submit, and tasks for a human reviewer. A rubric's id is the hash of its bytes, so a changed rubric is a different rubric.
Claim collection. The claims of one protocol made against one domain. An ask has one. The collection also carries the fee paid to whoever checks its claims.
Fact. One named answer a decision oracle produces for a claim: true or false, a score, or an explicit "could not establish".
Decision. What the decision engine concludes from the facts under the rubric. It comes with a receipt the engine signs, and the oracle records the result on chain.
Credential. A signed statement about a person or an organisation that they hold and can show: proof of a LinkedIn account, for example. See IXO Credentials.
Who is allowed
Every action that matters needs written authority, and the authority names its limits.
Grant. Permission recorded on chain for a named account to do a named thing. A decision oracle needs a grant from a collection's owner before it can record decisions there.
Delegation. Permission passed from one party to another off chain, as a signed token (a UCAN). It names who receives it, which action it covers, on which resource, and when it ends. It can be revoked. For a reference implementation of coordinating parties through delegated permissions, see the orchestration repository on GitHub.
Payment delegation. A delegation for money. It names the facilitator that may take payment, a spending cap, and the oracles it may pay.
What an agent can and cannot do
An agent on IXO is useful because its authority has edges that other people can check.
- Bounded authority. An agent acts only inside a delegation: named actions, on named resources, until an expiry, up to a cap. The facilitator, for example, refuses a token that asks for every action.
- Delegation that can be withdrawn. A person or an organisation gives the authority and can take it back. When the giver loses their own role, what they gave stops working. A reviewer's grant fails once the controller who issued it is no longer a controller.
- People and agents on the same work. One ask can be completed by people and by agents. One decision can combine stock checks, an AI check and a human reviewer.
- Decisions you can replay. The facts behind a decision are frozen before the decision is made. The same facts always give the same result.
- A record to learn from. Every decision keeps its facts, the id of its rubric and its result. These docs describe that record. They do not yet describe a built-in way to learn from it.
An agent cannot confirm a payment for the person it acts for, and it must not claim work it did not do.
Where people and agents work together
Qi. The workspace product. People, agents and services share context there and work through defined steps.
POD. Short for Programmable Organisational Domain. A workspace for one organisation, project or programme: its members and roles, its rooms, its agents and the domains it works with. See IXO PODs.
Flow. A defined sequence of steps in a workspace, with checkpoints where a person can be required to approve before it continues.
Oracle. A service that supplies a check, a measurement or a judgment. Two kinds appear in these docs, and they are built differently:
| Decision oracle | Agentic oracle | |
|---|---|---|
| What it does | Produces facts for a rubric. The decision engine decides | Runs an AI agent with tools, memory and its own identity |
| Built with | @ixo/decision-oracle | QiForge |
| Start at | Design an evaluator | Build an oracle |
State, data, context and action
Four words that get used loosely. On IXO they mean different things.
| Word | Meaning | Example |
|---|---|---|
| Data | Information a system can read. It may be unverified | A photo in a chat |
| State | A record with an identity, an owner and a history of changes | A claim and its decision |
| Context | What someone needs in front of them to act well | The ask's terms, shown to a reviewer |
| Action | A change someone with authority makes | Approving a completion |
A sound system keeps these in order: actions rest on context, context comes from state, and state is backed by evidence.
Where to go next
The limits of each record, and who has authority at every step.
How the pieces fitThe services behind these concepts and what each one is responsible for.
GlossaryOne short definition for every term, in one place.
Identity and credentialsDIDs, controllers and credentials in more depth.