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.

​
Build a POD

A POD is a programmable organizational domain. It gives your initiative a governed workspace where members, agents, data, tools, workflows, credentials, claims, evidence, and outcomes can be coordinated. Build a POD when you need a secure operating space for a project, program, protocol, fund, community, organization, DAO, marketplace operator, or multi-party initiative.

POD Creator

Use the POD Creator Agentic Oracle in qi.space to turn your intent, organization details, participants, roles, and operating rules into a POD setup plan.

​
What you will create

  • POD name, purpose, and domain
  • Member roles and permissions
  • Rooms for coordination
  • Entities represented in the IXO graph
  • Credentials and capabilities required to act
  • Flows the POD can run
  • Blueprints the POD can use
  • Tools and Agentic Oracles available to the POD
  • Economic rules for value, rewards, fees, or settlement

​
Multi-party rooms and cooperation spaces

Build this into your POD when many participants need a secure shared space tied to real work, not a disconnected file share. The problem. Funders, implementers, verifiers, communities, experts, service providers, and agents often coordinate through email threads, messaging apps, shared drives, and meetings. Context gets lost. Evidence is separated from decisions. Agents cannot see the full workflow. Participants lack a shared operational record. What you build. A secure cooperation space where rooms, messages, files, agents, participants, evidence, and workflow state stay connected. Example. A program creates a room for a project or claim. Implementers upload evidence and updates. Agents summarize activity and flag missing information. Verifiers ask questions and record decisions. The room stays linked to the relevant entity, claim, workflow, and state changes. Start with one room type. Define:
  • what the room is attached to: program, project, entity, claim, or workflow
  • participant roles and permissions
  • what evidence or messages belong there
  • which agents or services can observe the room
  • which events should update or reference IXO-backed state

​
IXO and Qi roles

IXO Matrix

Provides secure rooms, messaging, and shared cooperation spaces.

IXO Graph

Links rooms to entities, claims, evidence, participants, workflows, and outcomes.

Qi

Lets humans, services, and agents coordinate over the same verified workflow context.

Matrix Client SDK

Supports room-aware applications, services, and integrations.

​
Next steps

IXO Matrix

Secure cooperation spaces and shared state patterns.

IXO Matrix Client SDK

Build room-aware applications and services.

Qi Intelligent Cooperating System

How humans, agents, applications, and services cooperate over IXO state.

IXO Graph

How rooms connect to entities, evidence, workflows, and outcomes.
For the full narrative and stack context, see Multi-party data rooms.

​
Quick start

1

Define the domain

Name the POD and describe the real-world system it governs. Be specific about the outcome, geography, sector, program, community, or organizational boundary.
2

Add the participants

List the people, organizations, services, agents, and external systems that need to act inside the POD. Assign each participant a role before adding permissions.
3

Map the core entities

Identify the projects, assets, claims, credentials, services, data sources, outcomes, or marketplaces that should exist as graph entities.
4

Configure rooms and tools

Create the working spaces where participants cooperate. Tie each room to a program, project, entity, claim, or workflow so messages, files, and decisions stay in the same operational context as IXO-backed state—not a loose chat or drive. Attach tools, Agentic Oracles, data sources, and workflows only where they are needed.
5

Attach flows and blueprints

Choose the first Flow the POD should run and the Blueprint that defines the rules for claims, evidence, review, verification, and state transitions.
6

Test the first operating loop

Run one realistic case from intake to decision. Confirm that roles, permissions, evidence, agent support, human review, and state changes work as expected.

​
Useful first scope

Start with one operational use case, such as:
  • onboarding an implementer
  • submitting a verified claim
  • reviewing evidence
  • approving an outcome
  • issuing a credential
  • releasing a payment
  • publishing a marketplace listing

​
Resources

Blueprints

Start from POD templates for programs, organizations, funds, marketplaces, verification domains, or multi-party workspaces.

Concepts

Learn how PODs connect identities, graph entities, rooms, tools, credentials, permissions, claims, evidence, and outcomes.

Code with AI

Generate POD configuration, role models, entity mappings, and test fixtures with an AI coding assistant.

Deep dive

Understand POD architecture, security boundaries, graph state, governance, agent access, and operational patterns.