> ## 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 > Set up a programmable organizational domain—a governed workspace for members, agents, claims, evidence, and outcomes. ## 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. 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 Provides secure rooms, messaging, and shared cooperation spaces. Links rooms to entities, claims, evidence, participants, workflows, and outcomes. Lets humans, services, and agents coordinate over the same verified workflow context. Supports room-aware applications, services, and integrations. #### Next steps Secure cooperation spaces and shared state patterns. Build room-aware applications and services. How humans, agents, applications, and services cooperate over IXO state. How rooms connect to entities, evidence, workflows, and outcomes. For the full narrative and stack context, see [Multi-party data rooms](/guides/what-you-can-build#multi-party-data-rooms). ### Quick start Name the POD and describe the real-world system it governs. Be specific about the outcome, geography, sector, program, community, or organizational boundary. List the people, organizations, services, agents, and external systems that need to act inside the POD. Assign each participant a role before adding permissions. Identify the projects, assets, claims, credentials, services, data sources, outcomes, or marketplaces that should exist as graph entities. 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. Choose the first Flow the POD should run and the Blueprint that defines the rules for claims, evidence, review, verification, and state transitions. 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 Start from POD templates for programs, organizations, funds, marketplaces, verification domains, or multi-party workspaces. Learn how PODs connect identities, graph entities, rooms, tools, credentials, permissions, claims, evidence, and outcomes. Generate POD configuration, role models, entity mappings, and test fixtures with an AI coding assistant. Understand POD architecture, security boundaries, graph state, governance, agent access, and operational patterns.