Skip to main content
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

Entities

People, organizations, projects, assets, devices, services, agents, datasets, places, programs, workflows, and outcomes.

Claims and evidence

Assertions about delivery, eligibility, compliance, performance, impact, or state, linked to supporting evidence.

Credentials and authority

Roles, permissions, qualifications, attestations, delegations, and rights to act.

Transactions and state changes

Records of what changed, who changed it, when it changed, and which protocol operation or workflow caused it.

Flows and cooperation spaces

Workflow state, rooms, messages, agent actions, human review, escalations, and next steps.

Outcomes and determinations

Verified results, decisions, impacts, approvals, disputes, payments, credentials, and learning loops.

​
How it works

1

Represent the thing

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.
2

Connect identity and authority

The entity is linked to identities, domains, credentials, roles, permissions, or delegations that define who can act.
3

Attach Claims and evidence

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.
4

Record workflow state

Qi Flows coordinate the Claim through intake, review, evaluation, approval, dispute, settlement, or closure.
5

Record change over time

Transactions, attestations, Flow events, Evaluation Claims, and UDIDs create an inspectable history of what changed and why.
6

Enable the next action

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.
1

The service provider is represented

The provider exists as an entity with an identity, credentials, service profile, and marketplace listing.
2

The work is requested

A buyer requests the service through a Marketplace. A Qi Flow starts the fulfillment process.
3

The provider submits a Claim

The provider submits a Claim that field visits were completed for a specific project, location, and reporting period.
4

Evidence is linked

The Claim links to field reports, timestamps, location records, photos, device references, or verifier attestations.
5

An agent evaluates the Claim

An Agentic Oracle inspects only the context it is authorized to access, applies the active rubric, and creates an Evaluation Claim.
6

A verifier makes a determination

A human verifier accepts, rejects, disputes, or requests more evidence. The decision is recorded as a UDID when the Flow reaches a determination point.
7

The Flow triggers settlement

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

Claim and evidence review

Let participants submit Claims, attach evidence, route review, record Evaluation Claims, and issue determinations.

Digital MRV

Connect measurements, reports, verification events, attestations, outcomes, and funding logic.

Verified service marketplaces

Link providers, buyers, listings, orders, fulfillment Claims, evidence, review, settlement, and reputation.

Outcome-based financing

Release value when Claims and evidence satisfy protocol rules and a determination is recorded.

Agentic evidence review

Give agents scoped access to graph context, evidence, rubrics, and tools so they can support review without becoming final authority.

Verified learning loops

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.
1

Choose the entity

Decide what the graph should represent first. Examples: service provider, project, device, household, marketplace listing, dataset, agent, or outcome.
2

Define the Claim

Specify what can be asserted about that entity. Include the Claim type, issuer, subject, required fields, and evidence requirements.
3

Define authority

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.
4

Attach a Flow

Route the Claim through submission, review, evaluation, determination, action, and closure.
5

Record the determination

Use a UDID when the Flow reaches a decision and impact determination point.
6

Inspect and improve

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

IXO Protocol

Verifiable state, identities, Claims, credentials, assets, transactions, and protocol operations.

IXO Blocksync

Indexed IXO state for applications, dashboards, analytics, services, and agent context.

IXO Matrix

Secure cooperation spaces where humans, agents, and services coordinate around graph-backed work.

Qi Intelligent Cooperating System

The coordination layer that lets humans, agents, applications, and services act over shared state.

​
Next steps

Start Building

Build a POD, Flow, Blueprint, or Marketplace using IXO and Qi.

Core Concepts

Learn the vocabulary for entities, Claims, evidence, credentials, Flows, Blueprints, and outcomes.

Agent Evaluations

Evaluate agent work using UCAN authority, Claims, rubrics, evidence, Flow state, and UDIDs.

What You Can Build

Explore practical use cases for verified cooperation, digital MRV, outcome finance, marketplaces, and agent workflows.