Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.ixo.world/llms.txt

Use this file to discover all available pages before exploring further.

An IXO POD is a Programmable Organisational Domain. It is a secure operating domain where people, organizations, AI agents, services, tools, Claims, evidence, credentials, workflows, and value can cooperate around a shared purpose. Use a POD when work needs to happen across multiple actors and the system must know:
  • who is involved
  • what each actor is allowed to do
  • which entities, Claims, evidence, and outcomes matter
  • which Flows run the work
  • which Blueprints define the rules
  • which agents and services may act
  • which decisions, payments, credentials, or state changes are allowed
A POD is not just a workspace, DAO, database, or chatbot. It is the governed domain where shared state, human roles, agent authority, workflows, and verifiable outcomes come together.

​
When to build a POD

Build a POD when you need a governed operating space for a real-world initiative.

Program operations

Coordinate funders, implementers, verifiers, researchers, agents, and services inside one program domain.

Verified service delivery

Manage service providers, fulfillment Flows, Claims, evidence, review, settlement, and reputation.

Digital MRV

Connect measurements, reports, verification, Claims, outcomes, and funding decisions.

Marketplaces

Operate trusted exchange for services, data, protocols, agent capabilities, or verified outcomes.

Research and learning

Create a governed research space for data access, analysis, publication, and verified learning loops.

Multi-party governance

Coordinate decisions across humans, organizations, agents, services, and protocol-defined rules.

​
What a POD contains

A POD brings together the core objects of IXO and Qi.
The POD’s verifiable identity and operating boundary
People, organizations, services, and agents that participate
What each participant is responsible for
What each participant is allowed to do
Projects, assets, devices, services, datasets, agents, Claims, outcomes, or other graph objects
Structured assertions about work, evidence, eligibility, delivery, compliance, or outcomes
Documents, measurements, observations, attestations, media, reports, sensor data, or external records
Qualifications, roles, authorizations, attestations, or rights
Workflows that coordinate actions, reviews, decisions, and state transitions
Protocols that define schemas, evidence rules, rubrics, authority, and outcomes
Agentic Oracles or AI services that support review, routing, analysis, monitoring, and decision support
Secure cooperation spaces for humans, agents, and services
Payments, rewards, fees, credits, escrow, funding, or settlement rules
Decision and impact determinations that record what was decided, why, and with what effect

​
How a POD works

1

A domain is created

The POD is created for a specific purpose, such as a program, marketplace, fund, research initiative, verification network, or service operation.
2

Participants are added

People, organizations, services, and agents are added with roles, credentials, and permissions.
3

Entities are represented

The POD connects relevant projects, assets, services, datasets, devices, Claims, outcomes, and agents into the IXO Graph.
4

Blueprints define the rules

Blueprints specify claim schemas, evidence requirements, rubrics, authority, decision logic, and allowed outcomes.
5

Flows run the work

Qi Flows coordinate submission, review, evaluation, approval, dispute, settlement, and closure.
6

Agents support the process

Agentic Oracles can inspect permitted context, apply rubrics, summarize evidence, flag risks, and create Evaluation Claims.
7

Humans remain accountable

High-value, disputed, uncertain, or irreversible actions can require human, governance, or protocol-controlled approval.
8

Decisions are recorded

When a Flow reaches a determination point, a UDID records the decision, evidence, authority, impact, and resulting state change.

​
PODs and the IXO Graph

A POD operates over the IXO Graph. The graph gives the POD shared context for:
  • identities and roles
  • entities and relationships
  • Claims and evidence
  • credentials and authority
  • workflow state
  • transactions and state changes
  • evaluations and determinations
  • outcomes and learning loops
This prevents the POD from depending on disconnected spreadsheets, private databases, chat history, or agent memory as the system of record.
Do not use a POD as a loose collection of tools. Model the entities, Claims, evidence, permissions, Flows, and decisions that must be inspected or acted on.

​
PODs and Qi Flows

Qi Flows are the operating procedures inside a POD. A Flow defines:
  • what starts the process
  • who can act
  • which state the work is in
  • which evidence is required
  • which tools and agents may be used
  • which checks must pass
  • which decisions need human review
  • which state transitions are allowed
  • which payments, credentials, messages, or next actions may be triggered
Example Flow states:
A Claim, request, listing, or task enters the POD
The POD checks role, credential, permission, or UCAN delegation
Required evidence is requested or validated
A human, service, or Agentic Oracle applies the rubric
A verifier, operator, or governance role reviews the result
A UDID records the decision and impact determination
Payment, credential, state update, message, or next Flow is triggered
The process is complete and inspectable

