A POD is a Programmable Organisational Domain: a Qi workspace for one organisation, project or programme. It holds the members and their roles, the rooms they work in, the agents that help them, and the domains the work is about. Plan one when several parties (funders, implementers, reviewers, communities, service providers and agents) work on the same claims and evidence, and you need to say who may do what. This page helps you write that plan on paper.
This is a design guide. It helps you plan, and it gives you nothing to run. For paths you can follow to a working result today, see Choose your path.
| You end with | A POD design: its name and scope, its members and roles, its rooms, the domains it works with, its first Flow and Blueprint, and its rules for money. |
| Who decides | You set the roles, and each role's permissions say what its holder may do. A claim made in the POD is decided as it is anywhere on IXO: a decision oracle produces the facts and the IXO decision engine applies the rules. |
What you are designing
A POD is not a chat group or a shared drive. Each room is tied to a programme, a project, a domain, a claim or a Flow, so that messages, files and decisions stay with the records they are about.
| Part | What you decide |
|---|---|
| Name and scope | What the POD is for, and where its boundary is |
| Members and roles | Who takes part, and what each role may do |
| Credentials and capabilities | What someone must hold before they can act |
| Rooms | Where members coordinate, and what each room is attached to |
| Domains | The projects, assets, services and other things the POD works with |
| Flows and Blueprints | The steps the work follows, and the rules for its claims |
| Tools and agentic oracles | Which tools and agents the POD can use, and where |
| Economic rules | How value, rewards, fees or settlement work |
Design steps
Name the POD and its scope
Name the POD and describe the real-world system it covers. Be specific about the outcome, the place, the sector, and the programme, community or organisation it belongs to.
Pick the first use case
Start with one piece of work the POD must get done. For example: onboarding an implementer, submitting a claim, reviewing evidence, approving an outcome, issuing a credential, releasing a payment, or publishing a marketplace listing. Design the POD around that one case first.
List the members and give each a role
List the people, organisations, services, agents and outside systems that need to act inside the POD. Give each one a role before you write any permission. Then write what each role may do, and which credentials or capabilities its holder needs first.
List the domains
Write down what the POD works with that needs a domain of its own: projects, assets, services, data sources or marketplaces. Note the claims, credentials and outcomes the POD will record about them. Links between domains place them in a graph of relationships, which IXO Graph describes.
Plan the rooms
Start with one type of room. For that type, decide:
- what the room is attached to: a programme, a project, a domain, a claim or a Flow
- which roles are in it, and what each may do there
- which evidence and messages belong there
- which agents or services may observe it
- which events in the room should update a record on IXO, or refer to one
The rooms are IXO Matrix rooms. For example, a programme creates a room for one project. Implementers post evidence and updates there. An agent summarises the activity and flags what is missing. Reviewers ask their questions in the same room.
Place the tools and agents
Attach tools, agentic oracles, data sources and Flows only to the rooms that need them.
Choose the first Flow and Blueprint
Choose the first Flow the POD will run, and the Blueprint that sets the rules for its claims: the evidence, the review, and what each decision changes. Design a Flow and Design a Blueprint cover each one.
Set the rules for money
If value moves in the POD, write the rules for it: rewards, fees, and how settlement works.
Write one test case
Take one realistic case from intake to decision on paper. Check that your design says who holds each role, which permission each action needs, what evidence is required, what the agent does, where a person reviews, and which records change.
What a POD does not do
- It does not decide claims. A decision oracle produces the facts and the IXO decision engine applies the rules. Design an evaluator covers that part.
- It does not run the work. A Flow does that, under the rules of a Blueprint.
- It does not turn a message or a file into proof. A claim, its evidence and its decision are separate records. What each record proves says what each one shows.
Where a POD is built
Use the POD Creator agentic oracle in qi.space to turn your intent, organisation details, participants, roles and operating rules into a POD setup plan. This is its plugin reference.
IXO PODsWhat a POD contains and how it works, with two worked examples.
IXO MatrixThe encrypted rooms that members, agents and services share.
IXO Matrix Client SDKFor applications and services that work with rooms.