Core concepts

The ideas behind IXO and how they relate: asks, claims, evidence, decisions and payments, the domains that take part, and how authority is given.

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.worldIn the protocol and the reference pages
AskA domain with a claim collection
CompletionClaim
What counts as doneThe ask's terms, and for structured checks a rubric
VerifierDecision oracle
ApprovalAn approved decision, recorded on chain
Your companyAn organisation domain
Your payouts serviceA payouts facilitator
Your review budgetPer-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:

PartWhat it is
EntityAn NFT that can be owned. It anchors the domain on chain
IdentifierA DID
On-chain recordThe domain's IID document
ControllersThe parties allowed to change the record, as the IID document defines them
OwnersOne or more accounts that own the entity
Governance groupOptional. A group that governs the domain
Matrix spaceEncrypted rooms for the domain, with sub-spaces and rooms
VFSA cloud-hosted virtual file store
Linked resourcesDocuments and data the domain anchors
ServicesEndpoints the domain exposes
Linked claimsClaim types and collections attached to the domain
Accorded rightsWhat the domain is entitled to do, mainly expressed as UCAN parent capability documents
Linked entitiesLinks to other domains, which place this one in a graph of relationships
AccountsAccounts 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 oracleAgentic oracle
What it doesProduces facts for a rubric. The decision engine decidesRuns an AI agent with tools, memory and its own identity
Built with@ixo/decision-oracleQiForge
Start atDesign an evaluatorBuild an oracle

State, data, context and action

Four words that get used loosely. On IXO they mean different things.

WordMeaningExample
DataInformation a system can read. It may be unverifiedA photo in a chat
StateA record with an identity, an owner and a history of changesA claim and its decision
ContextWhat someone needs in front of them to act wellThe ask's terms, shown to a reviewer
ActionA change someone with authority makesApproving 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