> ## 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 PODs

> Programmable Organisational Domains for coordinating people, AI agents, services, workflows, evidence, and outcomes.

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.
</Tip>

## When to build a POD

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

<CardGroup cols={2}>
  <Card title="Program operations" icon="diagram-project">
    Coordinate funders, implementers, verifiers, researchers, agents, and services inside one program domain.
  </Card>

  <Card title="Verified service delivery" icon="handshake">
    Manage service providers, fulfillment Flows, Claims, evidence, review, settlement, and reputation.
  </Card>

  <Card title="Digital MRV" icon="chart-line">
    Connect measurements, reports, verification, Claims, outcomes, and funding decisions.
  </Card>

  <Card title="Marketplaces" icon="store">
    Operate trusted exchange for services, data, protocols, agent capabilities, or verified outcomes.
  </Card>

  <Card title="Research and learning" icon="microscope">
    Create a governed research space for data access, analysis, publication, and verified learning loops.
  </Card>

  <Card title="Multi-party governance" icon="scale-balanced">
    Coordinate decisions across humans, organizations, agents, services, and protocol-defined rules.
  </Card>
</CardGroup>

## What a POD contains

A POD brings together the core objects of IXO and Qi.

<AccordionGroup>
  <Accordion title="Domain identity">The POD’s verifiable identity and operating boundary</Accordion>

  <Accordion title="Members">People, organizations, services, and agents that participate</Accordion>

  <Accordion title="Roles">What each participant is responsible for</Accordion>

  <Accordion title="Permissions">What each participant is allowed to do</Accordion>

  <Accordion title="Entities">Projects, assets, devices, services, datasets, agents, Claims, outcomes, or other graph objects</Accordion>

  <Accordion title="Claims">Structured assertions about work, evidence, eligibility, delivery, compliance, or outcomes</Accordion>

  <Accordion title="Evidence">Documents, measurements, observations, attestations, media, reports, sensor data, or external records</Accordion>

  <Accordion title="Credentials">Qualifications, roles, authorizations, attestations, or rights</Accordion>

  <Accordion title="Flows">Workflows that coordinate actions, reviews, decisions, and state transitions</Accordion>

  <Accordion title="Blueprints">Protocols that define schemas, evidence rules, rubrics, authority, and outcomes</Accordion>

  <Accordion title="Agents">Agentic Oracles or AI services that support review, routing, analysis, monitoring, and decision support</Accordion>

  <Accordion title="Rooms">Secure cooperation spaces for humans, agents, and services</Accordion>

  <Accordion title="Value mechanisms">Payments, rewards, fees, credits, escrow, funding, or settlement rules</Accordion>

  <Accordion title="UDIDs">Decision and impact determinations that record what was decided, why, and with what effect</Accordion>
</AccordionGroup>

## How a POD works

<Steps>
  <Step title="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.
  </Step>

  <Step title="Participants are added">
    People, organizations, services, and agents are added with roles, credentials, and permissions.
  </Step>

  <Step title="Entities are represented">
    The POD connects relevant projects, assets, services, datasets, devices, Claims, outcomes, and agents into the IXO Graph.
  </Step>

  <Step title="Blueprints define the rules">
    Blueprints specify claim schemas, evidence requirements, rubrics, authority, decision logic, and allowed outcomes.
  </Step>

  <Step title="Flows run the work">
    Qi Flows coordinate submission, review, evaluation, approval, dispute, settlement, and closure.
  </Step>

  <Step title="Agents support the process">
    Agentic Oracles can inspect permitted context, apply rubrics, summarize evidence, flag risks, and create Evaluation Claims.
  </Step>

  <Step title="Humans remain accountable">
    High-value, disputed, uncertain, or irreversible actions can require human, governance, or protocol-controlled approval.
  </Step>

  <Step title="Decisions are recorded">
    When a Flow reaches a determination point, a UDID records the decision, evidence, authority, impact, and resulting state change.
  </Step>
</Steps>

## 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.
</Warning>

## 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:

<AccordionGroup>
  <Accordion title="`submitted`">A Claim, request, listing, or task enters the POD</Accordion>

  <Accordion title="`authority_check`">The POD checks role, credential, permission, or UCAN delegation</Accordion>

  <Accordion title="`evidence_required`">Required evidence is requested or validated</Accordion>

  <Accordion title="`evaluating`">A human, service, or Agentic Oracle applies the rubric</Accordion>

  <Accordion title="`review_required`">A verifier, operator, or governance role reviews the result</Accordion>

  <Accordion title="`determined`">A UDID records the decision and impact determination</Accordion>

  <Accordion title="`actioned`">Payment, credential, state update, message, or next Flow is triggered</Accordion>

  <Accordion title="`closed`">The process is complete and inspectable</Accordion>
</AccordionGroup>

## 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:

