> ## 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. # IXO Graph > The shared, verifiable graph for entities, claims, evidence, credentials, workflows, transactions, and outcomes. The IXO Graph is the shared map of reality, and a record of state changes over time. It connects people, organizations, projects, assets, services, agents, Claims, evidence, credentials, workflows, transactions, decisions, and outcomes so humans and AI agents can understand: * what exists * who is involved * what is being claimed * what evidence supports it * who has authority * what changed * what has been verified * what should happen next Use the IXO Graph when your system needs more than private data storage. Use it when multiple participants, applications, services, or agents need to coordinate around the same inspectable reality, and when you need to trace changes over time. Think of the IXO Graph as the shared operating map for intelligent cooperation. IXO Protocol records verifiable state. Qi uses that state to coordinate humans, agents, applications, and services. ## Why it matters Most real-world work is fragmented across spreadsheets, documents, chats, CRMs, dashboards, blockchains, APIs, and institutional records. That fragmentation creates coordination failures: * participants use different identifiers * evidence is separated from the Claim it supports * permissions are hidden inside private systems * agents act on partial or stale context * decisions cannot be replayed * outcomes are hard to verify * value is released without a clear audit trail The IXO Graph addresses this by giving the stack a common structure for representing entities, relationships, authority, evidence, decisions, and change over time. This lets IXO and Qi answer practical questions: Identity, domain, credentials, roles, and relationships. Claim type, subject, issuer, data, and linked evidence. Credentials, permissions, delegations, and workflow state. Documents, measurements, observations, attestations, media, reports, sensor records, or external references. Transactions, attestations, Flow events, state transitions, and decisions. Evaluation Claims, approvals, rejections, disputes, UDIDs, and outcomes. Flow state, allowed actions, assigned roles, agent tools, and settlement rules. ## What the IXO Graph connects People, organizations, projects, assets, devices, services, agents, datasets, places, programs, workflows, and outcomes. Assertions about delivery, eligibility, compliance, performance, impact, or state, linked to supporting evidence. Roles, permissions, qualifications, attestations, delegations, and rights to act. Records of what changed, who changed it, when it changed, and which protocol operation or workflow caused it. Workflow state, rooms, messages, agent actions, human review, escalations, and next steps. Verified results, decisions, impacts, approvals, disputes, payments, credentials, and learning loops. ## How it works A real-world or digital object is represented as an entity. This may be a person, organization, project, asset, device, service, agent, program, claim process, or outcome. The entity is linked to identities, domains, credentials, roles, permissions, or delegations that define who can act. Participants, services, devices, or agents submit Claims about the entity. Evidence is linked to the Claim so it can be reviewed, verified, disputed, or reused. Qi Flows coordinate the Claim through intake, review, evaluation, approval, dispute, settlement, or closure. Transactions, attestations, Flow events, Evaluation Claims, and UDIDs create an inspectable history of what changed and why. Humans, services, and Agentic Oracles use the graph to decide what is allowed, what needs review, what can be settled, and what should happen next. ## Example: verified service delivery A service provider delivers field data collection for a digital MRV program. The provider exists as an entity with an identity, credentials, service profile, and marketplace listing. A buyer requests the service through a Marketplace. A Qi Flow starts the fulfillment process. The provider submits a Claim that field visits were completed for a specific project, location, and reporting period. The Claim links to field reports, timestamps, location records, photos, device references, or verifier attestations. An Agentic Oracle inspects only the context it is authorized to access, applies the active rubric, and creates an Evaluation Claim. A human verifier accepts, rejects, disputes, or requests more evidence. The decision is recorded as a UDID when the Flow reaches a determination point. If the determination approves the work, the Flow can trigger payment, reputation update, credential issuance, or the next workflow step. The graph connects every part of this process: provider, buyer, project, service, Claim, evidence, rubric, agent review, verifier decision, settlement, and outcome. ## The developer mental model When building with the IXO Graph, model the system as connected operational facts. Entity. Identity, agent, service, or organization. Claim. Evidence. Credential, permission, UCAN, role, or delegation. Qi Flow. Evaluation Claim. UDID. Transaction, state transition, attestation, or Flow event. Payment, reward, fee, settlement, or allocation. Outcome, metric, research Claim, or updated Blueprint. ## IXO Graph and Qi Qi depends on the IXO Graph because intelligent cooperation needs shared context. Qi uses the graph to: * resolve which entities are involved in a Flow * retrieve Claims, evidence, credentials, and workflow history * check whether a participant, service, or agent has authority * give Agentic Oracles structured context instead of disconnected prompts * separate submitted information from verified state * record Evaluation Claims and UDID-backed determinations * trigger allowed state transitions, messages, payments, credentials, or next actions * feed verified outcomes back into analytics, research, governance, and future workflows Do not treat agent memory or chat history as the system of record. Use the IXO Graph for entities, Claims, evidence, authority, state transitions, decisions, and outcomes. ## Practical build patterns Let participants submit Claims, attach evidence, route review, record Evaluation Claims, and issue determinations. Connect measurements, reports, verification events, attestations, outcomes, and funding logic. Link providers, buyers, listings, orders, fulfillment Claims, evidence, review, settlement, and reputation. Release value when Claims and evidence satisfy protocol rules and a determination is recorded. Give agents scoped access to graph context, evidence, rubrics, and tools so they can support review without becoming final authority. Feed accepted outcomes, rejected Claims, disputes, and evaluation results back into protocols, rubrics, research, and agent improvement. ## First implementation move Start with one entity type, one Claim type, and one Flow. Decide what the graph should represent first. Examples: service provider, project, device, household, marketplace listing, dataset, agent, or outcome. Specify what can be asserted about that entity. Include the Claim type, issuer, subject, required fields, and evidence requirements. Decide who can create, read, review, evaluate, approve, dispute, or settle the Claim. Use credentials, roles, permissions, and UCAN-scoped delegation where agents or services act. Route the Claim through submission, review, evaluation, determination, action, and closure. Use a UDID when the Flow reaches a decision and impact determination point. Review the graph history to find missing evidence, unclear authority, slow review, rejected Claims, disputes, or settlement bottlenecks. ## Design principles Do not model everything. Start with the entities, Claims, evidence, permissions, workflows, and outcomes that participants need to inspect or act on. A Claim is an assertion. It becomes useful when linked to evidence, authority, review, and determination. Evidence should be linkable, identifiable, and reviewable. Include references, hashes, provenance, timestamps, source metadata, and access rules where needed. Record who acted, under which role, credential, delegation, or permission, and within which Flow state. Agents should access only the graph context, tools, rooms, Claims, and evidence required for their task. Keep recommendations, reviews, approvals, disputes, UDIDs, and state transitions distinct so decisions can be audited and challenged. A reviewer should be able to reconstruct what happened from the graph: Claim, evidence, authority, evaluation, decision, impact, and state change. ## Production checklist Before using the IXO Graph in a live workflow, confirm: * [ ] entities have stable identifiers * [ ] Claim types are defined * [ ] evidence requirements are explicit * [ ] authority rules are clear * [ ] agent permissions are scoped * [ ] workflow states are defined * [ ] Evaluation Claims have a structured schema * [ ] UDIDs record decision and impact determinations * [ ] state transitions are inspectable * [ ] disputes and corrections have a path * [ ] applications and agents can query only what they are allowed to access * [ ] verified outcomes can feed reporting, settlement, research, or learning loops ## IXO Graph in the stack Verifiable state, identities, Claims, credentials, assets, transactions, and protocol operations. Indexed IXO state for applications, dashboards, analytics, services, and agent context. Secure cooperation spaces where humans, agents, and services coordinate around graph-backed work. The coordination layer that lets humans, agents, applications, and services act over shared state. ## Next steps Build a POD, Flow, Blueprint, or Marketplace using IXO and Qi. Learn the vocabulary for entities, Claims, evidence, credentials, Flows, Blueprints, and outcomes. Evaluate agent work using UCAN authority, Claims, rubrics, evidence, Flow state, and UDIDs. Explore practical use cases for verified cooperation, digital MRV, outcome finance, marketplaces, and agent workflows.