IXO PODs

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

Tip

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.

Domain identity

The POD’s verifiable identity and operating boundary

Members

People, organizations, services, and agents that participate

Roles

What each participant is responsible for

Permissions

What each participant is allowed to do

Entities

Projects, assets, devices, services, datasets, agents, Claims, outcomes, or other graph objects

Claims

Structured assertions about work, evidence, eligibility, delivery, compliance, or outcomes

Evidence

Documents, measurements, observations, attestations, media, reports, sensor data, or external records

Credentials

Qualifications, roles, authorizations, attestations, or rights

Flows

Workflows that coordinate actions, reviews, decisions, and state transitions

Blueprints

Protocols that define schemas, evidence rules, rubrics, authority, and outcomes

Agents

Agentic Oracles or AI services that support review, routing, analysis, monitoring, and decision support

Rooms

Secure cooperation spaces for humans, agents, and services

Value mechanisms

Payments, rewards, fees, credits, escrow, funding, or settlement rules

UDIDs

Decision and impact determinations that record what was decided, why, and with what effect

How a POD works

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.

Participants are added

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

Entities are represented

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

Blueprints define the rules

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

Flows run the work

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

Agents support the process

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

Humans remain accountable

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

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.

Warning

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:

`submitted`

A Claim, request, listing, or task enters the POD

`authority_check`

The POD checks role, credential, permission, or UCAN delegation

`evidence_required`

Required evidence is requested or validated

`evaluating`

A human, service, or Agentic Oracle applies the rubric

`review_required`

A verifier, operator, or governance role reviews the result

`determined`

A UDID records the decision and impact determination

`actioned`

Payment, credential, state update, message, or next Flow is triggered

`closed`

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:

Read Claim

One Claim type in one Flow

Read evidence

Only evidence linked to that Claim

Read rubric

Only the active Blueprint version

Create Evaluation Claim

Structured recommendation with citations

Propose transition

Suggest next Flow state

Execute transition

Disabled until the workflow is proven safe

Tip

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.

Purpose

Help digital MRV programs find and pay verified field data providers

Members

Marketplace operator, service providers, buyers, verifiers, funders, agents

Entities

Providers, listings, projects, service orders, Claims, evidence, outcomes

Blueprint

Defines required evidence for completed field visits

Flow

Request service, accept order, deliver work, submit Claim, review evidence, settle payment

Agent

Evidence Review Oracle checks completeness, consistency, and missing fields

Human role

Verifier accepts, rejects, disputes, or requests more evidence

UDID

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.

Purpose

Verify outcomes for a clean cooking, water, energy, land restoration, or biodiversity program

Members

Program operator, field teams, device providers, communities, verifiers, funders, researchers

Entities

Households, devices, projects, reporting periods, measurements, Claims, outcomes

Blueprint

Defines eligibility, evidence requirements, measurement methods, and verification rules

Flow

Submit measurement Claim, validate evidence, review, determine outcome, trigger settlement

Agent

Agentic Oracle summarizes evidence and flags anomalies

Human role

Verifier reviews edge cases and approves determinations

UDID

Records verified outcome and impact determination

First implementation move

Start with one POD that runs one complete operating loop.

Define the purpose

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

Define the members

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

Define roles and authority

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

Define the entities

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

Choose one Blueprint

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

Run one Flow

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

Add one agent carefully

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

Test with real cases

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

Design principles

Start with the operating loop

Do not begin by modeling the whole organization. Start with one repeatable process that creates, reviews, determines, and acts on Claims.

Keep authority explicit

Every important action should be tied to a role, credential, permission, delegation, Flow state, or governance rule.

Separate recommendation from decision

Agent outputs should be recorded as Evaluation Claims. Decisions and impacts should be recorded as UDIDs when the Flow reaches a determination point.

Use Blueprints for repeatability

Put schemas, evidence requirements, rubrics, thresholds, disqualifiers, escalation rules, and outcome logic into a Blueprint.

Design for audit and dispute

A reviewer should be able to reconstruct what happened from the POD record: actor, authority, Claim, evidence, evaluation, decision, impact, and state change.

Do not over-automate early

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.