<AccordionGroup>
  <Accordion title="Read Claim">One Claim type in one Flow</Accordion>

  <Accordion title="Read evidence">Only evidence linked to that Claim</Accordion>

  <Accordion title="Read rubric">Only the active Blueprint version</Accordion>

  <Accordion title="Create Evaluation Claim">Structured recommendation with citations</Accordion>

  <Accordion title="Propose transition">Suggest next Flow state</Accordion>

  <Accordion title="Execute transition">Disabled until the workflow is proven safe</Accordion>
</AccordionGroup>

<Tip>
  Start with propose-only agents. Let humans, governance roles, or protocol-controlled checks decide when an agent recommendation becomes an approved state transition.
</Tip>

## Example: verified service marketplace POD

A marketplace operator creates a POD for evidence collection services.

<AccordionGroup>
  <Accordion title="Purpose">Help digital MRV programs find and pay verified field data providers</Accordion>

  <Accordion title="Members">Marketplace operator, service providers, buyers, verifiers, funders, agents</Accordion>

  <Accordion title="Entities">Providers, listings, projects, service orders, Claims, evidence, outcomes</Accordion>

  <Accordion title="Blueprint">Defines required evidence for completed field visits</Accordion>

  <Accordion title="Flow">Request service, accept order, deliver work, submit Claim, review evidence, settle payment</Accordion>

  <Accordion title="Agent">Evidence Review Oracle checks completeness, consistency, and missing fields</Accordion>

  <Accordion title="Human role">Verifier accepts, rejects, disputes, or requests more evidence</Accordion>

  <Accordion title="UDID">Records whether the service was accepted and whether payment should be released</Accordion>
</AccordionGroup>

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.

<AccordionGroup>
  <Accordion title="Purpose">Verify outcomes for a clean cooking, water, energy, land restoration, or biodiversity program</Accordion>

  <Accordion title="Members">Program operator, field teams, device providers, communities, verifiers, funders, researchers</Accordion>

  <Accordion title="Entities">Households, devices, projects, reporting periods, measurements, Claims, outcomes</Accordion>

  <Accordion title="Blueprint">Defines eligibility, evidence requirements, measurement methods, and verification rules</Accordion>

  <Accordion title="Flow">Submit measurement Claim, validate evidence, review, determine outcome, trigger settlement</Accordion>

  <Accordion title="Agent">Agentic Oracle summarizes evidence and flags anomalies</Accordion>

  <Accordion title="Human role">Verifier reviews edge cases and approves determinations</Accordion>

  <Accordion title="UDID">Records verified outcome and impact determination</Accordion>
</AccordionGroup>

## First implementation move

Start with one POD that runs one complete operating loop.

<Steps>
  <Step title="Define the purpose">
    State what the POD is responsible for. Use one sentence that names the domain, participants, and intended outcome.
  </Step>

  <Step title="Define the members">
    List the people, organizations, services, and agents that need to participate.
  </Step>

  <Step title="Define roles and authority">
    Specify who can submit, read, review, approve, dispute, pay, issue credentials, manage agents, or change rules.
  </Step>

  <Step title="Define the entities">
    Identify the projects, assets, services, datasets, devices, Claims, listings, agents, or outcomes the POD must represent.
  </Step>

  <Step title="Choose one Blueprint">
    Use one protocol to define the first Claim type, evidence requirements, rubric, and determination logic.
  </Step>

  <Step title="Run one Flow">
    Build the first workflow from submission to review, determination, action, and closure.
  </Step>

  <Step title="Add one agent carefully">
    Give the agent scoped access to one task, such as evidence summarization, completeness checking, or rubric scoring.
  </Step>

  <Step title="Test with real cases">
    Run complete, incomplete, rejected, disputed, and edge-case submissions before scaling.
  </Step>
</Steps>

## Design principles

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="Keep authority explicit">
    Every important action should be tied to a role, credential, permission, delegation, Flow state, or governance rule.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="Use Blueprints for repeatability">
    Put schemas, evidence requirements, rubrics, thresholds, disqualifiers, escalation rules, and outcome logic into a Blueprint.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## 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

<CardGroup cols={2}>
  <Card title="Build a Flow" icon="route" href="/guides/users/build-a-flow">
    Define the workflow that runs inside your POD.
  </Card>

  <Card title="Build a Blueprint" icon="file-signature" href="/guides/users/build-a-blueprint">
    Define the schemas, rules, evidence requirements, rubrics, and outcome logic.
  </Card>

  <Card title="Build a Marketplace" icon="store" href="/guides/users/build-a-market">
    Create trusted exchange for services, protocols, data, agent capabilities, or verified outcomes.
  </Card>

  <Card title="Agent Evaluations" icon="clipboard-check" href="/guides/dev/agent-evaluations">
    Evaluate agent work using Claims, evidence, UCAN authority, rubrics, Flow state, and UDIDs.
  </Card>
</CardGroup>