​
PODs and agent authority

Agents can participate in a POD, but they should not have open-ended authority. Use scoped permissions or UCAN-style delegation to define:
  • which agent may act
  • which POD, Flow, Claim, room, tool, or evidence set it may access
  • which capability it may use
  • whether it may read, evaluate, propose, or execute
  • when the authority expires
  • which actions require human approval
  • how the action is logged
A safe first pattern is:
One Claim type in one Flow
Only evidence linked to that Claim
Only the active Blueprint version
Structured recommendation with citations
Suggest next Flow state
Disabled until the workflow is proven safe
Start with propose-only agents. Let humans, governance roles, or protocol-controlled checks decide when an agent recommendation becomes an approved state transition.

​
Example: verified service marketplace POD

A marketplace operator creates a POD for evidence collection services.
Help digital MRV programs find and pay verified field data providers
Marketplace operator, service providers, buyers, verifiers, funders, agents
Providers, listings, projects, service orders, Claims, evidence, outcomes
Defines required evidence for completed field visits
Request service, accept order, deliver work, submit Claim, review evidence, settle payment
Evidence Review Oracle checks completeness, consistency, and missing fields
Verifier accepts, rejects, disputes, or requests more evidence
Records whether the service was accepted and whether payment should be released
The POD gives the marketplace an operating boundary. The Flow runs the work. The Blueprint defines the rules. Claims and evidence make delivery inspectable. The UDID records the decision and impact.

​
Example: digital MRV program POD

A climate program creates a POD to coordinate monitoring, reporting, and verification.
Verify outcomes for a clean cooking, water, energy, land restoration, or biodiversity program
Program operator, field teams, device providers, communities, verifiers, funders, researchers
Households, devices, projects, reporting periods, measurements, Claims, outcomes
Defines eligibility, evidence requirements, measurement methods, and verification rules
Submit measurement Claim, validate evidence, review, determine outcome, trigger settlement
Agentic Oracle summarizes evidence and flags anomalies
Verifier reviews edge cases and approves determinations
Records verified outcome and impact determination

​
First implementation move

Start with one POD that runs one complete operating loop.
1

Define the purpose

State what the POD is responsible for. Use one sentence that names the domain, participants, and intended outcome.
2

Define the members

List the people, organizations, services, and agents that need to participate.
3

Define roles and authority

Specify who can submit, read, review, approve, dispute, pay, issue credentials, manage agents, or change rules.
4

Define the entities

Identify the projects, assets, services, datasets, devices, Claims, listings, agents, or outcomes the POD must represent.
5

Choose one Blueprint

Use one protocol to define the first Claim type, evidence requirements, rubric, and determination logic.
6

Run one Flow

Build the first workflow from submission to review, determination, action, and closure.
7

Add one agent carefully

Give the agent scoped access to one task, such as evidence summarization, completeness checking, or rubric scoring.
8

Test with real cases

Run complete, incomplete, rejected, disputed, and edge-case submissions before scaling.

​
Design principles

Do not begin by modeling the whole organization. Start with one repeatable process that creates, reviews, determines, and acts on Claims.
Every important action should be tied to a role, credential, permission, delegation, Flow state, or governance rule.
Agent outputs should be recorded as Evaluation Claims. Decisions and impacts should be recorded as UDIDs when the Flow reaches a determination point.
Put schemas, evidence requirements, rubrics, thresholds, disqualifiers, escalation rules, and outcome logic into a Blueprint.
A reviewer should be able to reconstruct what happened from the POD record: actor, authority, Claim, evidence, evaluation, decision, impact, and state change.
Keep high-value, irreversible, ambiguous, or contested actions under human or governance review until the Flow has enough operating history.

​
Production checklist

Before inviting external participants, confirm:
  • the POD has a clear purpose
  • members and roles are defined
  • authority rules are explicit
  • entities have stable identifiers
  • Claim types are defined
  • evidence requirements are clear
  • at least one Blueprint is attached
  • at least one Flow is configured
  • agent permissions are scoped
  • human review is required for high-risk decisions
  • Evaluation Claims have a structured schema
  • UDIDs are used for decision and impact determinations
  • payments, credentials, and state updates require valid authority
  • disputes and corrections have a path
  • participants know where to act and what happens next
  • the POD history can be inspected and replayed

​
What to build next

Build a Flow

Define the workflow that runs inside your POD.

Build a Blueprint

Define the schemas, rules, evidence requirements, rubrics, and outcome logic.

Build a Marketplace

Create trusted exchange for services, protocols, data, agent capabilities, or verified outcomes.

Agent Evaluations

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