Skip to main content
Choose the build path that matches what you need first. If IXO and Qi are new, read Core concepts for vocabulary, or Act on Reality for the product story, then come back to pick a path.

Build a POD

Create the programmable organizational domain where people, agents, apps, assets, claims, evidence, and outcomes operate together.

Build a Flow

Create a governed workflow that coordinates humans, Agentic Oracles, tools, evidence, decisions, and state changes.

Build an Oracle

Design and operate Agentic Oracles that deliver services, automate tasks, inspect evidence, check rules, flag risks, and support human decisions.

Build a Blueprint

Define a reusable protocol for deeds, claims, evidence, roles, rubrics, rules, verifications, and settlements for PODs, Flows, assets, oracles, and markets.

Build an Asset

Model a real-world asset as a digital twin you can verify, link to claims and evidence, and exchange when your program allows it.

Build a Market

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. 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 connects claimants, subjects, claims, evidence, reviewers, and outcomes in one shared map. The IXO Protocol provides the primitives for entities, claims, credentials, and verifiable state changes. Qi 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
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. 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
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). The graph ties funders, implementers, and outcomes so “what was verified” and “what was paid” stay linked.Start here: Build OBF
Primary job: Use agents safely inside verification—bounded tools, IXO-backed context, human handoff.Stack: Qi supplies cooperation over verified state; Agentic Oracles read graph context and act through declared interfaces (including MCP where tools are exposed to models). Agents support review; they do not replace authority or protocol rules. A Flow defines states, evidence gates, and escalation.Start here: Build a Flow
Primary job: Create a secure domain for coordination.Stack: IXO Graph connects claimants, subjects, claims, evidence, reviewers, and outcomes in one shared map. IXO Protocol provides the primitives for entities, claims, credentials, and verifiable state changes. Qi 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

​
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?

I have an organization or program

Start with a POD. Then add one Flow and one Blueprint for the most important operating loop.

I have a process to automate

Start with a Flow. Then attach a Blueprint so every action has clear rules and evidence requirements.

I need agents in the workflow

Start with the Flow that needs help, then add Agentic Oracles with narrow tools and clear handoffs. See also Oracle architecture.

I have a protocol or standard

Start with a Blueprint. Then run it inside a POD through a Flow that tests real submissions.

I need a real-world asset digital twin

Start from the Digital twins guide, then connect claims, evidence, and Flows to what the asset represents in the real world.

I want participants to exchange value

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.

Verified claims

One end-to-end pattern for submit → evidence → review → decision.

Digital MRV

Measurement, reporting, and verification as one auditable workflow.

Outcomes-based financing

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 for deployment and trust boundaries.

​
Keep improving

Once your first build is running, use verified outcomes to improve the system.
1

Inspect what happened

Review claims, evidence, decisions, state changes, payments, disputes, and completion times.
2

Identify bottlenecks

Look for missing evidence, unclear authority, slow reviews, repeated escalations, rejected claims, or settlement delays.
3

Update the Flow or Blueprint

Improve the workflow, rubric, evidence rules, agent instructions, or governance logic based on real operating data.
4

Scale through the POD or Market

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.

Core concepts

Learn the vocabulary for IXO, Qi, state, evidence, claims, workflows, and agents.

IXO Graph

Understand the shared map of entities, relationships, evidence, and verifiable change.

IXO Protocol

Understand protocol primitives for verifiable state and coordination.

Qi Intelligent Cooperating System

Understand human-agent-service cooperation over IXO-backed state.
For the product narrative and a worked claims example, see Act on Reality. This page stays focused on which to build first and how the pieces connect.