> ## Documentation Index > Fetch the complete documentation index at: https://ixoworld-mintlify-9a7944b6.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Core concepts > Vocabulary and mental models for IXO, Qi, entities, claims, evidence, verification, and workflows. This page is **definitions and structure**: what words mean and how layers fit together. For motivation, positioning, and a short worked example, read [Act on Reality](/introduction) first. When you are ready to pick a first artifact (POD, Flow, Blueprint, and so on), use [What you can build](/guides/what-you-can-build). For DIDs, claims, and verifiable credentials in one place, read [Identity and credentials](/articles/identity-and-credentials). For quick term lookup, use the [Glossary](/reference/glossary). ## The problem space If you are building or buying systems for real-world work, you are usually asking how to **trust agents** with consequential work, **verify outcomes** before releasing money or authority, **coordinate** across organizations, and know **what changed**, **who did it**, and **whether it worked**. IXO and Qi target that class of problem—not generic chat over siloed documents. Most software tracks **internal** application state. Most AI systems reason over **generated** context. This stack coordinates many actors around **shared, verifiable reality**. * **State** — Structured information that can be identified, permissioned, queried, verified, and updated through protocol-defined actions: you can say what is true and what changed. * **Intelligence** — Humans and AI agents interpret state, coordinate with others, and take accountable action. * **Cooperation** — Alignment of people, organizations, agents, services, evidence, and workflows around a shared map of work. **IXO defines what is true and verifiable** in the shared model. **Qi defines how intelligent actors cooperate** over that model inside real workflows. IXO and Qi are closely connected, but they are not the same layer. **Problem:** AI agents and partners cannot safely act on **fragmented, unverifiable** data scattered across orgs and tools. **What the component does:** IXO (including the [IXO Graph](/articles/ixo-graph) and [IXO Protocol](/protocols/ixo-protocol)) connects **entities, identities, claims, evidence, credentials, transactions, and outcomes** into structured state that can be shared, queried, and verified. **What you build:** Workflows where humans and agents can **discover context**, **verify claims**, **trace changes**, and **ground decisions** in the same facts. **Problem:** Real-world workflows need **humans, agents, services, and organizations** to coordinate without losing context or accountability. **What the component does:** The **Qi Intelligent Cooperating System** provides the cooperation layer: actors **reason** over IXO-backed state, **exchange messages**, **evaluate evidence**, and **act** through declared workflows—with permissions and auditability. **What you build:** Evidence-review agents, secure cooperation spaces, assisted verification, human approvals, and automated routing—see [Qi](/articles/qi-intelligent-cooperating-system) and [IXO Matrix](/articles/ixo-matrix). Model identities, domains, entities, claims, credentials, assets, relationships, workflows, and evidence. Read IXO-backed context, coordinate securely, reason over evidence, and act through governed workflows. A useful rule: * **Use IXO** to define, verify, persist, or query the shared state of **reality**. * **Use Qi** to interpret, discuss, reason, decide, automate, or **act** on that reality. ## Domains In IXO, an **entity domain** (often shortened to **domain**) is the standardized way to register and manage a **digital twin** of a real-world subject on the stack: decentralized identity, verifiable credentials, linked claims and resources, services, and relationships—see [Entity Domains](/guides/dev/ixo-domains) for the developer-oriented model and [Domain registration](/guides/domain-registration) for how domains are created and typed. Each domain is anchored by a **digital identifier (DID)** following the interchain identifier pattern, has an **entity type** (what class of thing it is), and is associated with a **protocol** that defines the entity **class** and inherited properties. **Controllers** manage the on-chain domain record (DID document), and **metadata** carries standard settings for that type. Common **domain types** used across solutions include the following (wording aligned with [Domain registration](/guides/domain-registration) and the [Emerging platform domain model](/platforms/Emerging/domain-registration)): **Organisation** domains represent legal or virtual entities that operate programs, hold rights, or participate in governance—often managed as or alongside DAOs. They anchor who is accountable, who can act for the entity, and how the organisation connects to projects, assets, and markets. **Project** domains represent programs, portfolios, or interventions: the unit of work you measure, fund, verify, or report against. Project domains are typically linked to protocols that define operational rules, may use PODs for automation, and often coordinate agents, resources, claims, and accounts—see [Project Domains](/articles/projects). **Asset** domains represent physical systems, devices, infrastructure, sites, or **tokenized outcomes** that need identity, telemetry, custody, or verification on the graph. They bridge real-world “things” to claims, evidence, and economic actions (for example issuance, transfer, or retirement of outcome-linked instruments). **Protocol** domains (and protocol references on other domains) supply the **templates and rules** that govern behaviour: the entity **class**, inherited property sets, rubrics, and constraints that implementations must honour. Creating a domain of another type usually requires selecting the protocol DID that defines its class, as described under [Domain properties](/guides/domain-registration#domain-properties) and [Creating domains](/guides/domain-registration#creating-domains). **Oracle** domains (and oracle-linked services) represent **verification, measurement, or decision-support** capabilities attached to programs, assets, or workflows—often AI-enabled services that supply data or evaluations used in claims and reviews. For how oracle services fit the wider stack, see [Oracle architecture](/guides/ixo-oracles-architecture). \**Deed* style domains structure **asks and commitments** between parties so governance, negotiation, acceptance, execution, and fulfillment can be represented on the graph and autonomously executed by the system and its participants. The exact user-facing naming of domain types is configurable to the specific ontology of the use case. The underlying pattern is still a domain document with controllers, services, linked resources, rights, linked claims, relationships, and accounts. ## Core vocabulary These terms appear throughout the docs, including **build-pattern** names from [What you can build](/guides/what-you-can-build). A digital entity is a real-world actor, asset, system, place, project, organization, program, claim process, or other meaningful object represented in IXO. Digital entities make real-world things addressable in software. They can have identity, metadata, relationships, credentials, claims, services, and state transitions. A **domain** is the identity anchor for a digital entity: a DID-backed record that establishes who or what the entity is, which verification methods apply, and which actors or services may act on its behalf. For **domain types** (organisation, project, asset, protocol, oracle, request/offer) and how they relate to registration, read [Domains](#domains) above, then [Domain registration](/guides/domain-registration) or [Entity Domains](/guides/dev/ixo-domains) for procedures and interfaces. A **POD** (programmable organisational domain) is a governed **workspace**: members, roles, rooms, tools, graph entities, and agents share one coordination boundary. Hands-on: [Build a POD](/guides/users/build-a-pod). A **Flow** is a **governed workflow**: triggers, states, actions, evidence gates, reviews, and outcomes that move real work forward in an inspectable way. Hands-on: [Build a Flow](/guides/users/build-a-flow). A **Blueprint** is a reusable **protocol** for a class of work: claim schemas, evidence rules, rubrics, roles, permissions, and verification or settlement logic that many PODs or Flows can share. Hands-on: [Build a Blueprint](/guides/users/build-a-blueprint). A **Market** is a **discovery and settlement** pattern: listings, offers, fulfillment, verification, pricing, and disputes—usually implemented with Flows and Blueprints behind each listing type. Hands-on: [Build a Market](/guides/users/build-a-market). An **Agentic Oracle** is a **scoped automation or judgment service** (often with declared tools and human handoff) that reads IXO-backed context and participates in Flows—without replacing protocol authority or verified state. Architecture: [Oracle architecture](/guides/ixo-oracles-architecture). The **IXO Graph** is the shared, queryable map of entities, relationships, claims, evidence, credentials, and outcomes your applications and agents read from. It is the practical “shape” of IXO-backed state. More detail: [IXO Graph](/articles/ixo-graph). A digital twin is a working representation of a real-world entity or process. It combines identity, metadata, data services, verifiable state, relationships, and executable logic. A digital twin is not just a profile or database record. It is the operational model that applications, services, and agents use to interact with a real-world system—still expressed using domains, entities, claims, and evidence. Guide: [Digital twins](/guides/digital-twins). A claim is a verifiable statement about something. Claims can describe status, eligibility, delivery, performance, measurement, compliance, completion, impact, or any other assertion that needs review or attestation. A claim can be linked to evidence, evaluated by humans or agents, and accepted, rejected, disputed, or used to trigger further workflow steps. A credential is a portable proof issued by an authority or trusted participant. Credentials can describe identity, rights, roles, qualifications, authorizations, certifications, or attestations. They help systems determine who can do what, under which conditions, and with what level of trust. A Flow is a structured sequence of actions, decisions, messages, claims, evidence, reviews, and state changes. IXO-backed Flows make coordination explicit. Qi-enabled Flows allow humans, agents, and services to cooperate around each step using shared context and declared interfaces. A deed is an executable set of agreements and obligations that are packaged with controllers, services, resources, rights. claims, relationships, and accounts. Deeds can define requests and offers for units of work, or governance processes that are executed by the system. ## When to use the deeper technical words Use plain language first (the [introduction](/introduction) stays non-jargony). When you need precision, these are the usual mappings: First-impression phrase: **shared map** of people, assets, claims, evidence, and outcomes. Technically: a graph of entities and relationships expressed with **shared meaning** (for example linked data) so different systems interpret the same world the same way. First-impression phrase: **tamper-resistant history** of important changes. Technically: how certain state transitions are recorded so history stays inspectable and consistent with protocol rules. First-impression phrase: **data that different systems and agents can use together** without private one-off schemas everywhere. Technically: identifiers and relationships exposed in standard, machine-readable forms. First-impression phrase: **shared definitions** for how real-world things are represented. Technically: controlled vocabularies and class relationships that keep programs aligned on meaning. ## State, data, context, and action These four concepts are related, but they should not be confused. Data is information available to a system. It may come from APIs, databases, sensors, documents, messages, user input, or external services. Data can be useful without being verified, authoritative, or suitable for workflow decisions. State is the current structured condition of an entity, claim, workflow, asset, credential, or relationship. IXO state is designed to be identifiable, inspectable, permissioned, and verifiable. State tells the system what currently exists, what has changed, and which actions are valid. Context is the relevant information an actor needs to understand what is happening. Qi uses IXO-backed state, Matrix rooms, messages, evidence, workflow history, and external tools to provide context for humans and agents. Action is a change made by a human, agent, application, service, or protocol process. Actions may create entities, submit claims, issue credentials, request reviews, send messages, evaluate evidence, trigger workflows, or update state. For production systems, the goal is to keep these aligned: actions should be based on context, context should be grounded in state, and state should be supported by verifiable data and evidence. ## System layers IXO and Qi work together through several layers. They are ordered here from **outcomes and trust** down to **interfaces**. The stack exists so programs can answer: **What happened? What was claimed? What evidence exists? What was accepted or rejected? What changed next?** This is the through-line from **field reality** to **decisions and automation**—not only “logs,” but state and relationships you can inspect over time. Domains, DIDs, verification methods, roles, and delegated rights establish who or what can act. This layer answers questions such as: * Who is this actor? * What entity do they represent? * Which actions are they allowed to perform? * Which credentials or delegations support that authority? IXO Protocol modules define entities, claims, credentials, assets, relationships, and state transitions. This layer answers questions such as: * What exists? * What is currently true? * Who asserted it? * What evidence supports it? * What changed, and when? Linked services store, retrieve, index, and expose the data needed by applications, workflows, and agents. This layer includes data services, evidence stores, indexed chain state, and query surfaces such as [IXO Blocksync](/articles/ixo-blocksync). IXO Matrix provides encrypted rooms, messaging, and shared cooperation spaces. This layer allows people, organizations, agents, and services to align around context before, during, and after state-changing actions. Qi Agents and Agentic Oracles evaluate context, reason over evidence, support decisions, and trigger workflow actions. This layer should not invent state. It should discover relevant state, respect permissions, use declared tools, and act through verifiable processes. Applications, dashboards, SDKs, APIs, MCP servers, and developer tools expose the stack to builders and users. This layer turns IXO state and Qi cooperation into usable products, workflows, and services. **Compared to typical enterprise agent platforms:** those often optimize **deploying and monitoring agents inside one organization**. IXO and Qi emphasize **multi-party ecosystems**: shared evidence, verifiable state, and traceable change so agents cooperate on **real-world outcomes**, not only internal tickets and documents. ## How an agent should think about the stack If you are **not** implementing agents, you can skip to [Where to go next](#where-to-go-next). AI agents using IXO and Qi should follow a simple operating model. Identify the entity, domain, participant, workflow, claim, asset, or room that the task refers to. Use IXO-backed sources, SDKs, APIs, indexed data, or MCP tools to inspect the current state. Treat verified state, user intent, generated reasoning, external data, and speculation as different categories. Do not invent protocol actions, API shapes, permissions, or workflow steps. Use the documented SDKs, APIs, MCP tools, and workflow definitions. Submit claims, messages, evaluations, updates, or actions through the appropriate governed process. When an action changes state, make the result inspectable, attributable, and available for the next actor. ## Where to go next **Reading** Outcome-first positioning and a short walkthrough of a verified claims path. Choose a first POD, Flow, Blueprint, Oracle, asset, or Market and follow hands-on guides. Component deep-dives and design patterns across the stack. Measurement, reporting, and verification as a program discipline. **Hands-on patterns** Submit, evidence, review, and decision in one guided shape. Practical steps to wire measurement → report → verification → outcome. Tie settlement actions to verified outcomes. How program domains coordinate delivery, governance, and verification within a secure shared workspace. **Protocol and engineering** Trust, action, and coordination primitives for verifiable state. Cooperation over IXO-backed state. SDKs, setup, and implementation entry points. Creating and managing claims in application code. Package-specific setup, usage, and examples. Connecting agents to IXO-backed tools and context.