> ## Documentation Index > Fetch the complete documentation index at: https://ixoworld-canonical.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # What you can build > Start here when you want to turn an idea, program, protocol, service, or organization into a working system with shared state, governed workflows, evidence, verification, and economic coordination. Choose the build path that matches what you need first. If IXO and Qi are new, read [Core concepts](/core-concepts) for vocabulary, or [Act on Reality](/introduction) for the product story, then come back to pick a path. Create the programmable organizational domain where people, agents, apps, assets, claims, evidence, and outcomes operate together. Create a governed workflow that coordinates humans, Agentic Oracles, tools, evidence, decisions, and state changes. Design and operate Agentic Oracles that deliver services, automate tasks, inspect evidence, check rules, flag risks, and support human decisions. Define a reusable protocol for deeds, claims, evidence, roles, rubrics, rules, verifications, and settlements for PODs, Flows, assets, oracles, and markets. Model a real-world asset as a digital twin you can verify, link to claims and evidence, and exchange when your program allows it. Create a trusted exchange where participants can discover, offer, request, verify, and settle services, assets, outcomes, or deeds. Start small. A strong first build usually has one POD, one Flow, one claim type, one evidence standard, one review path, and one settlement action. ## How the pieces fit together A **POD** is the workspace. A **Flow** is how work moves. A **Blueprint** is the rulebook. **Agentic Oracles** carry out scoped automation and judgment. **Assets** (often as digital twins) are what you track, prove, or exchange. A **Market** is where discovery and settlement happen when many parties trade. **Use it to:** Create a secure domain for coordination. **First useful output:** Workspace, roles, entities, rooms, tools, and agents. **Use it to:** Run work through clear steps. **First useful output:** Trigger, states, actions, reviews, and state changes. **Use it to:** Automate or assist steps with bounded tools, context, and oversight. **First useful output:** Services, evaluations, summaries, checks, and handoffs into human decisions. **Use it to:** Standardize how something is done. **First useful output:** Claim schema, evidence rules, rubric, permissions, and outcomes. **Use it to:** Represent something real on the graph with identity, history, and verifiable updates. **First useful output:** A governed entity you can link to claims, credentials, workflows, and markets. **Use it to:** Enable discovery and settlement. **First useful output:** Listings, offers, verification rules, pricing, and fulfillment logic. In practice those blocks combine into recurring **program shapes**. For shared vocabulary first, read [Core concepts](/core-concepts). Open a shape below for how it uses **state, claims, evidence, and cooperation** on the stack, then follow **Start here** for a hands-on guide. **Primary job:** Prove assertions and resolve decisions with an inspectable trail. **Stack:** The [IXO Graph](/articles/ixo-graph) connects claimants, subjects, **claims**, **evidence**, reviewers, and outcomes in one shared map. The [IXO Protocol](/protocols/ixo-protocol) provides the primitives for entities, claims, **credentials**, and verifiable **state** changes. [Qi](/articles/qi-intelligent-cooperating-system) coordinates humans, agents, and services around the same workflow **context** so reviews and decisions stay aligned with protocol-backed truth—not siloed documents. **Start here:** [Verified claims](/guides/users/build-a-claim-collection) **Primary job:** Turn measurements and reports into verified outcomes programs can trust. **Stack:** Field and lab data become **evidence** linked to **claims** and entities on the [IXO Graph](/articles/ixo-graph). [IXO Blocksync](/articles/ixo-blocksync) indexes protocol events and state so dashboards, analytics, and tools can query history and relationships at scale. **Agentic Oracles** may pre-check completeness or consistency; humans or governed processes still attest what counts as verified. **Start here:** [Build digital MRV](/guides/users/build-dmrv) **Primary job:** Move value only after agreed outcomes are evidenced and accepted under rules. **Stack:** Outcomes are expressed as **claims** with **evidence** and reviewed through **workflows**; settlement is a protocol- and credential-aware **action** on state (for example assets, accounts, or governance transitions—see [IXO Protocol](/protocols/ixo-protocol)). The graph ties funders, implementers, and outcomes so “what was verified” and “what was paid” stay linked. **Start here:** [Build OBF](/guides/users/build-obf) **Primary job:** Use agents safely inside verification—bounded tools, IXO-backed context, human handoff. **Stack:** [Qi](/articles/qi-intelligent-cooperating-system) supplies **cooperation** over verified state; **Agentic Oracles** read graph context and act through declared interfaces (including [MCP](/mcp/model-context-protocol) where tools are exposed to models). Agents support review; they do not replace **authority** or protocol rules. A [Flow](/guides/users/build-a-flow) defines states, evidence gates, and escalation. **Start here:** [Build a Flow](/guides/users/build-a-flow) **Primary job:** Create a secure domain for coordination. **Stack:** [IXO Graph](/articles/ixo-graph) connects claimants, subjects, **claims**, **evidence**, reviewers, and outcomes in one shared map. [IXO Protocol](/protocols/ixo-protocol) provides the primitives for entities, claims, **credentials**, and verifiable **state** changes. [Qi](/articles/qi-intelligent-cooperating-system) coordinates humans, agents, and services around the same workflow **context** so reviews and decisions stay aligned with protocol-backed truth—not siloed documents. **Start here:** [Verified claims](/guides/users/build-a-claim-collection) ## Before you start Gather these inputs before using a builder or Agentic Oracle. You do not need every answer on day one—treat this as a living checklist. What real-world outcome should the system produce? Who acts, reviews, verifies, funds, governs, or receives value? What people, organizations, assets, projects, services, claims, or outcomes need to exist in the graph? What documents, measurements, observations, attestations, media, reports, sensor data, or external records prove what happened? Who has permission to submit, review, approve, dispute, pay, publish, or update state? What value is exchanged, rewarded, reserved, released, or settled? What decisions need human approval, automated review, or escalation? What outcomes should be fed back into models, programs, governance, and future workflow automation? What tools, data sources, or external systems are available to the system? What steps need to be taken to produce the outcome? What messages, emails, alerts, or events should be sent to participants? What metrics, logs, events, or alerts should be collected and analyzed? What should happen if the system fails to produce the outcome? When work is blocked or cannot complete, who decides the next step (escalation), and how do you restore integrity of data, permissions, or service (recovery)? What tests should be run to confirm the system is working as expected? What documentation should be created to explain the system? What training should be provided to the participants? ## Recommended first build paths Start with a POD. Then add one Flow and one Blueprint for the most important operating loop. Start with a Flow. Then attach a Blueprint so every action has clear rules and evidence requirements. Start with the Flow that needs help, then add Agentic Oracles with narrow tools and clear handoffs. See also [Oracle architecture](/guides/ixo-oracles-architecture). Start with a Blueprint. Then run it inside a POD through a Flow that tests real submissions. Start from the Digital twins guide, then connect claims, evidence, and Flows to what the asset represents in the real world. Start with a Market. Then define the fulfillment Flow and verification Blueprint behind each listing. ### Cross-cutting outcomes (after your first loop) When the basics work, add depth with these focused guides—each assumes you already have (or will add) a POD and Flow. One end-to-end pattern for submit → evidence → review → decision. Measurement, reporting, and verification as one auditable workflow. Tie settlement to verified outcomes instead of schedules alone. ## Production checklist Use this checklist before inviting external participants. Confirm the POD has a clear purpose, named operators, member roles, permission boundaries, rooms, tools, Agentic Oracles, entity mappings, and governance rules. Confirm the Flow has a trigger, states, actors, permissions, evidence requirements, escalation paths, decision outputs, and test cases for failure conditions. Confirm the Blueprint has schemas, evidence rules, review rubrics, role authority, state transition logic, versioning, and dispute handling. Confirm the Market has listing rules, participant onboarding, fulfillment flows, verification logic, settlement rules, moderation, dispute handling, and operating metrics. Confirm each Agentic Oracle has scoped permissions, tool access, context boundaries, human oversight, logging, evaluation criteria, and a clear handoff path. For production oracle services, review [Oracle architecture](/guides/ixo-oracles-architecture) for deployment and trust boundaries. ## Keep improving Once your first build is running, use verified outcomes to improve the system. Review claims, evidence, decisions, state changes, payments, disputes, and completion times. Look for missing evidence, unclear authority, slow reviews, repeated escalations, rejected claims, or settlement delays. Improve the workflow, rubric, evidence rules, agent instructions, or governance logic based on real operating data. Add more participants, listings, protocols, services, agents, or domains only after the first operating loop is stable. ## Architecture path After choosing a workflow, use the architecture docs to understand the stack in depth. Learn the vocabulary for IXO, Qi, state, evidence, claims, workflows, and agents. Understand the shared map of entities, relationships, evidence, and verifiable change. Understand protocol primitives for verifiable state and coordination. Understand human-agent-service cooperation over IXO-backed state. For the product narrative and a worked claims example, see [Act on Reality](/introduction). This page stays focused on **which** to build first and **how** the pieces connect.