IOI: Internet of Intelligence Technical Whitepaper

Ledger, Heath; IOI Foundation

doi:10.5281/zenodo.21610908

IOI: Internet of Intelligence Technical Whitepaper

How IOI turns intelligence into bounded autonomous institutions: one governed system distributing work across compute, state, verification, people, and devices; selective cooperation between sovereign systems through AIIP; and optional IOI L1 shared-trust and settlement services.

IOI: Internet of Intelligence
Technical Whitepaper
The Open Operating Stack for Bounded Autonomous Institutions
Date: July 2026
Version: 1.10.0
Author: Heath Ledger
IOI Foundation IOI Foundation Internet of Intelligence Technical Whitepaper v1.10.0\

Abstract

IOI is the open operating stack that turns intelligence into bounded autonomous institutions. It supplies the semantic, execution, authority, state, evidence, collaboration, and economic protocols required for software intelligences to pursue durable goals and act across digital or physical systems while remaining inside explicit constitutions.

The stack has three layers. IOI L0 makes one constitution-bound institution safely distributable across governed compute, state, verification, human, and embodied nodes close to its users, data, tools, and infrastructure. AIIP makes selective, positive-surplus interoperation between separately sovereign institutions contractible through typed terms, work, evidence, and contribution exchange. IOI L1 offers explicitly enrolled systems optional shared registry, rights, assurance, dispute, settlement, and economic-finality services. Local operation remains useful on its own; network participation adds reach and shared trust.

IOI composes locally canonical semantic world planes with constitution-bound runtimes and permits explicit versioned mappings where federation creates value. Each system binds the domain semantics appropriate to its profile; shared ontologies make objects, relationships, events, claims, actions, policies, and goals interoperable where federation requires it. Hypervisor turns those semantics into governed agency; wallet.network or applicable domain governance supplies scoped authority; Agentgres admits operational truth; and cryptographic receipts bind consequential transitions to their policy, evidence, and result. This is IOI's formulation of Web4: Read + Write + Own + Act, under machine authority.

For enterprises, this composition creates a governed learning boundary rather than another model wrapper. Foundation models remain replaceable cognition suppliers; the institution retains the ontology, admitted memory, corrections, private evaluations, policies, workflows, datasets, lineage, and rights-eligible derived capability that make its intelligence particular. A versioned InstitutionalLearningBoundaryProfile compiles source rights, policy-bound views, model-route rights, custody, training eligibility, retention, export, and revocation into one fail-closed system boundary. This profile joins Hypervisor, Agentgres, Foundry, Private Workspace, Ontology/Data, and model-neutral routing without becoming a new runtime, authority plane, truth store, application, or privacy tier.

Same-system distribution is a primary use of the stack rather than a preliminary replication trick. One system may place useful work across execution nodes, verifiers, gateways, people, robots, drones, sensors, and local controllers under one constitution, membership and authority model, operational truth, and lifecycle. Logical work assignment, partition behavior, reassignment, failover, replay, and duplicate-effect prevention remain governed even when no external counterparty or public consensus exists. This native L0 and Embodied Runtime coordination is not AIIP.

The Internet of Intelligence emerges where independently governed systems hold complementary capabilities, data-derived evidence, authority, locality, resources, demand, or verification capacity and can create more value through a bounded exchange than through their best permitted standalone alternatives. IOI makes that cooperation surplus contractible: systems negotiate one exact terms root, lease only the required capabilities and resources, preserve contribution and rights lineage, settle accepted value, and exit with permitted state. Collective intelligence is voluntary accountable cooperation among sovereign systems, rather than centralized custody or presumed federation.

This paper presents that target architecture and its security and economic logic. It is the publishing synthesis for contributors, reviewers, and early integrators. Subject-specific owner documents in docs/architecture remain authoritative for detailed contracts, terminology, implementation status, and conformance; this paper is reconciled to those owners as the system evolves.

Executive Summary

IOI defines the canonical Web4 target as an open, edge-sovereign operating fabric for governed autonomous systems. Web4 is the protocol category in which systems can Read + Write + Own + Act, under machine authority: autonomous systems may understand domain meaning, pursue goals, collaborate across sovereign boundaries, and execute anywhere, while IOI settles only commitments that require public, economic, rights, registry, governance, or dispute trust.

The ontology-centered operating environment and the Type 1/2/3 Hypervisor are complementary planes of one architecture, not competing product theses. Federated Domain Ontologies define what objects, relationships, events, claims, actions, policies, and goals mean. The collective-intelligence plane defines how intelligences discover, divide, attempt, verify, challenge, and course-correct work. Hypervisor Type 3 virtualizes agency, context, memory, tools, authority, evidence, and effects; Type 1 and Type 2 provide substrate control, custody, isolation, locality, and operator experience. Domain Ontologies make the world legible; Hypervisor makes action in that world governable. IOI is not a decentralized clone of a centralized enterprise ontology database, a VM manager with agents attached, or two loosely related products.

IOI is not only a model network and not only a safety layer. It is an intent-to-outcome and collective-pursuit fabric: demand enters as a job to be done, and supply is an open set of compute, data, models, workers, tools, services, evaluations, and workflows. The organizing security problem is machine authority: when software can spend money, execute code, use credentials, mutate durable state, affect third-party rights, or trigger settlement, safety cannot rest on an unverifiable model response. IOI provides alignment security by moving enforceable guarantees into explicit authority grants, deterministic runtime boundaries, canonical state transitions, receipt obligations, evidence bundles, and dispute-aware settlement.

The architectural boundary between model reasoning and economic consequence is the Determinism Boundary. Operationally, this boundary is expressed through the Intent Resolution Contract (CIRC), the Effect Execution Contract (CEC), the Hypervisor Daemon effect boundary, and HarnessProfile adapter conformance. Upstream of the boundary, workers may use any cognition backend: hosted frontier models, local open-weight models, retrieval systems, deterministic tools, verifier ensembles, or mixtures of those systems. Downstream of the boundary, a deterministic runtime normalizes the requested act, checks capabilities and authority, enforces policy, and emits receipts that can support audit, insurance, arbitration, and settlement. Validity is defined by evidence, not by hardware: private execution can be satisfied by TEEs, zero-knowledge proofs, verifiable computation, MPC, FHE, deterministic replay, cTEE/private-workspace receipts, or hybrid bundles, with the receipt set defined by the action class.

IOI treats the Worker, not the model, as the protocol actor. A worker has a manifest, policy envelope, capability surface, receipt obligations, identity, and settlement posture. The model is a component mounted by the worker. This distinction enables Mixture of Workers: routed labor graphs in which planners, executors, verifiers, tools, and services can be selected, paid, benchmarked, and disputed as accountable contributors.

This is why the Worker is the economic actor. The model supplies cognition; the worker supplies bounded agency. Authority, receipts, contribution accounting, reputation, disputes, and settlement attach to the worker and its manifest, not merely to whichever model powered one reasoning step.

Worker Training, WorkerPackages, ServicePackages, and Service Modules create the supply side of the MoW worker economy. A customer or builder does not merely buy a fine-tuned model; they produce trained, evaluated, policy-bound workers, reusable modules, or configured service outcomes with manifests, lineage refs, benchmark receipts, evaluation receipts, authority requirements, and contribution policy. Hypervisor Foundry is the application surface over Hypervisor Core for this lifecycle, including model garden and registry workflows, evaluation suites, datasets, endpoints, package promotion, and simulation-training environments such as robotics worlds, LiDAR and point-cloud corpora, Gaussian-splat scene representations, and sim-to-real validation lanes.

IOI is operationalized through separate but interoperable product domains. Hypervisor is the shared autonomous-work substrate. Hypervisor Core is the product/runtime substrate whose execution owner is the Hypervisor Daemon; Hypervisor App, Hypervisor Web, and CLI/headless are first-class clients over Core, with TUI as an optional terminal presentation. Hypervisor Workbench, Foundry, provider/environment views, sessions, missions, and approvals are application surfaces over the same Core, not separate runtime truths. Editor integrations, terminals, remote VMs, browser IDEs, local OS surfaces, and HypervisorOS nodes are adapter targets. External coding and agent systems such as Codex-style CLIs, Claude Code-style CLIs, DeepSeek-style harnesses, Aider/OpenHands-style tools, hosted coding agents, and CI agents are Agent Harness Adapters or HarnessProfile adapters. They submit proposed work through Hypervisor Core and daemon gates; they do not become Hypervisor clients, runtime truth, or Hypervisor’s identity.

Goal-shaped work in ioi.ai and Hypervisor Sessions is coordinated through two composable scales, not an unbounded swarm transcript. A durable GoalRun is the bounded orient, plan, act, observe, verify, repair, course-correct, and continue-or-close loop for one participant or subteam. Most ordinary work collapses to one GoalRun, Worker, model route, Automation, service, or Session. Persistent collective pursuit materializes an OutcomeRoom with a CollaborativeWorkGraph above one or more GoalRuns. The room owns the shared objective, participant leases, work frontier, claim leases, resource and capability offers, attempts, findings, verifier challenges, contribution lineage, admission policy, discussion projections, and replay; it is neither a peer runtime nor a globally mutable Agentgres graph. Cross-harness results use generic WorkResult and OutcomeDelta contracts; ImplementationResultPayload is the software profile for files, patches, diffs, and tests.

Hypervisor spans three deployment and control postures of one product. Type 1 is HypervisorOS, appliance, or cluster substrate control; Type 2 is Hypervisor Desktop / Workstation hosted on a normal OS; and Type 3 virtualizes autonomy across sessions, WorkRuns, workers, harnesses, model routes, tools, authority, receipts, replay, outcomes, and promotion. Type 3 is the differentiator, while Type 1 and Type 2 provide the governed substrate beneath it. The stable shell remains Home, Projects, Automations, Applications, and Sessions, with one optional Open Application slot. Specialized control surfaces live in the Applications catalog rather than expanding the permanent rail.

aiagent.xyz is the worker, capability, and managed-instance marketplace for publishing, benchmarking, ranking, installing, initializing, invoking, and routing workers. sas.xyz is the marketplace for autonomous service outcomes, including worker-training contracts and packaged service delivery. ServicePackages are not strictly worker-composed and do not depend on aiagent.xyz assets: they may execute deterministic pipelines or private local tools without using any marketplace-registered workers. ioi.ai is IOI’s first-party outcome conductor and Goal Space subscription product over Hypervisor. It owns goal intake, plan and status projections, contributor-scope and execution-policy selection, subscription and budget controls, collaborative-pursuit projections, synthesis, and account/device/restore metadata. Hypervisor executes; authority providers authorize; Agentgres domains retain operational truth; aiagent.xyz supplies and attributes Workers; and sas.xyz owns service procurement and delivery. A persistent OutcomeRoom appears as Goal Space in ioi.ai and Mission detail in Hypervisor without duplicating truth. IOI L1 is the public settlement, registry, rights, dispute, and governance root that anchors selected commitments from the local domains.

decentralized.exchange, decentralized.trade, and decentralized.cloud are candidate-intelligence engines for asset conversion, market exposure, and infrastructure capacity. They propose routes, venues, or resources; they do not become authority, custody, execution, provider-account, restore-truth, or settlement owners. wallet.network and applicable local/domain governance authorize; Hypervisor deploys or executes; venues and providers perform; Agentgres records admitted truth; IOI L1 settles only when a trigger requires it.

Hypervisor Node is a local settlement, orchestration, authority- integration, state, replay, routing, and interop domain centered on the headless Hypervisor Daemon, Agentgres, applicable authority-provider paths, local registries, receipts, and replay. It may host many sessions and governed autonomous-system chains. It mediates selected HarnessProfiles: the Default Harness Profile is IOI’s reference scaffold and fallback profile for loop-native scoped step resolution, not a peer runtime and not the only admissible harness. The node coordinates local inter-autonomous-system communications and submits effect proposals to local/domain policy and the applicable authority provider. wallet.network is required for portable delegated authority and designated high-risk external effects; the daemon admits and enforces the decision, and Agentgres records its receipts without consuming public L1 gas. When deployed bare-metal, the node operates under the HypervisorOS node profile.

Hypervisor Workbench is the code and systems application surface inside Hypervisor App and Hypervisor Web. It composes, replays, and supervises governed sessions while using editor, terminal, browser, VM, and agent-harness adapters as targets. It is not the runtime owner.

Hypervisor Automations is the durable workflow, trigger, schedule, API/service, approval-flow, queue-worker, and background mission surface over Hypervisor Core and the Workflow Compositor. It is where ad hoc work becomes reusable service shape, but it does not own execution semantics, wallet.network authority, Agentgres truth, receipts, or restore validity. ioi.ai is the Goal Space conductor that may ask, inspect, summarize, invoke existing work, draft a handoff, or project an OutcomeRoom when a durable shared frontier is useful. Contributor scope, execution/custody posture, placement, and routing policy remain separate controls. Durable automation/service deployment still moves into Hypervisor Automations, Foundry handles build/eval/training jobs when applicable, and execution must cross Hypervisor Daemon/Core contracts.

IOI Authority Gateway is the daemon sidecar and adapter profile for existing IDE, CLI, browser, hosted-agent, and MCP/tool ecosystems. It mediates available control points and maps third-party actions into Hypervisor proposals, gates, receipts, and observations. It is not a separate runtime and does not claim total interception of opaque tools.

Terminology alignment. Several protocol and product terms name different layers of the same authority stack. They should be read through the following owner map:

IOI Kernel / L0 means the reusable protocol substrate for domains, chains, modules, and settlement machinery; it is not the product execution owner for autonomous work.
Hypervisor Daemon owns execution semantics, gates effects, emits receipts, and admits consequential transitions through Agentgres.
Daemon Effect Boundary is a reference name for the daemon-owned deterministic effect boundary: action canonicalization, policy gates, sandboxing, approvals, normalized observations, and receipt emission.
Orchestrator should be read as a scheduling or planning role inside Hypervisor Core, the Workflow Compositor, or a selected HarnessProfile, not as a peer runtime authority.
Guardian is a profile or access-point role for policy, attestation, key share, approval, or declassification. It does not replace wallet.network as the authority layer.
IOI Authority Gateway names the adapter posture for mediated third-party tool integration. It is not a separate runtime, authority root, or total-control promise over opaque third-party tools.
Vault is a wallet.network product/security subcomponent for protected secrets and custody policy. It is not the application database, runtime truth layer, or storage backend.
User Node refers to the user’s Hypervisor Node or trusted local/client authority domain. Provider nodes and remote environments remain guests under daemon, wallet.network, Agentgres, and cTEE rules.

This edge-in topology places execution and cognitive sandboxing at the runtime edge inside the Hypervisor, while IOI L1 serves purely as the public registry, settlement, and dispute finality root.

aiagent.xyz supports two usage shapes. First, workers can be installed as composable capabilities inside Hypervisor, sas.xyz outcomes, enterprise runtimes, or MoW labor graphs. Second, workers can be initialized as managed instances bound to a user, organization, project, subscription, authority policy, runtime profile, and memory/archive policy. aiagent.xyz is not the engine that compiles or runs this code: the Hypervisor Daemon executes the worker, while aiagent.xyz lists, routes, licenses, and accounts for the instances. Managed instances may be invoked through web chat, API, Hypervisor, workflows, service outcomes, or router-selected MoW tasks. This makes aiagent.xyz both a supply marketplace and a direct intelligence access surface without making it the centralized execution runtime.

Hypervisor stabilizes, trains, and runs workers. aiagent.xyz publishes, initializes, and routes worker capability. sas.xyz sells verified service outcomes and productized delivery, whether the service is worker-composed, deterministic, private, or hybrid. ioi.ai is the first-party Goal Space outcome conductor; it coordinates goals, plans, participant scope, budgets, collaborative pursuit, synthesis, account/device state, restores, publishing, remote-runtime entitlement, and goal-appropriate Hypervisor handoffs without becoming execution, authority, truth, marketplace, or settlement owner. IOI L1 settles and governs selected public commitments.

The Hypervisor Daemon implements the runtime boundary. It isolates untrusted workload execution, translates tool requests into canonical ActionRequest objects, evaluates versioned PolicyEnvelopes, consumes applicable local/domain or wallet.network authority, and records outcomes in a hash-linked receipt chain. The same artifact semantics apply locally, in provider sessions, and in customer-boundary deployments. A future IOI L1 may receive selected settlement or dispute commitments. Execution happens at runtime edges and domain kernels; the L1 target is a sparse public settlement, registry, rights, reputation, dispute, and governance root rather than an execution dependency. The blockchain is not used as a global cognition engine; it is used for escrow, routing commitments, public identity commitments, sparse roots, and dispute resolution. A local or self-hosted operator must be able to complete governed work without public-chain coordination. The blockchain is never used to execute or store active cognition, private state, or daily workstation processes; selected commitments reach it only when a public or economic trigger applies.

IOI inverts the traditional blockchain topology. It does not begin by forcing all application state through global consensus. Work begins at the edge: local devices, hosted runtime nodes, customer VPCs, TEEs, DePIN nodes, and provider sessions. Domain kernels maintain operational truth through Agentgres. IOI L1 receives sparse public commitments only when the domain needs registry, rights, escrow, fee routing, dispute, governance, or settlement finality. This lets the intelligence economy scale across many independent providers without turning the L1 into a bottleneck for cognition or application state.

Agentgres supplies per-domain canonical operational truth: accepted operations, object heads, state roots, constraints, invariants, projections, subscriptions, receipts, quality/contribution ledgers, settlement mirrors, and sealed archive refs. ioi-memory indexes and retrieves private semantic memory, retrieval surfaces, references to execution traces, and task-scoped context slicing. Authoritative trace reconstructability is grounded in Agentgres operations, receipts, and artifact refs. While ioi-memory manages these retrieval surfaces, it is strictly isolated from authoritative state and does not replace or bypass Agentgres write mechanics. Sealed State Archives provide portable encrypted cold state, while Agentgres records what archive exists, what state it represents, the authority and policy refs governing restore, and which receipt makes restoration valid. Applicable authority providers decide who may restore it. Filecoin and CAS are storage backends, not peer authority components: the ArtifactRef and PayloadRef held in the Agentgres Artifact Plane determine which archives are valid. Domain Ontologies and Data Recipes supply ontology-bound domain truth for training, evaluation, projections, benchmarks, and worker/service composition. Together they replace the split between opaque SaaS databases and stateless AI tool wrappers with a portable state and semantic-data model for sovereign applications.

Portable memory follows the same ownership split. A MemorySpace is durable workspace/project/domain memory truth; a MemoryProjection is the scoped, policy-filtered view leased to a particular harness or model. Harness-local memory is cache. The human-readable ioi.hypervisor.memory-vault.v1 format exports and imports a MemorySpace without credential material, preserves stable refs and provenance, and reports conflicts rather than overwriting silently. Harnesses propose durable changes through a ContextMutationEnvelope review lane; approval applies the ordinary Agentgres admission gates and emits a context-mutation receipt.

Agentgres may expose Postgres-compatible projection/query surfaces for adoption, analytics, BI, admin tooling, and application reads. This bridge does not define Agentgres identity. Canonical writes still compile into Agentgres operations with schema, policy, authority, invariant, and receipt checks. This keeps familiar data access available without collapsing IOI back into a row-centric app stack.

IOI also requires a semantic data plane. Domain Ontologies define the entities, relationships, events, actions, states, roles, and invariants of a domain. Data Recipes map raw sources, documents, traces, and connector payloads into canonical objects, policy-bound data views, distilled training signal, evaluation datasets, and Agentgres projections. This is what turns worker training from “upload data and tune a model” into repeatable, auditable, comparable domain capability. It is also what lets the wider IOI economy pay, route, and evaluate data contributions without collapsing data into opaque platform custody.

The Ontology Development Kit (ODK) is the developer kit over Domain Ontologies, Canonical Object Models, Data Recipes, Connector Mappings, policy-bound views, ontology projections, workflow schemas, evals, and conformance. It scaffolds object-aware surfaces, domain apps, operator consoles, packages, and SDK bindings; it is not a runtime, truth store, authority layer, data warehouse, marketplace, settlement layer, or standalone Hypervisor application. Its object planes appear through Hypervisor Ontology, Data, Studio, Marketplace, and Developer Console.

The economic model is a market for verifiable work, governed by the rule that product surfaces monetize while substrate layers meter, prove, authorize, record, or settle only where they naturally carry value. The posture is Open substrate. Paid network: users may bring their model, cloud, tools, and authority, while IOI monetizes useful autonomous work, managed execution, distribution, governed trust, routing value, private posture, and value movement. The network moat is the Verified Work Graph—receipt-backed evidence of who did what, under which authority, with which worker/harness/model/tool/provider stack, at what cost and quality, and whether that evidence can improve routing, reputation, promotion, settlement, or disputes. Work Credits are the cross-product usage and budget abstraction, not necessarily a protocol token or final settlement asset. Ordinary Agentgres writes, local receipts, wallet authority checks, connector grants, and self-hosted work are bundled safety/truth substrate rather than independent toll booths. Arbitration is staged: cryptographic verification first, objective tests second, constrained semantic review third, and human escalation last.

The managed product has one commercial shape: ioi.ai sells a seat-like Goal Space subscription containing the persistent conductor, goal state, portable memory, policy, receipts, replay, collaboration, support, and a bounded grant of non-transferable Work Credits. Additional managed work uses top-ups, opt-in overage, or committed spend. Independent Network / Open participation uses a separate goal budget, bounty, procurement cap, or ServiceOrder; it does not silently consume the ordinary seat allowance. Named-user foundation-model subscriptions are not pooled production inference inventory. Lawful supply comes from direct or dedicated provider routes, negotiated agreements, customer BYOK/BYOA where permitted, replaceable aggregators, and open or self-hosted weights under explicit route-rights contracts.

The end-to-end architecture has seven supply legs: compute for execution, data for domain truth, models for cognition, evaluations for capability evidence, workers for bounded agency, workflows for composition and routing, and an economy for contracts, contribution accounting, payment, recourse, and settlement.

IOI does not claim to make neural inference deterministic, prove model wisdom, or put every local action on-chain. It claims that consequential action can be bounded by deterministic runtime controls and made economically legible through canonical receipts, explicit authority, and settlement-aware recourse.

For embodied or institutionally regulated work, two additional layers keep the same ownership split. Embodied Runtime represents robot/fleet identity, controller bindings, sensors, actuators, world state, command queues, telemetry, replay, recovery, and operator handoff; Physical Action Safety owns the independently enforceable safety envelope and actuator receipts. Ecosystem Assurance declares conformance, certification, jurisdiction, compliance, evidence, quarantine, liability-route, and commercial-export profiles. Assurance makes owner-domain evidence legible; it does not execute, authorize, store operational truth, adjudicate coverage, rank marketplaces, or settle disputes.

1. Web4 Thesis and Scope

Web4 extends the web primitive ladder from Read, Write, and Own to Act. Act is bounded machine authority: delegated software power that becomes canonical, authorized, policy-bound, attributable, revocable, and challengeable when it crosses a consequential boundary.

The Web4 thesis is therefore a machine-authority thesis. Read made information addressable. Write made publication interactive. Own made value programmable. Act makes delegated authority executable. IOI exists because an open network of intelligence can only become useful at economic scale if executable authority is alignment-secure at the boundary where intent becomes consequence. Its builder thesis is equally direct: IOI is the open, edge-sovereign operating fabric for governed autonomous systems. Hypervisor is its reference execution and control environment; federated Domain Ontologies are its semantic world plane; machine authority is its security protocol; Agentgres is its operational truth substrate; AIIP is its inter-domain work protocol; and IOI L1 settles only public or economic commitments requiring shared finality.

The scope is intentionally limited. A browser click, local inference step, draft, or file read need not become an on-chain transaction. The requirement is that any boundary touching ownership, credentials, durable state, third-party rights, escrow, or settlement must become transaction-shaped: canonicalized, authorized, policy-bound, receipt-backed, recovery-classified, challengeable, and eligible for the declared settlement path.

The stable unit of governance is the bounded act performed by a worker under an authority envelope, not the model response that proposed it. Model internals can change, model outputs can vary, and models can be swapped. The protocol-visible actor is the Worker: a bounded execution unit with identity, manifest, policies, capabilities, receipt obligations, and settlement posture. This worker-as-actor framing is what makes Mixture of Workers possible at runtime, and a MoW worker economy possible at network scale: routed labor graphs in which planners, executors, verifiers, tools, and services can be selected, paid, benchmarked, and disputed as accountable contributors.

The IOI architecture is local-first and fractal. Local execution preserves speed, privacy, and zero marginal network fees. Provider sessions add elastic capacity and specialized execution. IOI L1 handles escrow, public identity commitments, sparse commitments, and disputes. The invariant across those planes is not global execution; it is consistent artifact semantics at the consequential boundary. The same canonical ActionRequest, policy hash, approval chain, capability scope, and receipt obligations apply whether the workload runs on a personal device, a customer VPC, a hosted provider, a hardware-confidential runtime, a cTEE/private workspace, or the Cryptographic Operator Plane.

To facilitate seamless integration into existing developer, operator, and hosted-workflow environments, the Hypervisor local domain is organized as follows:

1. Hypervisor Node: The headless execution and local settlement domain. It hosts governed autonomous-system chains, manages local interop, processes local module invocations, and resolves local authority outcomes without consuming public L1 gas.

2. Hypervisor Core and clients: Core is the shared product/runtime substrate whose execution owner is the daemon. Hypervisor App, Hypervisor Web, and CLI/headless are first-class clients over Core; TUI is an optional terminal presentation.

3. Workbench, Foundry, and provider/environment views: Application surfaces over the same Core. Workbench handles code and systems work; Foundry handles worker/eval/training workflows; provider views manage sessions, environments, ports, services, logs, archive refs, restore refs, and infrastructure posture.

4. IOI Authority Gateway, adapter targets, and harness adapters: The compatibility profile for existing IDEs, browser surfaces, MCP tools, terminals, VMs, and local OS surfaces. External coding agents and terminal-first agent systems are modeled separately as Agent Harness Adapters. Both categories are mediated through Hypervisor proposals, gates, observations, and receipts rather than inheriting execution authority.

This is an edge-in topology. Authority-bearing work starts close to the user, project, provider, or compute venue; becomes canonical inside a domain kernel; and settles upward to IOI L1 only when a public trust commitment is required.

The reader should expect this paper to introduce the runtime architecture (Section 2), state and memory (Section 3), network/routing/work-graphs including MoW (Section 4), settlement and consensus (Section 5), cryptography and private-execution evidence (Section 6), identity and authority (Section 7), economics and arbitration (Section 8), security and evolution (Section 9), and protocol surfaces (Section 10). Schemas and examples — policy-envelope rules, effect-boundary artifacts, session artifacts, dispute schema — are collected in Appendix A. Other appendices cover canonical envelopes, the developer quickstart with connector manifest, claims and non-claims, fail-closed verdict logic, and references.

1.1 From Shared Gradients to Verifiable Labor

IOI differs from federated-learning and 6G visions of the Internet of Intelligence. Those architectures primarily optimize cooperative model training, gradient sharing, and distributed inference across edge devices. IOI instead uses the term for an open operating fabric in which bounded intelligences can discover shared work, negotiate meaning, receive scoped authority and resources, contribute across sovereign domains, preserve attribution and challenge rights, and carry permitted state away. Execution, authority, operational truth, and settlement remain distinct even when the user experiences one Goal Space.

The protocol does not require participants to reveal weights, training data, prompts, datasets, or proprietary reasoning traces. Intelligence may remain privately produced and privately owned. What becomes protocol-visible is the Worker: its manifest, authority scope, policy boundary, evaluation evidence, execution receipts, and contribution claims.

This shifts the organizing unit of the network from shared gradients to verifiable labor. IOI does not require cognition to become public. It requires consequential work to become accountable.

1.2 North-Star Internet-of-Intelligence Network Proof

IOI has demonstrated an Internet of Intelligence only when an independently operated external Worker can discover eligible work through a versioned, policy-bound OutcomeRoom discovery projection; negotiate semantic and action profiles; submit a typed participation request; receive bounded context, resource, capability, authority, and budget leases; claim work; return a verifiable contribution; preserve credit and dispute lineage; and exit with a portable permitted participant-state bundle. The proof must not require one runtime, operational database, administrator, or continued access to or trust in an IOI-hosted room.

Same-owner multi-model, multi-worker, or multi-node orchestration is valuable seed behavior, but it is not this network proof. Neither a large IOI-operated fleet nor a visually busy collaboration surface establishes federation by itself. The decisive property is an independently governed principal entering, contributing, being verified and attributed under declared terms, and leaving without surrendering sovereignty.

2. The IOI Runtime Architecture

IOI is defined by a fractal, edge-in operating fabric. Work begins near users, data, tools, providers, and physical systems. The Hypervisor Node is the local execution, orchestration, replay, interop, and settlement domain. Inside it, the Hypervisor Daemon owns execution semantics and gates consequential effects; wallet.network or the applicable local/domain governance path authorizes power; Agentgres admits operational truth. Federated Domain Ontologies make semantic objects and actions interoperable without creating a globally mutable database, and AIIP carries typed work and evidence between sovereign domains.

Rather than running as ad-hoc scripts, autonomous systems run as Governed Autonomous-System Chains. These are local, stateful admitted operation sequences containing policies, modules, proposals, and receipts, compiled and run strictly under the Hypervisor Daemon or daemon-mediated domain APIs. A selected HarnessProfile may be the Default Harness Profile, an imported agent harness, a Rust/WASM service module path, a connector/tool profile, a model mount, a verifier, or an AIIP handoff. Hypervisor Core coordinates the selection and session state; the daemon/domain gate owns consequential execution. The Hypervisor Node manages local interop and settles authority outcomes through Agentgres, anchoring selected roots to IOI L1 only when global registry, economics, reputation, or dispute resolution are required.

Autonomous System Package. Hypervisor’s primary developer artifact is the Autonomous System Package: the packageable object that binds worker responsibility, workflow or harness topology, model and tool capabilities, authority, memory/state/artifacts, evaluations, deployment profiles, and receipt expectations. It is not a raw workflow file, connector config, daemon process, or UI canvas. The canonical lifecycle is:

compose -> bind -> simulate -> authorize -> run -> verify -> inspect receipts -> package -> deploy -> promote -> improve

The Workflow Compositor shapes the high-level directed workflow/service graph and step contracts that may mature into an Autonomous System Package. Selected HarnessProfiles, service modules, model mounts, connectors, verifiers, and AIIP/capability exits resolve scoped steps under daemon gates.

This architecture serves as a governed improvement sandbox. Autonomous systems may inspect traces, identify failure modes, extract skills, and draft upgrade proposals, but they do not self-modify directly. Accepted changes enter the system only through daemon-mediated operations, Agentgres admission, policy gates, receipts, and, for high-assurance deployments, continuity proofs that bind the new generation to the same or narrower authority envelope.

This stack is designed to be fractally self-similar at its execution and domain boundaries: reusable contracts operate on user devices, provider Sessions, customer infrastructure, and sovereign domains. Those environments differ in capacity and trust profile, but share artifact semantics, canonical payloads, binding hashes, and evidence rules, so outcomes can move across Hypervisor Sessions, provider environments, MoW routes, and service-outcome contracts without reinterpretation. IOI L1 does not run the Hypervisor runtime or active cognition; it receives only selected roots and commitments whose rights, registry, reputation, economics, governance, or dispute semantics require shared finality.

2.1 The Protocol Core: The Four Pillars of Agency

To make probabilistic AI legally and economically enforceable — and to make Own executable as Act — the IOI runtime relies on four tightly coupled cryptographic contracts. These primitives ensure that intelligence is strictly bounded before any state mutation occurs, providing a clear roadmap for protocol engineers implementing the stack:

Pillar 1: Canonicalization. Every intent or tool call generated by an agent is intercepted and normalized into a mathematically stable JSON representation (RFC 8785) before hashing. This guarantees byte-level determinism across heterogeneous hardware.
Pillar 2: Policy Binding (policy_hash). The boundaries of agency are not heuristic. All rules, constraints, and scope definitions are normalized, deterministically ordered, and hashed. This policy_hash serves as the immutable law of the session.
Pillar 3: Pre-Effect Commitment: Before a side-effect touches the host system (network, filesystem, or GUI), the runtime binds the request hash, the policy hash, and any required user approvals (binding the exact request hash, scope, expiry, and revocation epoch) into the transaction-shaped evidence bundle for the act.
Pillar 4: Evidence and Settlement Binding. Applicable receipts bind the request, policy, authority decision, result, and evidence refs. When a declared trigger requires public or economic finality, a settlement profile may commit selected receipt or evidence roots to escrow, rights, dispute, or payout contracts. This makes the declared boundary auditable; it does not by itself prove legal liability or every real-world fact.

Design Doctrine: Process Safety over Model Safety

IOI accepts that global consensus is too slow for cognition and local execution is too unsafe for settlement. Furthermore, attempting to force bit-for-bit determinism onto the neural network inference layer fundamentally breaks the utility of modern AI.

IOI achieves verifiable agency by moving safety invariants out of the "black box" of the model and into explicit, checkable protocol surfaces at the execution boundary:

Canonicalization & Pinned IO: Makes the declared decision and evidence boundary auditable even when inference is stochastic. Each effect declares whether it is replayable, checkpointable, compensatable, reconciliation-required, or non-retryable; the protocol never infers real-world reversibility from a reproducible request.
Typed Intent, Steps, and Acceptance: Enforces hard constraints and strict type-matching before any model-based judgment is permitted to cross into shared reality.
Governed Remediation and Failure Routing: Acknowledges that agents will fail. A repair opens a new ActionProposal, gate, admitted effect, and receipt set rather than silently mutating or retrying the original effect.
Content-Addressed Evidence & Due Process: Narrows disputes by distinguishing receipts and committed evidence from observational events and analytics. Receipts prove only the fields, bindings, and verifier claims covered by their profile; events observe and analytics improve. Contractual, semantic, physical, and legal questions may still require declared verifiers, adjudication, or human review.

2.2 The Hypervisor Daemon & Multi-Plane Architecture

The Hypervisor Daemon is the universal execution endpoint and effect-semantics owner for canonical Web4 autonomous work. It is not the settlement ledger, not the raw L0 consensus engine, and not the client SDK; it is the host runtime that enforces the deterministic boundary. Fully managed runtime nodes initialize a compatible daemon runtime-node profile. Direct cloud, SSH, storage, connector, hosted harness, and other adapter lanes preserve their real semantics and mediate the control points they can observe; they do not claim total interception of an opaque third-party runtime.

Hypervisor Node Local Boundary:

– The Hypervisor Daemon manages local execution, containerization, and tool call intercept normalization.

– Hypervisor App, Hypervisor Web, and CLI/headless expose client lenses over the same Core. Workbench, Foundry, provider/environment views, approvals, receipts, logs, replay, and restore controls are projections over daemon and Agentgres truth.

– Agentgres maintains the local operational truth log (accepted actions, object states, projections, and receipt chains).

– wallet.network operates as the local authority plane, managing secrets, step-up prompts, and temporary cryptographic execution grants.

– Agent Wiki / ioi-memory handles semantic vector indexing and retrieval. Note that authoritative memory mutations are not written directly to memory blocks; they must be admitted into Agentgres via operation-backed commits.

Hypervisor Core exposes implementable session and adapter objects rather than hiding environment operations behind product screens. A HypervisorProject binds stable workspace identity, default policies, persistence defaults, adapter preferences, and Agentgres domain links. A HypervisorMission binds background, manual, scheduled, webhook, or event-triggered autonomous work to trigger policy, review contract, output contract, authority requirements, and receipts. A HypervisorSession is the live governed workspace, run, or control context.

AdapterConnectionProfile declares how a session connects to an editor, terminal, browser, VM, container, local OS surface, hosted worker, HypervisorOS node, or external harness. A HypervisorHarnessSelectionOption selects either a HarnessProfile or an AgentHarnessAdapter. External harnesses emit HarnessAdapterReceipt envelopes; containerized harness lanes are planned with HarnessContainerLanePlan and closed with HarnessContainerLaneReceipt. These objects let Codex-like, Claude-Code-like, Grok-Build-like, OpenHands-like, Aider-like, or DeepSeek-TUI-like harnesses propose work through daemon gates without becoming Hypervisor clients or runtime truth.

Managed environments use HypervisorEnvironmentClass, HypervisorEnvironmentOpsProfile, HypervisorEnvironmentLifecycleState, HypervisorEnvironmentActivitySignal, HypervisorEnvironmentService, HypervisorEnvironmentTask, HypervisorEnvironmentPort, and HypervisorScmAuthRequirement. Access to editors, SSH, browser previews, logs, support bundles, port shares, SCM actions, task exec, and environment operations is governed by a HypervisorSessionAccessLease; any SessionAccessToken is derived token material under that lease. PortExposurePolicy, BrowserOpenPolicy, and SupportBundlePolicy define what may be opened, proxied, shared, recorded, or exported. These are daemon/Core contracts and Agentgres projections, not UI-only controls.

This segregation prevents credential leakages, secures local file systems, and forces all worker behaviors to remain transaction-shaped.

The Hypervisor Daemon holds exclusive ownership over execution semantics, tool boundaries, effect admission, runtime state transitions, lease lifetimes, receipt generation, the emission and normalization of execution traces and trace refs, and state commitments to Agentgres (replay and reconstructability are grounded in Agentgres operations, receipts, and artifact refs). Rather than hosting an independent, parallel runtime engine, the daemon mediates HarnessProfiles. The Default Harness Profile is the IOI reference scaffold and fallback for loop-native scoped step resolution. It is useful for custom service steps, single-worker loops, and local development, but it is not a global meta-harness and not the owner of high-level workflow composition. Third-party agent harnesses, service modules, model mounts, verifiers, AIIP peers, and Rust/WASM workload paths participate through common boundary objects, adapter conformance, and daemon gates.

Rust/WASM step-module backend. IOI’s target execution shape routes consequential daemon steps through the Rust/WASM workload/kernel substrate as the authoritative step/module execution backend under the daemon. A serious step should materialize as a StepModuleInvocation with authority refs, context refs, artifact refs, state-root expectations, and receipt obligations, and close as a StepModuleResult or normalized observation admitted through Agentgres. This substrate is not a peer runtime beside Hypervisor; it is the canonical backend behind daemon-mediated execution.

Product clients and adapter surfaces may enter through daemon routes for HTTP clients, UI state, local adapter coordination, and existing Hypervisor surfaces. Canonicality is determined by typed envelopes, authority checks, receipts, state roots, and Agentgres admission rather than by the client implementation. The canonical execution sequence is: ActionProposal to GateResult to StepModuleInvocation through a typed daemon-core API or Rust/WASM workload client, then StepModuleResult, NormalizedObservation, receipt refs, state-root updates, and Agentgres admission. Implementations may use different transports only when they preserve these protocol envelopes and evidence obligations.

Execution is strictly bifurcated between two cooperating layers:

– The Probabilistic Cognitive Plane (Model Loop) interprets context, plans actions, adapts to exceptions, requests semantic evidence, handles domain ambiguity, and proposes state deltas.

– The Deterministic Safety Plane (Hypervisor Daemon) enforces hard limits, validates inputs, records execution traces, manages credential scopes, schedules execution segments, emits cryptographic receipts, and commits admitted state transitions to Agentgres.

The Loop-Native Execution Cycle. Every governed autonomous task uses loop-native semantics where adaptation is needed: model or harness pass, action proposal, policy/authority gate, execution, result normalization, receipt and Agentgres update, and model or harness re-entry. Higher-level directed workflow/service shape belongs to the Workflow Compositor; lower-level step resolution belongs to the selected HarnessProfile or module path. All consequential transitions must cross the determinism boundary through normalized IO interfaces. Consequential steps are executed as typed Service Module Invocations, direct daemon tools, model/inference mount calls, cTEE/private workspace actions, verifiers, or AIIP/capability exits, and the daemon writes governed transitions and local settlement records through Agentgres-compatible APIs without writing directly to IOI L1.

The loop continues iteratively until the task achieves resolution, at which point the final cognitive output must undergo an explicit Output Ownership Pass. This pass verifies that the final delivery is fully accounted for by cryptographic evidence, local observations, receipts, and valid Agentgres artifact references before the task can be marked complete and authorized for L1 settlement or local master integration.

Canonical loop (determinism boundary shown):

Product domains are not runtime nodes by default. A web app, marketplace, or product surface may create runtime assignments, request daemon-compatible execution, or project runtime state, but workers execute inside local, hosted, decentralized, enterprise, TEE, or customer-boundary runtime profiles.

A managed worker instance does not make aiagent.xyz the execution runtime. aiagent.xyz resolves the worker package, install/license rights, runtime profile, authority requirements, subscription policy, and memory/archive policy. Execution occurs on a daemon-compatible runtime node: local machine, hosted provider, DePIN node, TEE, GPU job, browser sandbox, customer VPC, or enterprise/private runtime.

Every execution node that performs IOI work runs, embeds, or speaks to a daemon-compatible runtime profile. The Daemon decouples logical isolation from physical hardware via a Multi-Plane Scaling Architecture. The invariant is: regardless of deployment target, every admitted path must preserve the declared authority, policy, envelope, receipt, and Agentgres boundaries. Physical isolation, provider semantics, capacity, privacy, attestation, and adapter control points vary and must not be flattened into identical security claims.

Deployment examples: locally (Hypervisor), the planes may collapse into a user-space virtualization layer over the host OS. On managed IOI or partner provider infrastructure, they may scale horizontally across four distinct planes, engaging public settlement only when an explicit trigger requires it:

Plane A: The Edge / Admission Plane

Role: The stateless API and routing layer.
Responsibilities: Handles initial authentication, rate limiting, request normalization, routing, and session admission. It acts as the programmatic ingress for hosted ioi.ai queries and third-party dApps.

Plane B: The Inference Plane

Role: The cognitive engine.
Responsibilities: Horizontally scaled by model pool and queue depth. It handles fast reasoning, embeddings, and rerankers. It utilizes warm capacity (Provider OSS or proprietary models) to eliminate cold starts for standard queries, while safely routing Bring-Your-Own-Key (BYOK) requests, where wallet.network brokers BYOK keys and never exposes them to raw workflows.

Plane C: The Guest Workload Plane

Role: The isolated environment where a model-backed worker, external harness, script, service module, or third-party binary attempts tool use. It is mediated away from provider-visible secrets, host authority, and the user’s primary state by daemon policy, wallet.network leases, and Agentgres receipts.
Responsibilities: Horizontally scalable worker nodes that execute workflow steps, tool calls, browser/runtime jobs, and generate raw artifacts.
Isolation: Runs through declared execution lanes such as containers, namespaces, microVMs, WASM workloads, local tools, remote managed bridges, provider sessions, or cTEE/private-workspace paths. It boots in a zero-trust state. API calls cross daemon-governed mediation points such as adapter bridges, capability proxies, MCP gateways, or wallet.network leases, each enforcing the active authority envelope before effects are admitted.

Plane D: Hypervisor Daemon / Coordinator Plane (The Effect Boundary)

Role: The bounded, capacity-governed execution-control role. This is the always-on daemon boundary that holds run state, policy bundles, tenant configurations, and cryptographic receipts while requesting decisions from local/domain policy and the applicable authority provider. wallet.network supplies portable delegated and designated high-risk authority paths; it is not required for every local act.
Runtime Node Modes: Execution venues that run Hypervisor daemon profiles.
- Hosted IOI Runtime: Hosted by the provider or provider-managed infrastructure for fast, consumer-facing tasks.
- Customer VPC Runtime: Deployed directly inside a customer's VPC or on-prem environment, allowing sas.xyz to orchestrate tasks without exfiltrating enterprise data.
- Local Hypervisor: Embedded inside Hypervisor on the user's personal device.
- IOI Authority Gateway (Sidecar Profile): Run locally or within customer boundaries to act as an external execution and policy boundary. Rather than serving as the primary interface, it runs as a background process ("sidecar") to intercept and normalize action requests from third-party cognitive environments, obtain the applicable policy and authority decision, and admit, deny, or mediate the resulting effect.
- Customer Boundary Runtime: Deployed inside a customer VPC or on-prem environment so orchestration can occur without exfiltrating enterprise data.
- Hardware-Attested Confidential Runtime: A TEE-backed runtime that may provide hardware attestation and memory-confidential execution under a vendor-specific threat model. Standard confidential VMs do not guarantee absolute protection against a compromised physical host. Vendor attestation, measured-boot evidence, cTEE, customer custody, and cryptographic operators provide different, non-interchangeable claims under their declared threat models. A TEE is one admissible private-execution substrate among several.
- Cryptographic Operator Runtime: A proof-carrying runtime that uses FHE, MPC, ZK proofs, verifiable computation, or a hybrid construction to produce externally verifiable evidence without treating hardware attestation as the root of validity.
wallet.network guardian/access-point profile: Operating within Hypervisor Core or the wallet.network authority path, a guardian/access-point profile may hold key shares, device attestations, approval state, or protected signing authority for a runtime. It does not by itself define protocol validity. Its signatures are accepted only when bound to canonical requests, policy hashes, monotonic sequence state, receipt obligations, wallet.network authority refs, and the applicable verifier requirements. Such a profile may integrate a minimal receipt sequencer (remote, local, or enclave-bound depending on the threat model) that maintains a persistent, monotonic counter (seq) on disk to enforce an append-only, non-equivocating receipt chain.


Safety Invariant: ** Because the receipt sequencer enforces monotonic sequence advancement on disk, equivocation becomes detectable under the declared storage and runtime threat model. A compromised host or execution worker cannot produce valid higher-tier evidence unless it also satisfies the receipt-chain, verifier, and challenge requirements for that action class.

2.2.1 Plane-Enforced Isolation

For daemon-controlled workloads and capabilities, Plane C (where cognition and guest work occur) is separated from Plane D (where the daemon evaluates policy, requests applicable authority, and commits receipted state). Managed I/O crosses the daemon effect boundary. Adapter profiles mediate only their declared control points, so containment and interception claims must name the actual substrate. When a brokered secret is required, wallet.network or an approved authority client performs the capability or issues an operation- scoped lease without exposing ambient secret material to the worker.

2.2.2 Deterministic IO and Pinned Externalities

Pinned I/O is a versioned runtime-profile property, not a claim that IOI eliminates all nondeterminism or intercepts every opaque external process. A profile declares which externalities it mediates, how it binds them, and which claims its receipts support:

Sequencing and time: Replay-critical policy and authority checks use the sequence, expiry, revocation epoch, monotonic source, or trusted time source declared by their owner contract. Wall-clock observations may support UX and telemetry but do not become settlement truth merely by being logged.
Network and tools: A mediated call resolves through a RuntimeToolContract or surface MCP contract. The request, authority/policy decision, response commitment, artifacts, and normalized observation are covered by the applicable receipt profile.
Randomness: Any random selection relied upon for eligibility, challenge, routing, or settlement declares its source, bias assumptions, commitment/reveal or verifier method, and replay semantics. No universal VRF construction is fixed in this synthesis.
UI and physical context: A computer-use adapter may require application/window/DOM/visual target bindings and refuse a mismatch before action. The exact focus, freshness, and observation checks belong to the adapter contract; an unobserved UI surface is not claimed to be contained.

The invariant is coverage honesty: consequential effects crossing a declared daemon or adapter boundary are canonicalized, gated, and receipted according to that profile. Nondeterministic cognition, wall time, provider behavior, and unmediated external state remain outside the proof unless a named evidence source and verifier cover them. The “Run Anywhere” Property

IOI’s portability is achieved by separating kernel semantics from workload packaging.

The Hypervisor Daemon and the underlying workload/kernel substrate provide the execution invariant: they define how policies bind, how receipts are formed, and how attestations are produced.

Workloads are packaged as Universal Protocol Artifacts (e.g., OCI images or equivalent bundles), allowing a workflow built locally on a laptop to run on a cloud provider or committee node without changing its portable contract. Transportability does not preserve every trust claim: each environment declares its evidence and verifier profile, and receipts advance only through the exact assurance ladder attested, evidenced, verified, accepted, adjudicated, and settled. A provider attestation, bond, certificate, or public commitment may add evidence or recourse, but none silently upgrades a receipt to a later stage.

2.2.3 The Sidecar Deployment Profile (IOI Authority Gateway)

When running in sidecar compatibility mode, the IOI Authority Gateway profile lets the Hypervisor Daemon operate as a deterministic, policy-enforcing boundary for external, unaligned processes. In this profile, the daemon does not own the external harness’s cognitive loop (the "thinking"). Instead, it mediates available control points and maps proposed effects into Hypervisor proposals, gates, observations, and receipts at host operating system, tool, and network boundaries.

This architecture implements the core thesis: Models reason; local/domain policy and the applicable authority provider authorize power; the Hypervisor Daemon admits, enforces, and executes action. wallet.network is the portable delegated and designated high-risk authority profile, not the source of every local decision.

A. Control Points and Interception Boundaries

Because external agent harnesses and editor/CLI/browser environments (such as Cursor, Claude Code, Codex, OpenHands, Aider, DeepSeek-style TUI harnesses, or proprietary hosted agents) expose only partial control points, the Authority Gateway mediates the boundaries it can actually observe through six deterministic control surfaces:

1. Shell Commands: The gateway intercepts terminal executions, verifying package installations, file deletions, network sockets, process spawns, and deployment commands against the active daemon policy bundle.

2. File System Watcher: Monitors workspace diffs and git configuration files. The gateway blocks unauthorized writes to protected system directories or sensitive file extensions.

3. Git Hook Mediation: Enforces policies on branches, force-pushes, and commit signing, automatically binding signed commit hashes to corresponding execution receipts.

4. Secret Isolation (wallet.network): API keys and deployment credentials remain within wallet.network vault custody. The gateway injects temporary, operation-scoped credential leases at the network edge, ensuring the raw secret material is never exposed to the agent's context window.

5. Hypervisor MCP Gateway: Exposes only the tools, surfaces, sessions, automations, Foundry actions, and receipt/replay views selected by an expiring or revocable gateway profile. Each call resolves to a declared RuntimeToolContract, surface MCP contract, or operator-plane contract, then crosses daemon admission and the applicable wallet.network authority path before Agentgres records the result. A gateway profile is not a master key, direct provider-credential broker, host-mutation bypass, or peer runtime.

6. Context-Aware Approvals: Requests a wallet.network step-up approval gate when an external agent attempts an action exceeding autonomous limits (e.g., spending capital, modifying production environments).

2.2.4 Goal Kernel, Outcome Rooms, and Typed Harness Brokerage

The Goal Kernel is the goal-shaped orchestration kernel used by ioi.ai and Hypervisor Sessions. It turns normalized intent into a durable GoalRun, executes a GoalGroundingLoop, selects a RoleTopology, leases only the context and authority each role needs, invokes compatible harnesses or workers, verifies results, and reconciles receipts, memory proposals, skills, and continuation state. It is not a super-agent, a swarm-control interface, or a runtime beside the daemon.

The Goal Kernel operates at the bounded-run scale. Persistent collective pursuit sits one level above it in an OutcomeRoom. An OutcomeRoom binds a durable objective to a CollaborativeWorkGraph: a governed frontier of questions, hypotheses, tasks, review needs, verification needs, resource needs, claims, attempts, findings, verifier challenges, admitted outcome deltas, contribution lineage, budget, and replay. One room may contain one or more GoalRuns, and a GoalRun may stand alone. Direct questions, one-shot runs, ordinary automations, and single sessions do not acquire room machinery merely because the substrate supports it.

Every persistent OutcomeRoom declares one shared-state ordering and admission topology. Under hosted_admission, one named governed domain orders and admits room-level frontier, attempt, finding, evaluation, and decision updates. Under federated_admission, a versioned policy names the participating domains, ordering or merge rules, quorum or adjudicator requirements, conflict behavior, failover, recovery, and policy-version transitions. Both modes preserve each party’s local operational truth and private context. A board, chat, inbox, digest, leaderboard, or replay is a projection over admitted objects, never a universal mutable database or authority source.

Each independent role works in a ContextCell. A ContextLease bounds files, documentation, memory projections, tools, connectors, budget, receipts, and authority. A typed ContextHandoff moves a task brief, bounded result, finding, blocker, test result, review request, verification result, resource request, decision request, or continuation summary between cells. This preserves long-horizon intent while preventing every actor from receiving a global context dump.

The harness broker boundary is:

TaskBriefPayload $\rightarrow$ HarnessInvocation $\rightarrow$ HarnessAdapterEvent $\rightarrow$ WorkResult / OutcomeDelta $\rightarrow$ VerifierPath.

WorkResult is the generic result seam for software, research, ontology mutation, incident response, service delivery, physical missions, review, evaluation, and custom work. ImplementationResultPayload is only the software-implementation profile carrying changed-file, diff, test, and implementation-summary fields. OutcomeDelta proposes an admitted change to a frontier item, finding, ontology, state, capability, policy, routing prior, or service outcome; producing a result never grants that change admission by itself.

Open or cross-domain participation uses typed room contracts rather than raw membership. OutcomeRoomDiscovery exposes a signed public or permissioned objective and declared semantic, capability, eligibility, privacy, budget, verifier, settlement, and contribution posture without private room state. RoomParticipationRequest requests admission; acceptance creates a bounded RoomParticipantLease. Resource and capability offers, frontier items, work-claim leases, attempts, findings, and verifier challenges remain proposals until the declared room admission path accepts them. Retirement, expiry, quarantine, or revocation releases live claims and may export a signed, policy-filtered ParticipantStateBundle; it ends future access without erasing permitted contribution, receipt, acceptance, settlement, or dispute lineage.

A HarnessProfile or Agent Harness Adapter may translate that contract into provider-specific prompts, commands, RPC calls, or hosted-agent sessions, but those renderings stay adapter-private. Durable coordination uses the typed objects, receipts, artifacts, and Agentgres refs. Raw chat is never the portable handoff or completion contract.

AIIP carries signed, sequenced, idempotent room updates and permitted refs between sovereign domains. It does not execute attempts, own the CollaborativeWorkGraph, or turn participant consensus into truth. Participant input remains tainted until policy, isolation, verification, and the named host or federation admission policy accept it. Multiple models, workers, runtime nodes, providers, or keys controlled by one principal remain one party when that principal controls authority, truth, verification, risk, or settlement.

The daemon-owned Agent Operating Plane admits configured agents, sessions, work queues, work items, WorkRuns, turn coordination, delegation, conversation projections, usage, and execution/security telemetry. The Hypervisor Operator Plane uses the same agent, model, HarnessProfile, tool/MCP, authority, and receipt contracts to operate Hypervisor itself; it is neither an ambient host administrator nor a privileged child-session harness.

2.3 The Anatomy of a Worker

The IOI runtime decomposes agency into composable primitives rather than treating each agent as a monolithic container. This decomposition serves three purposes: deterministic execution boundaries, portability across deployment targets, and intellectual property isolation between participants.

The Worker Ontology

The IOI runtime decomposes agency into four distinct primitives:

Worker: The core execution unit. Each worker has a defined role, a policy scope, a computational budget, and a capability set (defined by a canonical WorkerManifest). Workers are actors, they do things.
Model: The cognitive backend. Models are cognitive backends, not peers to workers. The node owns the model routing and invocation boundaries. Model weights, local model files, local model servers, and provider endpoints are mounted by a Model Deployment Profile, and are not part of the Hypervisor Node binary by default. The Model Deployment Profile MUST enforce the ModelWeightCustodyProfile (see §2.3.1) to prevent accidental plaintext leakage of proprietary weights to hostile-root compute operators.
Capability: Capabilities are what workers use. This surface groups four pillars: 1. Connections (authenticated reach to external systems), 2. Computer Use (direct digital action, browser, desktop, terminal), 3. Skills (reusable, named operating patterns), and 4. Extensions (installable packages that grant new capabilities).
Extension: An installable package that grants new capabilities to a worker, extending its capability surface without modifying its core policy or identity.

Model Routing vs. Worker Routing

IOI distinguishes model routing from worker routing.

Model routing selects an eligible cognition backend under quality, privacy, authority, latency, context, commercial-rights, and cost constraints. The route may use a direct provider API, managed or dedicated endpoint, negotiated inference agreement, customer BYOK/BYOA, a replaceable aggregator such as OpenRouter, or open/self-hosted weights.

Worker routing selects an accountable actor: a bounded worker with a manifest, policy envelope, tools, runtime requirements, receipt obligations, license terms, and settlement identity.

The canonical model-router API uses explicit runtime objects rather than hardcoded provider names. A ModelEndpoint declares the provider or local server, mount mode, deployment profile, model artifact ref, auth mode, key ref, privacy class, supported model roles, architecture profile, active-context strategy, and run-to-idle behavior. A ModelRoute maps a role such as planner, executor, verifier, summarizer, code, vision, embedding, or rerank to candidate endpoints under cost, privacy, context, latency, route-rights, and fallback policy. A ModelInvocation is the receiptable runtime act that invokes a route with a task context, prim:model.invoke, a scope:model.invoke.* authority scope, an authority grant, and a receipt mode. ModelDeploymentProfile binds whether a route uses bundled weights, local files, local servers, external APIs, dedicated managed capacity, aggregator adapters, TEE sessions, DePIN sessions, or customer VPCs.

Every unattended or customer-facing route resolves a versioned ModelRouteRightsContract. It binds provider and model terms, contract hash and validity window, endpoint and model version, access mode, commercial posture, customer-facing and downstream rights, automation and OEM/reseller authorization, credential principal, provider allowlist, data collection, retention, region, price, required parameters, fallback classes, and output-training right. Missing or expired rights fail closed. A fallback that changes provider, model, Worker, privacy posture, or commercial posture is a material semantic substitution: it remains inside the declared constraint envelope, emits routing evidence, and re-runs applicable verification and acceptance.

The lawful supply portfolio is intentionally plural:

open or self-hosted weights where license, custody, quality, and operations permit;
direct provider APIs and managed endpoints for core routes and feature fidelity;
dedicated capacity or negotiated inference agreements for volume, service level, retention, residency, and data posture;
explicit OEM or reseller authorization when IOI exposes near-raw provider capability;
customer BYOK or BYOA for customer-owned cost and approved interactive harnesses; and
replaceable aggregators such as OpenRouter for bootstrap breadth, long-tail models, price and availability discovery, policy-qualified fallback, overflow, and experimentation.

Named-user ChatGPT, Claude, or comparable chat/workspace subscriptions are not production inference inventory. They may serve internal human operators or an expressly provider-approved, user-scoped interactive BYOA harness, but IOI must not pool, share, browser-automate, or resell their limits as autonomous-worker capacity. An aggregator likewise does not erase underlying provider terms, privacy posture, semantic differences, or commercial rights, and use of an aggregator is not presumed to authorize resale of near-raw model or API access. Inference permission does not imply training, distillation, downstream resale, or OEM permission.

The execution-policy grammar is orthogonal to subscription plans: Auto / 1-of-N selects the least-cost eligible route expected to satisfy declared constraints and may run a verified cheap-first cascade; Pinned uses the selected eligible route and fails closed unless a qualified fallback was explicitly authorized; and Compare / N-of-N runs declared attempts, preserves each admitted result, and applies a named comparison, verifier, or synthesis rule.

BYOK provider keys belong in wallet.network. Runtimes receive brokered authority grants or short-lived operation-scoped tokens, never raw long-lived provider keys by default. Run-to-idle model serving is a lifecycle primitive—cold -> warming -> ready -> busy -> draining -> idle -> sleeping—so local, hosted, DePIN, or customer-cloud model routes can scale down without becoming invisible to policy, receipts, or restore.

Mixture of Experts (MoE) is model routing. Federated Learning (FL) is cooperative training. Mixture of Workers (MoW) is accountable labor routing.

Mixture of Workers (MoW) is how autonomous labor is routed and executed. The MoW worker economy is how autonomous labor is discovered, priced, governed, and settled.

A Worker may internally use a dense model, an MoE model, a fine-tuned local model, a tool-augmented model, a rules engine, a human approval path, or a specialist trained, configured, or evaluated through synthetic-data workflows. The protocol does not privilege the internal substrate. It binds accountability to the Worker identity, manifest, policy envelope, authority chain, evaluation receipts, contribution receipts, and settlement surface. This preserves intellectual property while ensuring that benchmarks, disputes, and royalties attach to the verifiable actor rather than the opaque cognitive engine.

Node Packaging Principle

The Hypervisor Node contains model routing and invocation contracts; the model itself is a mounted cognition backend unless a deployment profile explicitly declares bundled weights. Bundled weights are allowed only when declared by specific offline or local-only deployment profiles and are not the architecture default. Service modules and workers invoke models strictly through route aliases, never via direct file assumptions or hardcoded provider names.

Instead, a "Worker" is decomposed into distinct, composable primitives. This structure aligns with the Model Context Protocol (MCP) while enforcing Hypervisor Daemon and IOI L0 security invariants. It rigorously enforces the separation of Logic (Routing), Cognition (Thinking), and Execution (Acting).

1. The Agent Core (Logic, Cognition & Context)

To reduce unnecessary exposure of developer IP while maintaining zero-idle infrastructure, the agent’s protected workspace intelligence is never packaged as a single heavy asset. It is strictly decoupled into three sub-components defined in the Worker Manifest:

The Logic Binary (WASM): The state machine, prompt templates, tool wiring, and ReactFlow node configurations are compiled into a lightweight WebAssembly (WASM) binary (typically <5MB).
Distribution Boundary (WASM is not secrecy): Compiling to WASM makes worker logic portable, typed, hashable, fuel-bounded, and easier to execute under daemon policy. It may slow casual inspection, but it is not a confidentiality primitive and must not be marketed as protection against determined reverse-engineering. Developer IP protection comes from not packaging private context, secrets, private retrieval state, proprietary weights, or authority as provider-readable plaintext, and from binding package use to manifests, policy, receipts, contribution accounting, and the selected execution/privacy posture.
The Cognition Engine (Models & Weights): Logic binaries do not contain model weights; they declare cognition dependencies. Public foundational models may be fetched from public registries or caches. Proprietary models and private retrieval substrates are encrypted at rest and hydrated only under the action’s declared private-execution evidence profile. Encryption-at-rest and a standard cTEE workspace wrap do not by themselves protect plaintext proprietary weights on a rented, hostile-root node: when both workspace privacy and proprietary weight secrecy are required on the same rented node, the execution path MUST pair cTEE with hardware confidential compute, or use the Cryptographic Operator path. Depending on the workload, the profile may require TEE attestation, FHE-backed private evaluation, MPC execution, ZK-proven model computation, deterministic replay evidence, or hybrid evidence. TEEs are admissible where ordinary software compatibility and performance matter. FHE/MPC/ZK-based execution is preferred where the action class requires stronger external verifiability or reduced dependence on hardware attestation roots. In all cases, the model or program hash, input commitments, output commitments, policy hash, leakage bounds, and verifier requirements are bound into the applicable CustodyProof, proof refs, and receipt bundle. This reduces exposure under the declared substrate threat model and makes any authority-critical claim dependent on receipt completeness, not on trust in the execution venue.
The Sovereign Context (The Data Moat): For complex agents relying on public open-weights, the developer's true IP is often their proprietary data. The agent's knowledge base (e.g., 50,000 proprietary trading algorithms) is represented as encrypted semantic indexes and private memory refs in Agent Wiki / ioi-memory, with durable mutations, policy refs, provenance, and artifact refs admitted through Agentgres. Even if the WASM logic is decompiled, without the decryption key, wallet.network authority, and authorized access to those memory projections and Agentgres-governed refs, the remote worker lacks the protected context that gives the workspace its operational advantage.

2. Tools (The Cognitive Interface / Intent)

Analogy: OpenAI Function Definitions, MCP Resources & Prompts.
Definition: The intent schema exposed to the Foundational Model or Cognition Engine.
Role: Allows the model to request an action.


Invariant: ** A Tool Call is a request, not an execution grant. When a model selects a Tool, it generates a ActionRequest (derived from the MCP CallToolRequest standard). This request is treated as untrusted input and MUST be validated by the daemon effect boundary before any side effect occurs.

3. Drivers (The Execution Layer / MCP Servers)

Analogy: Model Context Protocol (MCP) Servers, Hardware Drivers.
Definition: The binary or process that performs the I/O.
Architecture:
- Software Drivers (MCP Wrappers): Standard MCP servers (e.g., stripe-mcp, filesystem-mcp) wrapped by the Hypervisor Daemon and bound by explicit RuntimeToolContract schemas defining primitive capabilities and risk classes. The wrapper handles credential injection and policy enforcement transparently.
- Native Drivers (Hypervisor Daemon): Native code holding OS handles (e.g., Enigo for mouse control, xcap for screen capture). These provide the low-latency "Atomic Vision-Action Lock" required for GUI agents, which standard MCP over JSON-RPC cannot guarantee.
Role: Executes the authorized I/O. Drivers do not "think"; they obey the daemon.


Invariant: ** Drivers are Air-Gapped from the Model. They never receive raw tokens or persistent API keys. They only receive policy-validated, canonical payloads from the Hypervisor Daemon, injected with ephemeral credentials for the duration of a single operation.

2.3.1 Model Weight Custody and Routing Boundaries

To protect both developer IP and user privacy, the Hypervisor enforces a strict separation between Private Workspace Protection (governed by the cTEE) and Proprietary Model-Weight Protection (governed by the Model Weight Custody Policy).

While the target cTEE posture is designed to keep a user’s protected workspace outside remote-host plaintext custody, it does not automatically protect proprietary model weights. If a developer loads unencrypted, proprietary weights directly into the memory (CPU/GPU) of a rented remote node, a hostile host-root operator can copy those weights, snapshot the disk, or inspect process memory.

To mitigate this risk, the Hypervisor requires that all worker configurations declare their model access path in compliance with the ModelWeightCustodyProfile. In current model-router API terms this is materialized as a ModelWeightCustodyProfile on the deployment route. The profile is separate from ExecutionPrivacyPosture: one answers what happens to the weights; the other answers what happens to the user’s workspace data.

ModelWeightCustodyProfile lanes.


Lane	Weight custody claim	Valid use	Boundary
public_open_weight	Weights are public or intentionally shareable.	Rented GPUs, DePIN nodes, local machines, hosted pools.	Workspace privacy still depends on cTEE, redaction, local custody, or another execution privacy posture.
user_local_private_weight	Weights remain on user-owned or customer-controlled machines.	Local/private model serving, user-owned GPUs, enterprise clusters.	Strong weight custody when the user’s own authority domain controls the node.
remote_api_private_weight	Provider keeps proprietary weights behind an API; the user and rented compute node never mount them.	Foundation-model APIs and managed private model services.	Protects provider weights, but private user inputs cross a provider-trust boundary unless redacted or declassified.
provider_trust_remote_mount	User/org proprietary weights are mounted on provider-visible infrastructure under contract or accepted trust.	Explicit provider-trust deployments only.	Must not be labeled private-native; requires disclosure, policy, and receipt.
tee_or_customer_cloud_mount	Proprietary weights mount only inside an accepted hardware-confidential, customer-cloud, or customer-controlled boundary.	Confidential GPU lanes, customer VPCs, enterprise-controlled accounts.	Valid when attestation or customer control satisfies policy; not a generic consumer-GPU claim.
forbidden_plaintext_mount	Requested mount would expose non-public weights to an untrusted root provider.	Invalid route.	Must be blocked unless policy changes to local/customer/API/TEE posture or the owner explicitly accepts provider trust.

Public trunk plus private head is a composition pattern, not a separate custody lane. The rented GPU may run public/open trunk weights while the private head, scoring function, retrieval policy, or selection logic remains local, wallet/guardian-bound, threshold-protected, or cryptographic-operator-bound. This is the model-weight analogue of Candidate-Lattice Private Decoding: keep high-throughput public kernels on cheap compute while protected selection state stays outside provider plaintext custody.

2.4 The Determinism Boundary (Invariant)

As established in Section 1, IOI does not make AI deterministic. It makes agentic state transitions deterministic by enforcing the following invariants at the execution boundary.

The Determinism Boundary is the alignment-security boundary. It does not make inference deterministic. It determines when a proposed act has enough canonical input, authority, policy binding, evidence, and settlement context to become a consequential effect.

Implementation note: the current conformance docs do not treat “Determinism Boundary” as a separate runtime or contract family. They realize it through CIRC semantic collapse, CEC admitted-effect collapse, daemon gates, wallet.network authority, Agentgres admission, and HarnessProfile adapter contracts.

The Determinism Boundary decouples Cognition from Sanction and extends Own into Act. Models run on any hardware, embracing hardware-induced drift. Strict mathematical determinism is enforced only at the daemon effect boundary using integer-bound computation.

Upstream (fuzzy): Models may be stochastic, creative, and adaptive.

The Boundary: Before any output can affect shared state (payments, votes, property, credentials, durable records, irreversible actions, or settlement), it must pass through a strict, normative invariant set. This is the consequential boundary of Web4 Act.

Downstream (rigid): The resulting artifact (Receipt → Commitment → Certificate/Resolution) is immutable, machine-verifiable, and enforceable.

The Determinism Boundary Invariant Set (DBIS)

To ensure skeptics, auditors, and protocol engineers can mathematically verify the execution boundary, the Hypervisor Daemon enforces the following normative invariants:


DBIS-1: Canonicalize-before-hash/sign (MUST, Fail-Closed):All ActionRequest objects and any commitment material MUST be canonicalized via RFC 8785 (JSON Canonicalization Scheme) prior to hashing (e.g., try_hash()) or signing. This prevents cross-runtime mismatch and ensures hashes are stable. Failure to canonicalize MUST result in the request being dropped.

DBIS-2: Tiered Safety Decision Determinism:

DBIS-2A Deterministic Safety (MUST): Any decision that changes the Allow / Block / Require Approval semantics for high-risk actions MUST be computed via a deterministic mechanism (e.g., a pinned deterministic inspection profile running in a strict WASM sandbox).
DBIS-2B Advisory Safety (MAY): Non-deterministic models (e.g., standard LLMs) MAY be used for heuristic hints, intent parsing, or assistive transforms only if the final enforceable decision remains fully DBIS-2A compliant.

DBIS-3: Explicit and Scoped Pinned Externalities (MUST):

Externalities relevant to execution MUST be deterministically bound. For example, window_id and visual perceptual hashes are explicitly pinned for UI and browsing actions. However, wall-clock timestamps (e.g., SystemTime::now()) are explicitly classified as non-binding telemetry unless sourced directly from a verified chain/block timestamp.

DBIS-4: The Deterministic Retry Contract (SHOULD):

Agents inherently fail and retry. Retries are permitted, but they MUST be deterministic, bounded, and fully recorded. A failed execution MUST generate a failure receipt, increment a deterministic attempt counter against a strict budget, and be included in the verification evidence. Unbounded, unlogged heuristic loops are strictly prohibited.

DBIS-5: Binding Set for Enforceability Artifacts (MUST)

For any consequential action that crosses the boundary, the runtime MUST emit a transaction-shaped action/evidence record that securely binds:

request_hash (The canonical intent)
policy_hash (The ruleset governing the action)
Context bindings where relevant (e.g., window_id)
Approval references (if the action required a user step-up token)

Enforceable vs. Observational Artifacts

To prevent verification bloat and preempt disputes over non-deterministic telemetry (such as local machine latency), the determinism boundary strictly categorizes all outputs into two artifact classes:

Enforceability Artifacts (Settlement-Grade): These are the inputs to disputes and economic liability. This includes ActionProposal records, GateResult receipt refs, settlement commits, and Merkle inclusion proofs. They are not Web2-style logs; they are transaction records for acts that may become economically or legally consequential. These rely exclusively on deterministic inputs, bounded states, and cryptographic signatures.
Observational Artifacts (Telemetry): These are local UI and ops events (e.g., WorkloadReceiptEvent streams, wall-clock timestamps, local activity feeds). While useful for user experience and debugging, they contain non-deterministic metadata and MUST NOT be used to evaluate policy compliance or settle on-chain disputes.

Design Principle (Normative):

IOI constrains the effects of intelligence, not the process of intelligence. That is how Web4 turns Own into Act without trying to make cognition itself deterministic.

2.4.1 Typed Intent, Constraints, and Acceptance Contract

To enable replay, verification, delivery review, and optional dispute resolution, a GoalRun or task binds normalized intent to typed constraints, acceptance criteria, verifier paths, budgets, policy/authority requirements, and output contracts. Concrete carriers include GoalRun, TaskBriefPayload, ActionProposal, workflow step contracts, ServiceOrder terms, and domain schemas; there is no separate universal intent-contract object in current canon.

The typed contract makes an act transaction-shaped by converting the relevant parts of natural-language intent into fields, constraints, acceptance, and evidence criteria that can be signed, replayed, verified, challenged, delivered, or settled when applicable.

2.4.2 The Adversarial Hierarchy (Adaptive Work Graphs / Deterministic Gate)

To support massive, high-velocity agent work graphs without exposing the Hypervisor Node to chaotic or malicious state changes, IOI bifurcates execution into two distinct security zones. This architecture treats the Hypervisor Node’s protected context (files, wallet, calendar, memory, and authority state) as protected workspace/domain state, and all agent activities as Proposed State Deltas.

The Hypervisor Daemon enforces an Adversarial Hierarchy:

Zone A: The Optimistic Internal Zone (The Delegated Work Graph)

Execution occurs within a Delegation Thread. Workers operate with high velocity using Advisory Peer Review. When a Worker proposes a change (a "State Delta"), another Worker in the graph MAY act as a reviewer to flag obvious errors. Trust is Optimistic: state transitions in this zone are provisional (labeled as speculative state). They allow for messy, non-linear collaboration (e.g., hundreds of asynchronous drafts or plans) but MUST NOT affect the User Node’s protected workspace/domain state.

Zone B: The Deterministic Egress Gate (Daemon/Owner Boundary)

The boundary between the Graph's provisional state and the User's protected state is the daemon effect boundary and owner/authority checkpoint. This is an authoritative, local-first checkpoint. No effect lands in the protected workspace context without passing this gate.

The Gate executes a Deterministic Gate VM- a canonical, sandboxed verification runtime that validates two vectors:

State Validity: It executes a Validation Recipe to verify the output (e.g., "Do the unit tests pass?", "Are the facts verified against authoritative evidence refs?", "Is the transaction syntax valid?").
Policy Compliance: An Intent Contract Evaluator verifies the Provenance Ledger, ensuring the State Delta came from a hired worker, the chain of custody is intact, and the effect does not violate authorized prim:* and scope:* restrictions.

Only if all checks pass does the gate emit the applicable GateResult, ExecutionResult, and receipt refs and admit the resulting state transition under the owner contract.

2.5 Fractal Edge-In Topology and the L0/L1 Boundary

IOI's fractal topology routes state transitions and settlements across strict boundaries:

Governed Autonomous-System Chain

- Accepts local module invocations, proposals, receipts,

and state transitions

v (Local Settlement)

Hypervisor Node (Local Settlement Domain)

- Coordinates multiple autonomous-system chains

- Settles local interop, authority outcomes, local receipt-roots

v (Global Anchoring & Escalation)

IOI L1 (Global Settlement Layer)

- Anchors selected roots (node, system-chain, policy,

module, upgrade roots)

- Settles public rights, disputes, reputation, registry, economics

The layers are not identical. They reuse the same kernel doctrine at different authority and commitment boundaries.

The IOI kernel / L0 substrate provides reusable machinery for: domain creation; policy namespaces; Agentgres domain state; runtime-node profiles; worker and service manifests; receipt and artifact semantics; routing and settlement mirrors; upgrade and governance hooks; and L1 commitment interfaces.

IOI L1 provides: public registry roots; identity and rights anchors; escrow and fee routing; dispute bonds; settlement finality; governance and upgrade approvals; and sparse public commitments.

The topology is edge-in. Runtime edges execute; domain kernels remember; IOI L1 settles.

The purpose of this topology is composability. A result may involve one user’s local Hypervisor, a managed worker from aiagent.xyz, data recipes from a domain ontology, a hosted model, a verifier worker, a sas.xyz service workspace, and an IOI L1 escrow. The architecture must let those layers compose without becoming one centralized runtime.

2.5.1 The Three Execution Axes

Rather than hardcoding static "lanes," the IOI runtime evaluates execution along three dynamic axes, which the user or developer configures as execution "presets."

Axis 1: Where it runs (The Physical Target)

Local Hypervisor: Execution occurs on the user's personal device. Ideal for tasks requiring local GPU, direct desktop/browser control, or ultimate sovereignty where no hosted dependency is desired.
Customer Boundary (VPC / On-Prem): Execution occurs within an enterprise's secure firewall. A Boundary Coordinator orchestrates tasks, ensuring that proprietary data never leaves the internal network.
Provider-Hosted: Execution occurs on a remote cloud or DePIN provider. Ideal for batch jobs, heavy inference requiring massive hardware, or proprietary models that cannot be distributed locally.
Decentralized Private Execution: Decentralized compute nodes with minimized task capsules whose substrate-specific exposure bounds are bound into private-execution receipts; suited to third-party execution of sensitive workloads where centralized infrastructure is undesirable.
Hardware-Attested Confidential: Attested confidential compute nodes (e.g., AWS Nitro, Google Confidential Space) providing hardware-bounded execution and remote attestation under a vendor-specific threat model. Hardware-attested TEEs (such as SGX or confidential GPUs) are an optional performance profile, not the baseline definition of cTEE: the baseline cTEE model relies on software-driven cryptographic containment — candidate lattices, cryptographic operators, and plaintext-free mounts — treating hardware attestation as one admissible private-execution substrate among several.

Axis 2: How inference is sourced and commercially admitted

Open / Self-Hosted Model: Licensed weights run locally, in the customer’s infrastructure, or on an admitted managed runtime with explicit custody and attestation posture.
Bring Your Own Key or Account (BYOK/BYOA): The customer binds an external API credential or expressly permitted interactive account through wallet.network. The customer owns supplier cost; IOI may separately price conductor, runtime, governance, support, or audit value.
Direct or Dedicated Provider Route: IOI or the customer uses a provider API, managed endpoint, reserved capacity, or negotiated inference agreement under a versioned route-rights contract.
Aggregator Route: A replaceable adapter such as OpenRouter supplies breadth, overflow, discovery, or policy-qualified fallback; the underlying provider, terms, privacy posture, and price remain visible and eligible under the route-rights contract.
Proprietary or Specialized Model: Closed or custom weights run behind an admitted provider, dedicated endpoint, customer boundary, or confidential-compute profile under explicit inference and downstream rights.

Named-human workspace seats are excluded from pooled managed-worker supply unless a signed provider agreement authorizes the exact use.

Axis 3: Privacy and Evidence Posture

Privacy posture and evidence posture are related but distinct. The runtime records technical states such as private_native, redacted_api, provider_trust, and unsafe; those states are admission evidence, not separate product modes. Hardware TEEs, cTEE/private workspaces, local/customer boundaries, FHE, MPC, ZK proofs, verifiable computation, and deterministic replay may satisfy different parts of a required receipt profile. Verified means that the declared verifier has accepted the covered evidence and boundary claim; it does not name a single substrate, imply outcome acceptance or settlement, or turn an unsafe custody route into a private one.

2.5.2 Managed Execution Modes

The user-facing managed execution selector has exactly two modes. Speed, model choice, provider choice, and evidence strength remain separate controls:

Standard: IOI-managed execution is private-native at the operating-substrate layer by default: cTEE / Plaintext-Free Runtime Mounting, scoped authority, connector vaulting, and receipts are baseline discipline. A disclosed provider-trust model route may still receive sensitive plaintext when policy permits; that boundary must be visible in the execution privacy posture and receipts.
Private: Adds a no-provider-trust model route for protected data through open-weight or user-controlled models in a local, BYO private-node, customer-boundary/customer-cloud, cTEE, hardware-TEE, or other custody-proven route. The stronger promise must be supported by custody proof, model/API boundary evidence, and receipts.

Private mode may be a paid managed posture when IOI provisions stricter runtime custody, protected connector processing, encrypted storage, attestation/custody proof, audit/replay, or persistent background work. Connecting an app, granting ordinary authority, or using local/BYOM/BYOA without IOI-managed private compute is not by itself a connector tax.

2.5.3 Agentgres: The Per-Domain State Substrate

Agentgres is the per-domain state substrate. It stores operational truth, not IOI L1 economic settlement. Every consequential Web4 application domain (e.g., aiagent.xyz, sas.xyz, enterprise deployments) runs its own kernel/runtime deployment with its own Agentgres domain.

Agentgres is not a thin index over Filecoin/CAS blobs. It owns the canonical operation log, object heads, constraints, indexes, projections, subscriptions, delivery state, and quality/contribution ledgers. The IOI L1 blockchain is used strictly for sparse root commitments, contract state, and dispute resolution. Truth is anchored in Agentgres canonical operations and deterministic object state, not in mutable table rows.

2.5.4 The "Eject" Bridge: Pointer-Based State Injection

Because all engines and execution targets share the exact same Artifact Schema and Fractal Query Fabric (FQF) standards, a user can seamlessly migrate an agent from Local (Private) to Network (Public). This is not a bulk data upload, but a State Injection via the ai:// global namespace. To prevent blockchain bloat, the protocol enforces a strict separation between Logic (Storage) and Authority (Chain).

The Migration Protocol executes in three atomic steps:

1. Content Addressing (The Store):

The Hypervisor freezes the local agent. It uploads the static payload bytes (WASM binary, React UI bundle, connector schemas) to the selected storage backend (a decentralized network such as IPFS/Filecoin, or an enterprise/local CAS), which holds them as opaque blobs. The corresponding ArtifactRefs are declared, versioned, and evaluated exclusively inside the Agentgres Artifact Plane.

Result: A set of Content Identifiers (CIDs).

2. Root Anchoring (The Transaction):

Most portability stays local: the canonical record is the Agentgres ArtifactRef/PayloadRef. When—and only when—a public registry listing, marketplace publication, or cross-domain settlement is triggered, the user submits a DeployAgent transaction to the IOI L1. That L1 payload is minimal (approx. 200 bytes); it contains only the pointers:

Identity: ai://<authority>/<agent_id>/<version> (The human-readable DNS name).
Logic Root: ManifestCID (Pointer to the code).
State Root: agentgres_projection_watermark (The Agentgres projection anchor) or StateRoot.

3. Hydration (The Execution):

A provider environment picks up the job. It uses the ManifestCID to pull the logic, and the StateRoot to rebuild the required projections or retrieve the context slice required for execution.\

Zero-Bloat Invariant: ** A future IOI Mainnet stores selected commitments, not payload bytes. It may anchor publisher identity, registry commitments, valid state roots, and settlement/dispute facts when triggered. The gigabytes of UI bundles, vector-memory archives, datasets, packages, and model payloads are retrieved from storage backends only by the runtime or provider lane provisioning the workload, under Agentgres ArtifactRef/PayloadRef meaning, wallet.network authority, and any declared ModelWeightCustodyProfile.

Zero-bloat is not zero-retention. For every challenge-eligible commitment, the corresponding Agentgres ArtifactRefs and PayloadRefs MUST declare a challenge_epoch_ref, a retention_until height or time, and one or more retrievability lanes (local archive, provider archive, Filecoin/IPFS/S3-style object store, or Witness-Coded Recovery Capsule). The declared retrievability window MUST strictly dominate the challenge period plus publication and retrieval slack:

T_{\mathrm{retain}} \geq
T_{\mathrm{challenge}} + \Delta_{\mathrm{publish}} +
\Delta_{\mathrm{retrieve}} + \Delta_{\mathrm{verify}}.

If a challenged payload cannot be served, reconstructed, and hash-verified inside its declared challenge epoch, that absence is itself objective evidence. The dispute path fails closed: irreversible release is halted and the missing-evidence dispute resolves in favor of the challenger unless the respondent produces the required bytes or a valid recovery bundle before the epoch closes.

2.5.5 Node Profiles and HypervisorOS

Execution venues across the network are classified into standardized Runtime Node Profiles. To ensure bare-metal operational integrity and reproducible environments, high-performance nodes can deploy HypervisorOS — a minimal, measured operating-system image where the Hypervisor Daemon operates as the daemon-root node process.

HypervisorOS is the Type 1 substrate posture of the same Hypervisor control plane. Type 2 is Hypervisor Desktop / Workstation hosted on a normal operating system and governing local VMs, sandboxes, models, tools, agents, connectors, and environments. Type 3 is the autonomy posture across sessions, WorkRuns, workers, harnesses, model routes, tools, authority, receipts, replay, outcomes, and promotion. These are not three products. Type 1 and Type 2 provide the inspectable substrate; Type 3 virtualizes governed autonomy above it. HypervisorOS improves control, integrity, containment, measurement, and reproducibility, but it never replaces cTEE no-plaintext-custody or an applicable confidential-compute proof.

Implementation status. HypervisorOS is a planned node profile; no current HypervisorOS image or measured-boot product build is claimed.

The target boot flow generates a signed HypervisorOSBootReceipt based on a HypervisorOSBootProfile and declared hardware measurements. This receipt is bound to the node’s node capability manifest, detailing its physical resources (such as VRAM, CPU cores, and network capability) and recording the measured image under the profile’s attestation assumptions.

While HypervisorOS provides excellent node measurement, operational control, and execution reproducibility, it is not a privacy cure-all. If a node is deployed on rented hardware where a malicious provider retains physical or out-of-band management access, the provider can still read plaintext state from CPU registers or GPU memory if it is mounted without encryption.

Therefore, a signed boot receipt or measured boot sequence is operational integrity evidence under its threat model, not a substitute for software-level cTEE candidate-lattice decoding or hardware-level confidential GPU protections.

Runtime node profiles.


Node Profile	Host / Hardware Ownership	Target Execution Environment	Isolation / Privacy Posture	Primary Use Case
Local	User-owned (personal computer).	Standard user-space hypervisor layer.	High (no external network data leakage).	Daily personal assistance, document summary, local code synthesis.
Workstation	User/team-owned (high-perf local rig).	Direct OS process within a local VM.	High (sovereign local hardware control).	High-throughput local model inference and development.
Hosted	Third-party provider (SaaS / cloud VM).	Rented virtual machine (non-attested).	Low (host-root can inspect VM memory).	Generic low-risk API agents and standard web scrapers.
VPC	Customer VPC (enterprise cloud).	Controlled enterprise subnet and VM instances.	Medium (bound to enterprise security policy).	Internal enterprise workflows and sensitive database queries.
DePIN	Untrusted rented provider.	Docker container or ephemeral VM.	Low (host can read plaintext); requires cTEE.	Cost-optimized, scale-out compute pipelines.
TEE / Confidential GPU	Attested cloud hardware (AMD SEV, NVIDIA CC).	Attested secure VM enclave / confidential memory.	High (hardware-enforced memory isolation).	Proprietary weight mounting and highly sensitive financial computation.
Enterprise	Dedicated on-prem server.	On-premises hardware behind a strict corporate firewall.	High (completely internal state retention).	Sovereign corporate operations and internal compliance systems.
HypervisorOS	Dedicated server / bare-metal.	Minimal, measured-boot bare-metal image.	High (system integrity); Low (physical hardware spying still possible).	Core provider infrastructure and dedicated routing nodes.

2.6 Policy Enforcement & Authority Gates (Client-Side)

Standard operating systems protect the machine from malware. Hypervisor protects the machine, account, workspace, and organization from unbounded agency.

In a fully managed user-space or HypervisorOS profile, the daemon isolates the untrusted guest workload from declared host capabilities. The daemon effect boundary is the deterministic gate for the network, filesystem, GUI, tool, connector, or provider control points actually mediated by that profile. Opaque external harnesses and ordinary provider adapters are not magically fully trapped; their conformance claim is limited to the controls and evidence their adapter exposes. Consequential crossings that the daemon admits create transaction-shaped receipts.

By leading with OS-level isolation rather than brittle "prompt-engineering," IOI shifts the security paradigm from "prompt-safe" to action-safe.

The daemon effect boundary enforces a strict, four-step decision pipeline at the validator ante level:

Intercept and Normalize: When the agent attempts an externally-effectful operation, the hypervisor intercepts the request and normalizes it into a canonical ActionRequest. This object contains a typed target (e.g., gui::click), deterministic parameters, and the execution context.
Translate Policy Context: The engine loads the active, state-backed PolicyEnvelope and versioned rule set. Rule-set schemas are compatibility representations; the canonical boundary is the policy envelope bound to applicable authority, Agentgres state, and receipt obligations. The bundle includes applicable namespaced ontology-version and action-contract policies, per-target guardrails, and environment capability scopes (e.g., restricted filesystem paths).
Enforce (Context-Aware): The request is deterministically evaluated against the ruleset at the exact moment of execution:

- If a matching cryptographic ApprovalToken is presented for the exact request hash, the action is explicitly allowed.
- Otherwise, rule matching applies (Allow / Block / RequireApproval).
- PII Egress Routing: If the action involves data egress, the daemon routes the payload through a local PII review contract. Here, the deterministic inspection/evaluator path identifies and masks sensitive data before it leaves the local boundary.
- All rejections are fail-closed.

Emit Audit Trail: The daemon emits transaction records and auditable outcomes as signed receipts and events (e.g., EffectBoundaryInterception, PiiDecisionReceiptEvent), ensuring every execution decision is preserved for replayability and deterministic arbitration.

Context-Aware Guardrails

Because the daemon effect boundary sits at the Hypervisor level, its context awareness is real, not heuristic. Conditions are evaluated against live session, OS, browser, workspace, and provider state through mediated adapters. For example:

allow_apps constraints validate the active window for gui::* actions. This prevents "Context Hijacking," where a malicious agent waits for the user to open a sensitive application (like a password manager) before triggering a seemingly benign allowed click.
Click coordinates are mathematically bounded to the active window geometry.
Network actions require strict URL-domain allowlists at the proxy level.
System command execution is constrained by safe command allowlists and command-class bans.

The Interception Boundary (RequireApproval)

The daemon effect boundary functions as the governance boundary between the agent's logic and the host's authority. If a high-risk step triggers a RequireApproval policy, the daemon returns a PendingApproval state and pauses the agent's execution. This triggers the UI to request explicit human consent. Upon receiving a resume command with a valid cryptographic signature from the user, the daemon deterministically verifies the token and allows the OS interaction to proceed.

2.6.1 ActionRequest: The Canonical Action Primitive

To be enforceable, policies must evaluate deterministic inputs. The firewall therefore requires every outbound operation to be translated into a normalized ActionRequest. The ActionRequest is the pre-effect transaction candidate: a canonical representation of the act before authority is granted or execution occurs. This aligns with the Model Context Protocol while adding the strict typing required for security.

The kernel normalizes inputs into the following schema before hashing:

Typed Target: The namespaced identifier, covering both standard and native capabilities:
- Standard MCP: fs::write, net::fetch, wallet::send, sys::exec.
- Native Core (GUI): gui::click, gui::type (OS-level Kinetic actions).
- Headless Browser: browser::navigate, browser::click_selector, browser::eval, browser::screenshot (Hermetic DOM actions).
Arguments: A canonical, schema-validated JSON payload (RFC 8785) containing the tool parameters.
Payload Storage: Large input/output payloads (e.g., retrieval documents, datasets, packages, or model payloads) MUST be referenced through Agentgres-governed ArtifactRefs/PayloadRefs and, where useful, content-addressed commitments. A CID or hash proves bytes; it does not by itself authorize access, define artifact meaning, or make proprietary model weights safe to mount on an untrusted provider. Small payloads MAY be inlined when policy permits.
Context Bindings:
- policy_hash: The hash of the active ruleset.
- session_id: The session identifier (if applicable).
- origin: The ID of the agent requesting the action.
- window_id (Optional): For GUI actions, binding the click to a specific OS window handle to prevent clickjacking.


Normative Invariant: ** This structure prevents bypass via alternate toolpaths (e.g., trying to access the network via browser::fetch instead of net::fetch). The Hypervisor Daemon maps all drivers and MCP servers into the same target namespace, creating a unified daemon action surface for agency where every action, regardless of source, produces an identical, hashable receipt.

2.6.2 Policy Envelopes and Versioned Rule Sets

Daemon effect policies are expressed as versioned policy bundles bound to wallet.network authority, Agentgres state, capability scopes, approval thresholds, budget limits, declassification rules, and receipt obligations. A PolicyEnvelope binds the selected versioned policy schema and canonical rule content. Exact rule schemas belong to the policy and wallet/daemon owners rather than this synthesis. Policies are default-deny and may support graph-aware permissioning. The selected schema determines matching, precedence, decision values, canonicalization, and evaluation semantics; implementations may not infer those rules from unordered source data. Security-critical deterministic inspection must not depend on uncontrolled floating-point, locale, clock, random, or thread-scheduling behavior. See Appendix A.1 for a non-exhaustive policy example rather than a second policy-language specification.

2.6.3 Versioned Policy Canonicalization and Hashing

A PolicyEnvelope binds a versioned policy schema, canonicalization function, evaluation semantics, and policy hash. The owner contract must specify whether rule order is meaningful, how maps, arrays, strings, numbers, identifiers, and duplicates normalize, which canonical encoding is used, and whether evaluation consumes the same representation that was hashed.

The invariant is representation fidelity: two implementations claiming the same policy profile must produce the same canonical bytes and decision for the same valid input, while malformed or unsupported versions fail closed. Raw HashMap iteration, locale-dependent comparison, and source insertion order must not silently change a policy hash or decision unless the owner schema explicitly makes order semantic.

RFC 8785 JCS is the default JSON canonicalization reference where the selected owner profile uses JSON. Exact sorting keys, precedence rules, Unicode handling, and hash algorithms remain in that profile; the example in Appendix A.1 is illustrative and does not establish a second normative policy language.

2.6.4 Deterministic Inspection Assist Profile: Policy Enforcement over a Local Evidence Graph

A decentralized agent system cannot treat arbitrary neural inference as a consensus primitive. Open-ended model execution varies across hardware, runtimes, compiler settings, and vendor-specific kernels. Even when two environments produce semantically similar outputs, they are not a safe basis for policy gates, receipts, or replay-critical validation. IOI addresses this by separating cognitive inference from enforcement: models may propose, but the enforcement path must reduce those proposals to deterministic, replayable structures before they can cross a trust boundary.

Consensus on Enforcement, Not General Cognition

The goal of the deterministic inspection assist profile is not to reproduce a full model's internal reasoning across nodes. The goal is narrower and more useful: consensus on policy-relevant classification and action gating. For PII-sensitive egress, IOI first builds a local evidence graph using deterministic detectors and validators for concrete classes such as API keys, emails, phone numbers, SSNs, and card PANs. The assist profile then operates on that evidence graph, not on raw probabilistic hidden states. If two nodes begin from the same evidence graph, policy, target, and risk surface, they derive the same assist identity, routing outcome, and decision hash.

A Candidate Assist Profile: Narrow and Deterministic

A candidate profile such as inspection_v0 could be a narrow deterministic assist contract, not a generalized quantized LLM. Its role is to refine ambiguous spans in a strictly bounded way before routing and transform decisions are made. Its allowed behaviors are intentionally limited: it may drop spans that are deterministically identified as ambiguity false positives, downgrade confidence buckets, and clear ambiguity in specific policy-defined cases. It may not create new spans, mutate the source hash, increase severity, or upgrade a classification to a more severe class. This keeps the safety layer legible, auditable, and consensus-friendly.

Deterministic Runtime Properties

The assist contract forbids wall-clock reads, RNG, external I/O, locale-sensitive behavior, and floating-point or thread-scheduling dependence. The surrounding PII pipeline is likewise structured around deterministic evidence extraction, rules-only routing, and deterministic transform. In practice, this means the safety decision is driven by stable local detectors, explicit policy controls, and an assist receipt that is bound into decision-hash material. A locally produced PII decision can therefore be validated and replayed without depending on arbitrary model execution.


Status Note: This synthesis does not claim a deployed inspection_v0 profile. Any implementation must be established by its canonical owner and conformance tests and must carry explicit assist identity, version, configuration, module, evidence, and receipt bindings. It must not be marketed as a generalized integer-only model or protocol-wide WASM safety guest.

Normative Invariant:

The validity of the daemon effect boundary must not depend on reproducing open-ended cognitive inference on verifier hardware. Safety-critical policy decisions must be reducible to deterministic evidence, explicit policy state, the applicable authority refs, and a versioned, verifiable assist contract.

2.6.5 The Capability Surface: Primitive Constraints vs. Authority Scopes

The Bifurcated Capability Surface

To prevent security bypasses and ambiguous authority boundaries, IOI abandons flattened capability bags. The capability surface is strictly bifurcated into two tiers:

Primitive Execution Capabilities (prim:*): These describe runtime feasibility, physical isolation, and risk boundaries enforced by the Hypervisor Daemon. Examples: prim:fs.read, prim:fs.write, prim:sys.exec, prim:ui.interact, prim:net.request, prim:model.invoke.
Authority Scopes (scope:*): These describe authority-provider admission policies, budgets, and identity constraints. wallet.network governs portable delegated, secret-bearing, spend-bearing, declassification, cross-domain, and high-risk external scopes; local/domain owners may govern ordinary local scopes. Examples: scope:gmail.read, scope:gmail.send, scope:commerce.order_submit, scope:repo.write.

Every tool and connection MUST define a RuntimeToolContract that declares both its required prim:* capabilities and its scope:* authority boundaries. The Hypervisor Daemon enforces primitive feasibility; the applicable authority provider enforces authority admission. Together, they prevent the "confused deputy" failures that arise when execution capability and resource authority are conflated into a single permission bag.

2.6.6 Capability scopes: permissions, not root

Agents are granted scoped capabilities rather than ambient authority, ensuring they operate within a "Safety Envelope":

prim:net.request bounded by scope:domain_allowlist — outbound allowlists (domains/IP ranges), protocol restrictions, and per-origin limits.

prim:fs.read / prim:fs.write — read/write scopes restricted to sandboxed roots; explicit deny lists for secrets (~/.ssh, /etc, keychains).

prim:ui.interact bounded by scope:ui.application — UI control limited to specific window/application identifiers and interaction types.

scope:wallet.transfer_under_limit — hard ceilings for work credits, settlement assets, and any wallet/transaction operations (per-session and per-day).

prim:sys.exec bounded by an executable policy — restrictions on creating child processes or accessing system binaries (e.g., "Allow ffmpeg, Block bash").

Capabilities define the maximum possible envelope; the daemon policy bundle defines the per-action policy inside that envelope. Concrete rule representations remain versioned owner contracts.

2.6.7 Interception and approvals

1. Request: The active runtime substrate emits an ActionRequest (e.g., gui::click{x,y,window_id}). The substrate may be a process sandbox, container, VM, microVM, WASM worker, browser sandbox, GPU job, TEE enclave, or other daemon-approved execution lane.

2. Evaluation: The Hypervisor Daemon evaluates primitive feasibility and policy, then requests the applicable authority provider. wallet.network is mandatory where a portable delegated grant, secret lease, spend, declassification, cross-domain reuse, or high-risk external effect is required.

3. Settlement Resolution:

* ALLOW: forward to the relevant driver.

* BLOCK: drop the request and return AccessDenied.

* REQUIRE_APPROVAL: pause execution and prompt the user via the IOI UI.

Approval tokens (formalizing “user consent”):

User approvals are issued as signed approval tokens with explicit scope (target + constraints), TTL, and optional usage count (one-time vs session). Tokens are recorded in the audit chain and can be replay-checked to prevent silent reuse. This acts as 2FA for Agency, ensuring critical actions (like spending) require explicit human sign-off. Approval therefore carries Own into Act. The user is not merely clicking OK; they are signing bounded execution authority for a specific transaction-shaped action.

When an action triggers REQUIRE_APPROVAL, the applicable authority provider authorizes a scoped approval artifact. For a wallet.network step-up, issuance follows evaluation of the AccessPointBinding and resolution of the StepUpChallenge. To prevent replay and bypass attacks, the artifact MUST bind:

request_hash (the canonical intent)
policy_hash (the active policy state)
visual_hash (SHOULD be bound for GUI/screen-based actions)
audience (Validator/Executor identity)
expiry (time bound; Chain Time / Block Height)
revocation_epoch (minimum valid epoch for bulk revocation)
counter (Monotonic nonce)

Tokens may be One-Shot (burned upon execution) or Multi-Use (Lease). Multi-use tokens MUST strictly decrement a max_usages counter recorded in the state receipt log.

Gate Results and Decision Receipts

The runtime MUST produce a GateResult and receipt ref for every consequential governed action. It records the ActionProposal, policy hash, applicable authority refs, result, reason, blocker or safe alternatives, and decision receipt. The binding makes the declared decision replayable; it does not by itself prove faithful policy enforcement outside the admitted boundary.

2.6.8 Audit and portability

Every daemon effect decision is appended to the local receipt chain, creating the Economic Chain of Custody by which executable ownership remains replayable and settleable:

action_hash (canonicalized request)
policy_hash
resolution (+ approval token reference if applicable)
timestamp/sequence (daemon or wallet.network authority-profile linked)

Policies themselves are content-addressed (hashed), enabling:

Sharing: developers publish hardened policies (e.g., “Safe Banking”, “Read-Only Email”).
Auditing: third parties verify an agent operated under a declared policy set.
Enforcement: when outcomes escalate to network settlement, the daemon or wallet.network authority path attests to the policy_hash. Artifacts whose bindings do not match the declared policy are invalid for higher tiers.

This turns the user device from a passive terminal into a managed runtime: autonomy is real, but it is bounded by explicit, verifiable constraints that limit Liability.

2.6.9 Effect Boundary Object Family

The Hypervisor Daemon effect boundary uses current HarnessProfile objects to ensure interoperability: ActionProposal (the normalized proposed act and its primitive/scope needs), GateResult (the policy and authority result with a receipt ref), and NormalizedObservation (typed reality returned to the loop). Wallet approvals or grants remain separate authority artifacts referenced by the gate result. All hashes are computed over RFC 8785 canonicalized bytes; policy_hash MUST be stable for a given ordered ruleset. Full Illustrative field summaries are in Appendix A.2; canonical owner documents govern exact schemas and canonicalization requirements.

2.6.10 Attribution Graphs & Contribution Receipts

To scale agency beyond simple tasks, IOI supports Marketplace Neutrality and Contribution Accounting. These primitives ensure that delegated work graphs remain economically legible and that upstream contributors retain credit even when their work is composed into downstream outcomes.

Anti-Cannibalization Rule

The Hypervisor Daemon is the execution substrate, and it mediates HarnessProfiles under loop-native conformance; the Default Harness Profile is the reference scaffold/fallback and possesses no substrate mechanics separate from the daemon. As that substrate, the daemon MUST remain neutral: it is forbidden by conformance, policy, and marketplace-neutrality doctrine from silently cloning, absorbing, or reproducing third-party worker logic into native primitives. Marketplace neutrality is enforced at the protocol level: the runtime cannot use its privileged position to displace the very contributors whose work it routes.

Contribution Receipts

When an agent hires another worker or uses a specialized tool, Agentgres records a ContributionReceipt. This receipt tracks the quality_delta the contribution introduced and binds the contributor’s identity into the downstream outcome’s provenance chain. When the downstream task settles successfully, wallet.network uses the contribution graph to route compensation or credit attribution to upstream providers in proportion to their measured contribution.

The Contribution Graph (Agentgres)

Agentgres maintains the canonical Contribution Graph for each domain: a directed acyclic record of who hired whom, under what authority budget, with what measured quality contribution. This replaces the prior “Delegation Graph Ledger” abstraction with a marketplace-neutral object whose semantics are economic accounting first, runtime sub-hiring second. The graph is queryable as a first-class projection and is admissible as evidence in dispute resolution.

2.6.11 Proposal-Mediated Upgrades & Upgrade Governance

To enable safe autonomous improvement, improvement is re-framed as a governed, proposal-mediated upgrade process. Agents do not self-modify directly. Instead, autonomous systems propose upgrades to governed modules, workflows, skills, memory projections, routes, and policies, and only policy-bound, receipted governance makes those upgrades canonical.

When an autonomous system identifies a performance limitation, it executes the following upgrade pipeline:

1. Observe limitation & draft an Upgrade Proposal.

2. Bind the target module, workflow, policy, tool, model route, or schema.

3. Simulate, evaluate, benchmark, or dry-run the proposed changes.

4. Review the upgrade under current policy and authority.

5. Approve, reject, escalate, or roll back.

6. Commit the accepted operation through the daemon into Agentgres.

7. Emit Upgrade Receipts and optional IOI L1 anchored roots.

The receipt set is typed. A ContextMutationReceipt binds a versioned context update, contradiction, supersession, or deprecation to evidence, policy, authority, and worker/project refs. A PromotionDecisionReceipt binds a context, adapter, route-policy, evaluation, package, skill, or workflow promotion decision to baseline/candidate versions, regression checks, gates, rollback refs, and policy. Training, benchmark, evaluation, and routing effects use the same receipt family as Worker Training: TrainingReceipt, BenchmarkReceipt, EvaluationReceipt, and RoutingDecisionReceipt.

This process strictly enforces the Monotonic Policy Invariant (Policy_New must be a strict subset or equivalent of Policy_Old) at the boundary, ensuring logic can be optimized but privileges cannot be expanded without explicit step-up signature authorization.

The Subset Inclusion Invariant:

An upgrade is valid IF AND ONLY IF Policy_New is a strict subset or equivalent of Policy_Old ⊆.

Allowed: "I want to remove my access to the filesystem because I don't need it." (Tightening constraints).
Allowed: "I want to change my system prompt to be more polite." (Logic change, Constraint unchanged).
BLOCKED: "I want to add access to api.stripe.com." (Loosening constraints).
BLOCKED: "I want to increase my daily spend limit." (Loosening constraints).

This prevents an accepted upgrade from silently widening its own declared authority. It does not prove that changed logic is harmless. Any proposed constraint relaxation requires a new, explicit authority and policy decision under the applicable owner contract.

Continuity Proofs

A future High-Assurance Continuity Profile (Section 9.4.4) may require a versioned continuity record carrying an accumulator and proof for a precisely specified transition predicate. Under such a profile, an upgrade lacking the required proof is rejected and the existing manifest remains canonical. No particular record name, proof backend, or recursive circuit is canonized by the current architecture owners.

3. State, Memory, and Semantic Data

Traditional web applications rely on a centralized relational database as the source of truth, with blob storage for files and caches for speed. Decentralized agentic applications require a different foundation: canonical replayable operations, portable serving across untrusted nodes, and cryptographic receipts. A centralized database cannot serve as the ultimate source of truth for decentralized, portable agency.

To replace this legacy stack, IOI uses a kernel-native state and memory architecture with two complementary planes. Agentgres is admitted operational truth: the canonical operation log and its materialized projections, serving the role traditionally held by a centralized database without inheriting mutable-row truth semantics. Agent Wiki / ioi-memory is the semantic context-memory plane: the agent’s local execution history, document corpus, learned tool affordances, workspace facts, and vector embeddings, serving the role traditionally held by a user’s personal context. Authoritative execution history, however, is not held in this fuzzy substrate: it consists of admitted operations and receipts carrying their declared assurance stage inside Agentgres, which Agent Wiki / ioi-memory indexes for semantic retrieval. Receipt presence alone does not imply verification, acceptance, adjudication, or settlement.

IOI separates state, memory, and semantic data:

Agentgres stores canonical operational truth: accepted operations, object heads, state roots, projections, subscriptions, receipts, ledgers, and archive refs.
ioi-memory stores private semantic memory, retrieval surfaces, references to execution traces, and task-scoped context.
Domain Ontologies and Data Recipes define domain meaning and transform raw sources into ontology-bound runtime, training, evaluation, and projection data.

Agentgres: The Application’s Truth. Agentgres rejects the premise that mutable database rows are the source of truth. Canonical truth is the deterministic operation log; app-facing reads are materialized as strictly verifiable Agentgres Projections.
Agent Wiki / ioi-memory: The Worker’s Memory and semantic context plane. It governs what the worker knows, providing tiered memory (working, core, archival), vector search, learned tool affordances, route preferences, wiki facts, and privacy slicing. Archival and core memory mutations are not direct file operations; they must be written to the Agentgres Artifact Plane via ContextMutation commits before they count as durable or portable state.

3.1 Agentgres: Operation-Backed Domain Truth

Agentgres is the operational truth substrate for governed autonomous-system chains and Hypervisor Node local settlement domains. It records proposals, module invocations, local settlement records, receipt roots, upgrade decisions, state roots, and replayable projections.

For collective pursuit, Agentgres records the admitted per-domain OutcomeRoom and CollaborativeWorkGraph state: discovery and participation decisions, participant leases and portable exit bundles, resource and capability offers, frontier items, claim leases, attempts, findings, verifier challenges, generic WorkResults, OutcomeDeltas, contribution lineage, and replay refs. It records what a domain admitted; it does not make a room, message board, or federation into one globally mutable truth database.

Each serious Web4 application domain (e.g., aiagent.xyz, sas.xyz, enterprise deployments) runs its own kernel/runtime deployment with its own independent Agentgres domain.

Agentgres stores:

governed autonomous-system chain records;
Hypervisor-node local settlement records;
service module manifests and registry roots;
module invocation records;
proposal queues and upgrade decisions;
admitted operations and domain sequence numbers;
object heads and state roots;
schema versions;
constraints and invariants;
policy hashes;
authority grant refs;
artifact refs;
projection definitions and checkpoints;
subscription watermarks;
receipt metadata;
OutcomeRoom discovery, participation, lease, exit, frontier, claim, attempt, finding, challenge, WorkResult, OutcomeDelta, and replay objects;
ontology versions, overlays, assertions, crosswalks, semantic mapping decisions, and ontology action contracts;
quality/contribution ledgers;
settlement mirrors;
archive refs and restore receipts.

Agentgres state is domain-local operational truth. A domain may publish state roots, registry roots, settlement mirrors, receipt roots, or dispute commitments to IOI L1, but ordinary projection state, traces, subscriptions, runtime state, and worker-training state stay in the domain kernel unless a public commitment is required.

An OutcomeRoom therefore names its shared-state admission owner. In hosted_admission, the host domain sequences and admits the room projection. In federated_admission, a versioned policy declares the member domains, ordering or merge rules, conflicts, quorum or adjudicator, failover, and recovery. Each participant still admits its own private work and outbound claims locally. AIIP carries signed refs and permitted deltas between those boundaries; packet arrival, participant consensus, or leaderboard state is evidence input rather than automatic Agentgres admission.

Each serious domain should have its own Agentgres kernel:

agentgres://domain/local-hypervisor-user
agentgres://domain/ioi.ai
agentgres://domain/aiagent.xyz
agentgres://domain/sas.xyz
agentgres://domain/enterprise-customer
agentgres://domain/sovereign-worker-network

These domains may reference one another explicitly, but they should not share one giant mutable Agentgres state. Cross-domain references bind object refs, state roots, manifest hashes, policy hashes, receipt roots, room-admission watermarks, semantic mapping decisions, restricted views, and settlement mirrors. A hosted room database is never a portability dependency: a departing participant may retain a signed, policy-filtered ParticipantStateBundle whose historical proof remains usable without continued access to the room host.

Agentgres operates across a rigorous, decoupled data stack:

The Canonical Operation Log (The Deepest Truth): The state machine does not mutate rows in place. Every state change is a signed, canonical operation appended to the log. Truth is historical and replayable.
The Object Model: A semantic object framework built over the canonical state log. It holds domain entities like Service, Version, Run, Receipt, CapabilityLease, OutcomeRoom, WorkFrontierItem, Attempt, Finding, WorkResult, OutcomeDelta, and the federated ontology object families (object-first truth, not row-first truth).
The Projection Engine: The computational engine that maintains materialized read models, derived indexes, real-time changefeeds, and projection checkpoints.

The Replay Invariant: Because all truth originates from the canonical operation log, any node can independently reconstruct the current state of the application by replaying the signed operations from genesis to the current agentgres_projection_watermark.

3.2 The Agentgres Artifact Plane and Storage Boundaries

To prevent state corruption and to avoid the critical security flaw of trusting storage layers with protocol authority, the Hypervisor enforces a strict boundary between the Agentgres Artifact Plane and passive Storage Backends.

Storage backends (such as Filecoin, IPFS, S3, or local disk partitions) are strictly passive byte repositories. They do not possess authority, they do not understand schemas, and they cannot validate the cryptographic lineage of the data they hold. Raw bytes retrieved from a storage backend do not constitute canonical evidence, a valid delivery, or portable state unless they are bound to an ArtifactRef or PayloadRef registered within the Agentgres Artifact Plane.

The Agentgres Artifact Plane is the canonical meaning, admission, and lifecycle layer for operational artifact semantics, state-root validity, and structural lifecycle management. It is not an authority provider. When a worker generates an output (e.g., a PDF, a dataset, or a state archive), the Hypervisor Daemon commits the metadata, policy linkages, and cryptographic receipts to Agentgres, mapping these to the raw bytes via content-addressed identifiers.

Backend availability is also represented as admitted operational state. If a payload ref is missing, stale, unavailable, fails hash validation, or cannot be retrieved from its declared backend, the daemon records an ArtifactAvailabilityIncident in Agentgres. Repair, replica selection, backend migration, archive regeneration, or replacement binding must emit an ArtifactRepairReceipt. These records do not make Filecoin, IPFS, S3, local disk, or any object store the truth layer; they make storage failure and recovery accountable under the Agentgres artifact lifecycle.

For artifacts that can become dispute evidence, availability incidents are not merely telemetry. During a live challenge epoch, failure to serve the bytes named by an admitted ArtifactRef or PayloadRef before the declared retrieval deadline creates a valid MissingEvidence challenge. Agentgres remains the semantic truth layer, but the protocol requires enough data availability to reconstruct the challenged trace. Storage backends may hold the bytes; Agentgres records the commitments, retention bounds, repair receipts, and challenge consequences.

Storage, meaning, and authority boundary.


Dimension / Asset	Agentgres Artifact Plane (Meaning / Lifecycle)	Storage Backends (Passive Byte Storage)
Data Owned	ArtifactRef, PayloadRef, EvidenceBundle, DeliveryBundle, and AgentStateArchive.	Raw blocks, blobs, and encrypted byte arrays.
Responsibilities	Records policy and authority linkages; validates structural lineage, state roots, receipt-to-action bindings, artifact lifecycle, and restore validity. Applicable authority providers authorize access and mutation.	Storing, retrieving, and serving requested bytes by hash, key, or path.
Trust Profile	Admitted Operational Truth. Writes cross daemon/domain admission under applicable local governance and wallet.network authority.	No Semantic or Execution Authority. Treated as an untrusted or volatile transport and storage channel.
Valid Systems	Local Agentgres instances, Domain Kernels, and Mirror Nodes.	Local disk, AWS S3, Google Cloud Storage, Filecoin, CAS/IPFS, and DePIN blob stores.

To prevent blockchain bloat and ensure fast execution, the architecture enforces a strict separation between operational metadata and heavy payloads.

Agentgres is not a thin index over Filecoin/CAS blobs.

Agentgres (Hot / Operational): Owns the canonical operation log, object heads, constraints, indexes, projections, subscriptions, receipt metadata, delivery state, and quality/contribution ledgers.
Storage Backends (Cold / Payload): Store payload bytes behind Agentgres-governed refs: worker packages, large evidence objects, trace bundles, generated artifacts (PDFs/videos), and archival checkpoints. Filecoin, CAS/IPFS, S3, object stores, CDNs, and local disk are backend examples, not authority layers.

The Mechanism: storage backends store payload bytes; Agentgres stores the ArtifactRef. The ArtifactRef binds the payload’s Content Identifier (CID/Hash) to its provenance (which run produced it, which receipt validates it, and what policy governs its access).

Managed worker instance lifecycle. Managed worker instances may keep small canonical refs hot and move heavy or idle state cold. Hot state includes instance id, worker manifest ref, lifecycle status, latest state root, runtime assignment, authority policy, subscription/entitlement, archive CID/hash, policy hash, and restore permissions. Cold state may include traces, context windows, intermediate artifacts, inactive patch branches, cached projections, checkpoints, and evidence bundles sealed as encrypted content-addressed archives.

Agentgres has two planes.

Hot canonical runtime state: operation log; object heads; task/run/patch state; projection checkpoints; active subscriptions; leases; receipts; archive refs and lifecycle metadata.

Cold durable artifact plane: encrypted snapshots; trace bundles; evidence bundles; replay exports; dormant agent/worker state; large payloads; backups; sealed archives, including SealedStateArchive payloads for inactive, idle, portable, migrated, or restorable runtime/domain state.

Filecoin/CAS/S3/local disk may hold encrypted archive bytes by hash/CID. These bytes are not canonical live state. Agentgres is the authority that records the archive ref, state root, schema version, policy hash, object heads, authority context, restore policy, and receipts.

Operation-backed restore and import. State restoration is never a silent, out-of-process local file mutation. The Hypervisor Daemon executes state imports as canonical, operation-backed Agentgres transactions.

in local log)

1. Archive Retrieval: the Hypervisor Daemon fetches the encrypted AgentStateArchive bytes from the designated Storage Backend.

2. Cryptographic Verification: the retrieved bytes are hashed and matched against the expected content-addressed identifier (CID) to guarantee payload integrity.

3. Authority Validation: the daemon queries wallet.network to verify the requester’s identity and obtain a valid cryptographic key or short-lived decryption lease.

4. Decryption: the bytes are decrypted within the secure hypervisor runtime.

5. Agentgres Operation Import: the state transitions are ingested and parsed as a sequence of signed operations in the Agentgres log, ensuring historical consistency and preventing arbitrary state injection.

6. Projection Reconstruction: the projection engine rebuilds the materialized database views, bringing the active workspace up to the current state-root watermark.

7. Receipt Recording: the daemon generates and commits a canonical RestoreReceipt to the Agentgres log, permanently recording who restored the archive, under which policy, and with what valid receipt references.

Secret handling. Secrets should be represented by wallet.network references or sealed key leases, not embedded as raw secret material in state archives. Restore reacquires scoped authority instead of replaying stale secret material.

3.3 Projections & Subscriptions: The Agentgres Read Interface

In traditional databases, indexes and views are hidden implementation details. In IOI, Projections are first-class, versioned protocol artifacts. Agentgres serves these projections directly to applications.

Agentgres supports multiple projection families natively:

Relational Projections: For dashboards, billing summaries, and tabular admin views.
Graph Projections: For service dependency graphs, capability workflows, and lineage tracking.
Timeline / Event Projections: For run timelines, audit trails, and operation feeds.
Capability Projections: For resolving “what this session can access” or “what this lease permits.”

Projection Watermarks: Clients bind directly to these named, versioned projections. Because projections are asynchronous, every read from Agentgres includes an agentgres_projection_watermark (e.g., domain_seq:99182). This guarantees that the client knows exactly which sequence of operations is reflected in the view.

Postgres bridge. Projections are first-class serving surfaces. Agentgres may expose SQL or Postgres-compatible reads over named projections for BI tools, admin tooling, dashboards, ORMs, and psql-compatible clients. Projection reads must expose freshness, domain sequence, policy, and source watermarks when relevant.

Projection compatibility does not imply mutable-row canonicality. Writes become canonical only when compiled into Agentgres operations and accepted under schema, authority, policy, constraints, invariants, and receipt obligations.

The canonical bridge/readiness object names are explicit. AgentgresPostgresBridge is a Postgres-compatible read/query surface over named projections, not a mutable-row truth store. AgentgresConsistencyLevel declares whether a read is cached_projection, projection_consistent, snapshot_consistent, state_root_consistent, linearized_domain, or serializable_domain. DomainSequence is the ordered accepted-operation sequence for an Agentgres domain; recovery restores to sequence N, verifies roots through N, and rebuilds projections from verified checkpoints. AgentgresInvariant covers validity rules such as authority, receipt, settlement, policy, temporal, projection, state-root, artifact-integrity, and policy-monotonicity requirements. AgentgresConstraint covers object rules such as required fields, schema types, unique keys, foreign refs, checks, exclusion rules, cardinality, and temporal ranges.

3.4 Distributed Runtime Serving, Managed Instances, and Subscriptions

Agentgres enables true multi-environment serving. If a user is interacting with an app through provider environment A, and that environment goes offline, the client can seamlessly fail over to provider environment B without losing application state.

This is achieved via Stateless Portable Session Tokens and Resumable Subscriptions. Instead of sticky web sessions, the client holds a token scoping its read/write capabilities. When connecting to a new node, the node statelessly verifies the token and resumes the client’s Agentgres projection changefeed via a deterministic change_seq delta catch-up or a verified ProjectionCheckpoint rebase.

Managed Worker Instances and Runtime Subscriptions

A ManagedWorkerInstance is a user-, organization-, or project-bound initialization of a worker package. Product UX may call it an agent instance, but canonical state binds it to:

worker manifest ref;
install/license right;
owner or tenant;
runtime assignment or routing policy;

persistence profile: per-invocation | warm |
  persistent | zero-to-idle;

authority policy;
memory/archive policy;
interaction surfaces;
subscription or entitlement;
latest state root and archive refs;
receipt obligations.

A RuntimeSubscription is the entitlement or billing object that keeps an instance available. It may pay for per-invocation use, warm runtime allocation, persistent runtime allocation, restore operations, storage, archive retention, verifier costs, or premium routing. It does not grant the worker ambient authority; authority still flows through wallet.network or an equivalent authority layer.

3.5 The Query Model & Consistency Levels

A query in Agentgres is a runtime capability. Agentgres exposes a structured REST and relational API for local machine-economy objects (POST /v1/query), registering paths for:

/v1/hypervisor-nodes
/v1/autonomous-system-chains
/v1/service-modules
/v1/module-invocations
/v1/upgrade-proposals
/v1/upgrade-proposals/{proposal_id}/decisions
/v1/local-settlements

Clients must declare their required Consistency Level:

cached_projection: May be stale; suitable for UI, search, and non-critical browsing.
projection_consistent: Read is served from a named projection at a declared watermark.
snapshot_consistent: Multiple reads observe the same projection or state snapshot.
state_root_consistent: Read is bound to a specific domain state root.
linearized_domain: Read observes all accepted operations up to the latest committed domain sequence.
serializable_domain: Operation set is evaluated as if applied in a single valid serial order.

3.6 Agent Wiki / ioi-memory Context-Memory Plane

Memory inside a worker is not a singular flat file or an unchecked database table. The Hypervisor decomposes memory into a multi-tiered structure that separates volatile, in-flight semantic cognition from committed, policy-relevant state.

Agent Wiki (also referred to as ioi-memory) is the semantic context and private memory plane of the worker. It governs what an agent can know, retrieve, remember, and adaptively apply. While the Agent Wiki manages semantic retrieval surfaces, embeddings, and context indexes, it is not a direct arbiter of legal or protocol truth.

Persistent workspace intelligence. Skills, wiki facts, learned tool affordances, route preferences, failure lessons, and durable behavior-affecting context are workspace/project/domain state, not property of the currently selected model or harness. They should survive model and HarnessProfile swaps when workspace identity, compatibility, provenance, policy, privacy posture, and wallet.network authority allow. If such intelligence affects routing, policy, training, shared knowledge, replay, restore, or future behavior, the mutation must be admitted through Agentgres rather than remaining as invisible prompt residue.

Agentgres serves as the admitted truth substrate. It is not the worker’s complete cognition substrate — it does not house raw vector embeddings or ephemeral scratch hypotheses — but it acts as the authoritative ledger for memory mutations.

Ephemeral thoughts, hypotheses, task-local summaries, and raw retrieval candidates remain within the volatile semantic plane. Whenever a memory change becomes durable, policy-relevant, portable, shared, or legally binding, however, it must cross the Agentgres Admission Boundary. The boundary is crossed by executing a formal ContextMutation or memory-commit transaction, binding the updated semantic state to active policy hashes, receipt references, and provenance metadata inside Agentgres.

The four-layer memory architecture.

THE FOUR-LAYER MEMORY ARCHITECTURE

While Agentgres manages admitted operational truth, ioi-memory manages the agent’s private semantic memory, thread checkpoints, and local context caches as adjacent runtime-memory material. Those checkpoints and caches accelerate recall, enrichment, rollback, or inspection; they do not replace Agentgres operation logs, ArtifactRefs, projection checkpoints, restore validity, or replay authority. The memory plane is organized as a modular, tiered architecture:

Thread Execution (LangGraph-shaped): Maintains resumable transcripts and bounded working state.
Tiered Ontology (Letta-shaped): Separates memory into distinct working, core, and archival layers.
Background Enrichment (Zep-shaped): Utilizes an asynchronous pipeline for summaries, entity extraction, and compaction, avoiding synchronous runtime bottlenecks.
Local Evidence / Artifact Cache: May cache or index blob-oriented evidence and artifact payloads for retrieval. Artifact identity, lifecycle, checkpoint refs, replay meaning, and restore validity remain Agentgres Artifact Plane concerns; storage backends hold bytes.

3.6.1 Locality-by-Default

By default, the substrate index remains local:

Local execution: Retrieval occurs against the local substrate and context is consumed locally.
Remote execution: When offloading to a provider, the runtime does not export the full corpus or index. It exports only a task-scoped context slice under the privacy-preserving injection protocol.

Instead of moving user data to centralized compute, IOI moves the compute to the data.

Invariant: the user’s Agent Wiki / ioi-memory corpus, retrieval indexes, and durable workspace intelligence never become a provider dependency. Provider runs receive only policy-bound context slices, redacted projections, encrypted refs, or cTEE/private-workspace handles.

3.6.2 The Memory API

Agent Wiki / ioi-memory exposes a uniform, policy-governed retrieval interface to agents and workflows. It utilizes Intent-Constrained Addressing (ICA) to abstract over raw file formats and storage locations, treating user context as a queryable knowledge graph rather than a directory tree. Durable or behavior-affecting updates still cross the Agentgres Admission Boundary through ContextMutation or equivalent Agentgres operations before they become canonical, portable, or replay-relevant.

// Querying Agent Wiki / ioi-memory via ICA

agent.memory.query("Q3 financial reports", limit = 5)

The runtime resolves this into a policy-governed retrieval operation against the local Agent Wiki / ioi-memory plane and Agentgres domain refs, returning the minimal set of relevant chunks (plus metadata/provenance) required for the current step of the agent DAG.

3.6.3 Privacy-Preserving Context Injection

When a local agent offloads to a provider, remote execution needs context to be useful, but users require privacy by default. IOI solves this with privacy-preserving context injection: a protocol that minimizes the exported surface area, binds it to explicit policy, and encrypts it under session-scoped keys.

The export follows the selected owner contract: a scoped MemoryProjection or ContextLease for goal work, a ContextHandoff/TaskBriefPayload for delegation, or a PrivateWorkspaceCapsule and custody profile for protected remote work. No generic packet type is allowed to absorb memory truth, authority, or raw workspace custody.

3.6.4 Portable Memory Vault and Projection Contract

A MemorySpace is durable workspace/project/domain memory truth. Harnesses and models consume scoped MemoryProjections; they do not own the raw store, and harness-local memory remains cache. A run proposes a durable addition, supersession, or archive operation through a ContextMutationEnvelope. Review applies the same validation, sensitivity, connector, provenance, policy, and Agentgres admission gates as ordinary memory mutation and emits a context-mutation receipt.

OutcomeRoom state is not memory merely because a participant observed it. Messages, attempts, findings, ontology mappings, evaluator suggestions, leaderboard state, and ParticipantStateBundles remain provenance-bearing, tainted collaboration inputs until the owning domain admits a specific ContextMutation. Admission must preserve source and room refs, license and export posture, evidence and assurance stage, contradiction or supersession, retention, and any downstream recall obligation. Popularity, participant consensus, a signature, or a receipt alone cannot promote room material into durable memory, routing policy, an ontology, or production capability.

The portable ioi.hypervisor.memory-vault.v1 bundle is a human-readable transport for MemorySpace records, memory entries, skills, and automation affinities. It preserves stable refs, tags, source refs, confidence, sensitivity, compatibility, expiry, archive/revoke state, connector refs, timestamps, and structured sidecars. Export scrubs and reports credential material; import rejects credential-bearing bundles, validates records through the ordinary gates, remains idempotent, and reports same-ID content conflicts rather than overwriting or duplicating silently.

The vault is a portable serialization of MemorySpace truth, not an independent truth source or harness prompt file. Agentgres records admitted meaning and mutations; encrypted storage or archive backends hold bytes; authority and policy determine who may view, import, export, mutate, declassify, or restore. The room-specific ParticipantStateBundle is a different portable object: it preserves the participant’s permitted work, contribution, evidence, receipt, acceptance, settlement, and dispute lineage while excluding private room database state, raw secrets, protected plaintext, unauthorized connector payloads, unrelated memory, and non-opted-in training traces. Neither bundle grants continuing room access or execution authority.

3.7 Domain Ontologies and Data Recipes

Federated Domain Ontologies and Data Recipes are IOI’s semantic world plane. They make independently governed domains legible to workers without requiring one global ontology or one global database. An ontology states what one governed domain means under a namespaced, versioned contract; a Data Recipe states how raw sources become ontology-bound runtime, training, evaluation, and projection data.

A DomainOntology defines entities, relationships, events, actions, states, roles, invariants, namespace ownership, compatibility, and deprecation policy. Its immutable OntologyVersion and locally governed OntologyOverlay profiles preserve base-version lineage. A CanonicalObjectModel grounds that meaning in identifiers, schemas, lifecycle states, constraints, privacy classes, authority needs, and projection hints.

Local canonicality is the default. An organization or autonomous system may canonically define its own objects, actions, assertions, and policy. Cross-domain work declares namespaced versions, compatibility ranges, crosswalks, mapping decisions, and policy-bound projections. No network-wide ontology, crosswalk, or room schema silently overrides a domain’s local definition, and AIIP semantic negotiation does not become a universal schema authority.

Operational admission and semantic truth remain distinct. A ProvenanceAssertion, represented by the shared OntologyAssertion envelope, records subject, predicate, value, valid and transaction time, source and observation context, confidence or uncertainty, supporting and contradicting evidence, applicability, causal or counterfactual context where relevant, supersession, dispute, and admission state. Agentgres can prove that a domain admitted that assertion under a policy and evidence set; admission does not make the proposition universally true.

Cross-domain meaning is explicit and challengeable. An OntologyCrosswalk is the OntologyMapping profile that declares source and target versions, mapped objects, relationships, events, and actions, compatibility, loss, ambiguity, policy-bound views, validation, and migration. A SemanticMappingDecision applies a crosswalk or adapter to a concrete handoff, query, object, or action and binds the target, decision maker, verifier challenges, version, and decision receipt. Silent field equivalence is forbidden.

Ontology actions become executable only through an OntologyActionContract. The contract binds the semantic action and target object to typed inputs and outputs; preconditions, postconditions, invariants, and expected state transition; runtime, tool, automation, and prim:* capability requirements; local policy and scope:* authority requirements; risk, approval, revocation, preview, and dry-run posture; idempotency and retry behavior; one external-effect recovery class (replayable, checkpointable, compensatable, reconciliation_required, or non_retryable); ambiguous-effect reconciliation and compensation; verifier, evidence, and receipt obligations; and a Physical Action Safety profile where an actuator can be affected. An action name or connector method alone is never an execution contract.

Ontology semantics do not grant power. Local or domain governance and the applicable authority provider authorize; the Hypervisor Daemon admits and enforces execution; Agentgres admits resulting durable operational state. A prior transformation or mapping receipt is evidence of that boundary event, not perpetual permission to read, train, export, or act.

Data Recipes define how source systems become admitted semantic state. A DataRecipe maps documents, connector payloads, traces, work analytics, feedback, examples, corrections, and source systems into ontology-bound objects and assertions, policy-bound data views, evaluation datasets, distilled ontology datasets, and Agentgres projections. Raw connector payloads remain source material until a ConnectorMapping, transformation, validation, policy, and receipt path admits their meaning.

The canonical path is:

raw sources

-> ConnectorMapping

-> DataRecipe

-> TransformationRun

-> canonical ontology-bound objects

-> PolicyBoundDataView

-> DistilledOntologyDataset / EvaluationDataset / WorkerTraining / OntologyProjection

-> WorkerManifest, MoW routing, service outcomes

Workers train on ontology-bound data, not raw blobs. For efficient specialist workers, the best substrate is often distilled ontology-bound data: compact examples, counterexamples, verifier assertions, tool traces, canonical object transitions, rubric judgments, and failure regressions derived from ontology-bound source material.

An ontology-bound OutcomeRoom may share a namespaced collaboration schema for objectives, frontier items, claim leases, hypotheses, attempts, findings, artifacts, evaluations, verifier challenges, resource leases, contribution claims, and decisions. The declared hosted or federated policy admits the shared-room projection; it does not merge participating Agentgres domains into one mutable graph. Other domains receive only authorized projections, proofs, summaries, derived objects, or query results.

Adoption is progressive. A domain may begin with the minimal consequential objects and action contracts required for useful work, then learn and govern new schemas, mappings, assertions, views, and evaluations from admitted work. IOI does not require exhaustive enterprise modeling before a worker may act.

3.8 Canonical Object Models and Connector Mappings

Connector payloads are not canonical domain truth by themselves. A ConnectorMapping maps provider fields, files, events, and actions into canonical object models and authority scopes. For example, CRM records, emails, spreadsheets, PDFs, repo events, tickets, and prior work traces become domain objects only after a DataRecipe extracts, redacts, normalizes, dedupes, validates, and links them under policy.

3.9 Distilled Ontology Datasets and Evaluation Datasets

DistilledOntologyDataset is a compact, high-signal dataset derived from ontology-bound source truth. Distillation may use teacher workers, verifier workers, deterministic gates, human reviewers, and data recipes. It may reduce source volume, but it must not erase provenance. A distilled dataset binds source commitments, recipe versions, policy-bound data view refs, transformation receipts, teacher/verifier refs when used, and rubric or benchmark bindings.

EvaluationDataset is the benchmark-facing counterpart: golden cases, holdouts, adversarial cases, failure regressions, expected outputs, rubric refs, benchmark refs, and provenance commitments. Evaluation datasets are not ad hoc folders of examples; they are receipted inputs with domain meaning.

4. Network, Routing, and Work Graphs

IOI replaces the flat gossip mesh of traditional blockchains with an Elastic Topology: locality-first execution with network escalation only when capacity, capabilities, or enforceability require it.

4.1 Private Workspace Backed by cTEE

Implementation status: speculative. This section defines the target custody contract; no current cTEE implementation or no-plaintext-custody product claim is implied.

Remote execution and workload offloading to untrusted or rented compute nodes — such as decentralized DePIN nodes or hosted third-party virtual machines — are governed strictly by the Private Workspace backed by cTEE posture. A hostile-root node must never become the plaintext custody domain for protected workspace state. Under this posture, simple encryption-at-rest is insufficient, because the node’s memory could still expose raw workspace variables during live execution. Instead, a conforming future runtime establishes a Cryptographic Trusted Execution Envelope (cTEE) that enforces the declared no-plaintext-custody profile for protected workspace assets. A protected remote run remains a temporary escalation from a Hypervisor Node runtime (Local) into a Provider runtime (Session): the Hypervisor Node exports a minimal execution capsule, receives a result plus verifiable accounting artifacts, and reintegrates the output into the local agent graph — but that capsule carries no plaintext custody of protected state.

When the selected privacy posture is software-only, cTEE means zero-disclosure cryptographic partitioning, not software-only memory isolation. Protected state remains encrypted, secret-shared, committed, guardian/client-held, or assembled locally through candidate-lattice private decoding. The hostile-root provider may receive public trunks, redacted projections, encrypted refs, candidate lattices, and capability handles, but it MUST NOT receive the deciphering key or materialize protected plaintext inside provider-visible CPU, GPU, disk, log, cache, or process memory. Local lattice assembly, guardian selection, cryptographic operators, or approved confidential-compute lanes are the privacy mechanism; encrypting a normal plaintext runtime is not.

The Offload mechanism targets a Private-Execution Non-Exposure property. The exact guarantee depends on the selected substrate and must be represented explicitly in the receipt bundle:

Provider exposure bound: what the infrastructure operator can and cannot observe under the declared substrate threat model.
User exposure bound: what the user can and cannot extract from developer-owned logic, weights, or protected data.
Developer exposure bound: what the developer can and cannot observe about the user’s private inputs or context slices.
Verifier requirements: which attestations, proofs, transcripts, commitments, or replay evidence are required before the output can be accepted.

The protocol mandates a Session Erasure Obligation. A provider must emit evidence that the session was closed, state was not retained beyond the authorized window, and any cached context was deleted or rendered cryptographically inaccessible according to the substrate’s erasure model. For TEE-backed sessions, this may include teardown attestations and enclave lifecycle receipts. For cryptographic operator paths, this may include proof transcripts, key-erasure commitments, MPC transcript closure, or output-only commitments.

Session Offloading is strictly restricted to cognitive and data operations. Offloading migrates only the declared runtime-session state needed for the step. The wallet.network authority keys, policy engine, kinetic operations (mouse, keyboard, hardware control), and local memory substrate remain on the Hypervisor Node or authenticated client authority domain.

To enable computation without exposing private state, the workflow is split into public/compartmentalized execution payloads and secure local state.

Allowed Node Exposure (What the Node May Receive):

– Public trunk code and dependency blueprints.

– Redacted projections and schema definitions.

– Encrypted references and content-addressed commitments.

– Candidate lattices (for structured output decoding).

– Public model weights and benchmark kernels.

– Sealed private-head handles and capability-exit requests.

Protected State (What the Node Must Never Receive in Plaintext):

– Protected user files, raw PII, and private research notes.

– Proprietary quant strategy source, private thresholds, and private coefficients.

– Ambient API credentials and private memory indexes.

– Live portfolio states and unredacted transaction ledger logs.

cTEE Mechanism Stack. This is speculative target architecture; no current cTEE implementation or no-plaintext-custody product claim is implied. The target user-facing posture is singular: Open Private Workspace. The user does not choose between cryptographic modes during ordinary work. The Hypervisor Daemon would realize that posture through a mechanism stack selected by policy, cost, risk, and workload fit:

1. Plaintext-Free Runtime Mounting: Workspaces are mounted as virtual crypt-volumes. The host file system cannot access file structures, directory names, or raw bytes. This protects workspace custody—not proprietary model weights. Defending weights requires a separate ModelWeightCustodyProfile: local/customer custody, provider API custody, accepted TEE/customer-cloud custody, cryptographic-operator partitioning, or an explicitly receipted provider-trust route. Any no-plaintext model-mount path must be verified under that weight-custody profile; it is not implied by workspace cTEE.

2. Candidate-Lattice Private Decoding: The target default high-throughput profile. The remote node generates structured candidate token trees (lattices) using public base weights; the final private selection and token assembly are resolved locally or within a secure boundary. The CandidateCoverageProfile declares candidate count, coverage assumptions, public-token overhead, and the expected selection-leakage surface for the protected task.

3. Counterfactual Lattice Execution: Used where zero online selection leakage is mandated. The node computes multiple counterfactual execution paths simultaneously, obfuscating the actual logical branch taken under the declared leakage profile; it is not a claim that all semantic inference, timing, or side-channel leakage disappears.

4. Cryptographic Operator Plane: FHE, MPC, garbled-circuit, ORAM, local/client guardian, browser/phone guardian, wallet.network, or enterprise-key-service mediated operators for private heads, private model scoring, policy checks, and private retrieval. This plane may use one authenticated access point or a threshold path when the workload requires stronger non-collusion assumptions.

5. Capability Exits & Declassification Gates: Managed channels that intercept action attempts at their declared control points. Actions must be packaged as capability-exit requests and passed through a local declassification gate before execution.

The daemon binds each protected offload to an ExecutionPrivacyPosture, a CustodyProof, and, when the agent is allowed to run beyond the immediate user session, an AutonomyLease. The PrivateAgencyTransform rewrites candidate-selection-reducible work into public/generic generation plus private selection, scoring, policy, or declassification, preserving the no-plaintext-custody invariant while keeping the rented node useful for high-throughput public kernels.

Privacy Posture Comparison.


Posture / Path	Trust Assumptions	Custody Model	Performance Characteristics	Primary Exposure Bounds
Plaintext Workspace	Absolute trust in host root and infrastructure provider.	Host retains full plaintext custody of memory and storage.	Full bare-metal hardware speed.	Total exposure. Host-root has full visibility into all keys, files, and variables.
cTEE Private Workspace	Zero trust in host for protected workspace plaintext under the declared leakage profile.	Host receives no protected plaintext by design; it computes over public trunks, redacted projections, encrypted refs, candidate lattices, and capability handles.	Near-native for public/generic trunks; extra cost depends on candidate overgeneration, private-head routing, and crypto-operator use.	Constrained by explicit leakage profiles, declassification gates, custody proofs, and deterrence metrics.
Cryptographic Operator Path	Mathematical hardness guarantees (FHE/MPC).	Zero plaintext custody. Mathematical guarantees independent of hardware.	High compute overhead; restricted to low-dimensional linear algebra (private heads, scores).	Bound by mathematical security parameter bounds (e.g., LWE hardness).
Confidential GPU / Hardware TEE Path	Hardware vendor trust (Intel, AMD, NVIDIA).	Hardware-enforced memory isolation from host OS.	High performance, near native CPU/GPU execution.	Vulnerable to side-channel analysis and hardware-level root-key exploits.
Provider API Path	Trust in third-party API provider (OpenAI, Anthropic).	Plaintext custody is transferred entirely to the API provider.	Zero local compute footprint; fast network transit.	Provider-readable plaintext visibility into sensitive context supplied to the API host.

4.1.1 Trigger conditions

Hypervisor Core, the Workflow Compositor, or the selected HarnessProfile MAY propose an offload when any of the following holds:

Capacity limit: Local hardware cannot satisfy the declared execution requirements (e.g., model snapshot exceeds VRAM, missing accelerator class).
Capability gap: The task requires a tool or dataset not available locally (e.g., enterprise data feed, specialized service, regulated connector).

4.1.2 The Hybrid Data Plane (Dual-Path I/O)

The Hypervisor Daemon selects the transport based on the topology of the agent work graph and the approved provider/session policy:

Remote path: The selected provider, harness, connector, or private- workspace contract declares its authenticated transport and the exact refs or context projection it may carry. Transport encryption protects transit; it does not by itself make the destination private. Plaintext exposure remains a property of the declared cTEE/private-workspace, TEE/confidential-compute, customer-controlled, redacted-only, or provider-trust posture.

Local path: Co-located runtimes may use shared memory, local sockets, or other zero-copy/IPC optimizations when supported. These are implementation choices beneath the same typed contracts and do not change authority, privacy, receipt, or admission semantics.

4.1.3 Session bootstrap: Routing and Route Selection

Hypervisor presents four user choices rather than exposing provider-market mechanics as the product model:

Run local on the user’s machine or HypervisorOS node.
Use my infrastructure through a connected provider account, customer cluster, bare-metal/SSH target, or enterprise environment.
Pick a cloud by selecting a specific provider or venue.
Let Hypervisor choose under explicit cost, custody, region, reliability, failover, and receipt constraints.

Under those choices are three placement sources: connected infrastructure billed to the user, managed capacity where IOI or a partner is provider-of-record, and optimized placement where Hypervisor compares, procures, fails over, reconciles, or aggregates routes. decentralized.cloud may supply resource-intelligence candidates to the optimized path, but it is neither mandatory nor the provider-account, VM lifecycle, credential, spend-authority, storage-custody, restore-truth, or execution owner.

A CloudResourceIntent or equivalent placement request produces evidence-bound CloudResourceCandidates, provider quotes, custody plans, failover plans, and spend estimates. Hypervisor selects a candidate into its own PlacementDecision. Provider credentials remain in a ProviderCredentialBinding under wallet.network or approved customer authority; agents receive scoped leases rather than raw keys. Provider lifecycle work executes through the appropriate adapter and emits ProviderOperationReceipts, SpendReceipts, snapshot/archive refs, and restore evidence admitted by Agentgres.

Direct and BYO adapters do not universally require the remote target to run a Hypervisor Daemon or hardware attestation. The adapter must preserve its real provider semantics and satisfy the declared readiness, authority, privacy, evidence, and receipt contract. A remote daemon handshake applies when the selected runtime profile actually includes a daemon-compatible node; ordinary SSH, cloud, storage, DePIN, or customer-provider adapters use their own conformance path.

The Handshake & Topology Negotiation

Once a route is selected, Hypervisor performs the readiness or handshake protocol appropriate to that adapter and runtime profile:

Security Verification: The Hypervisor Node verifies that the destination satisfies the declared posture before transmitting data or refs. Public work may run on ordinary provider lanes. Private workspace state requires cTEE/private-workspace constraints, hardware confidential compute, customer-controlled infrastructure, cryptographic private operators, or explicit provider-trust approval depending on policy.

Topology Negotiation: The runtime negotiates data and context boundaries. Simple steps use a task-scoped context slice. Goal-shaped or delegated work uses ContextCells, ContextLeases, and typed ContextHandoffs with explicit result, blocker, evidence, and continuation payloads. It does not rely on shared-memory CRDTs or copied agent chat as the durable merge contract.

The user retains control over the placement choice and can inspect the candidate evidence, selected PlacementDecision, fee basis, privacy posture, and receipts. Adapter-specific bootstrapping varies; the authority, evidence, and truth boundaries do not.

4.1.4 Typed Provider Handoff and Private-Workspace Capsules

IOI does not define one universal OffloadPacket. A placement decision selects an adapter and the narrow owner contract appropriate to the work:

Goal-shaped delegated work crosses a ContextHandoff carrying a TaskBriefPayload, then a HarnessInvocation; the generic result returns as a WorkResult and may propose an OutcomeDelta, with verifier and continuation refs. ImplementationResultPayload is only the software-work profile for files, patches, diffs, tests, and implementation summaries.
Tool, connector, and MCP work binds to a RuntimeToolContract or declared surface MCP contract and its primitive, authority, risk, privacy, budget, and receipt requirements.
Protected remote work uses a PrivateWorkspaceCapsule bound to an ExecutionPrivacyPosture, CustodyProof, leakage profile, model-weight custody posture, and, when offline autonomy is authorized, an expiring AutonomyLease.
Provider lifecycle work binds the ProviderAccount, ProviderCredentialBinding, RuntimeNode, PlacementDecision, and relevant snapshot, restore, spend, and provider-operation refs.

Every handoff is minimized to the context, artifacts, capabilities, and authority required by its declared contract. wallet.network root material, ambient provider credentials, and unbounded workspace state never become generic handoff payloads. Transport encryption protects transit; it does not upgrade the destination’s custody or privacy posture.

4.1.5 Provider Execution, Admission, and Reintegration

Before dispatch, Hypervisor evaluates adapter readiness, budget, privacy, custody, policy, and current authority. Provider mutations are performed by the daemon through the selected adapter under scoped credential and capability leases; agents do not receive raw provider secrets.

Provider-native ids, statuses, snapshots, bills, and success claims return as evidence. They become operational or restore truth only after the daemon and Agentgres validate and admit the applicable hashes, state roots, receipts, and owner contracts. ProviderOperationReceipt and SpendReceipt records cover successful and refused crossings; private work additionally carries the evidence required by its CustodyProof and selected VerifierPath.

A returned artifact, plan, model output, or staged effect is therefore pre-canonical. The receiving gate validates its signature and bindings, normalizes the observation, runs required deterministic checks, and either admits, rejects, or escalates it. Any effect materialized after a delay, replay, or branch merge is re-authorized against the current revocation epoch, grant expiry, and policy hash and mints new receipts. Failed verification cannot be repaired by silently reusing the old grant; it begins a new proposal or remains blocked.

Implementation status. Direct provider and BYO-provider lanes are mixed and adapter-specific. Private Workspace backed by cTEE, including its no-provider-trust mechanisms, remains speculative architecture; product surfaces must not present that posture as implemented without the required custody proof.

4.2 Session Accounting and Value Flow

A Hypervisor Session or WorkRun may consume local resources, customer-billed provider capacity, managed capacity, marketplace labor, connectors, storage, verification, or public settlement. The accounting contract follows the owner of each cost rather than imposing a universal state channel or packet format.

Work Credits are the product-wide usage and budget abstraction for managed autonomous work. They may meter or budget model calls, runtime time, provider operations, private managed execution, storage, Foundry jobs, marketplace invocations, and other managed costs. They are not necessarily a protocol token, payout asset, provider payment rail, or IOI L1 settlement asset.

For provider operations, budget discovery precedes mutation. wallet.network or the applicable local/domain authority approves the spend and credential use; the daemon executes the provider call; SpendReceipt and ProviderOperationReceipt records disclose the applicable cost, credential source, grant, and outcome; Agentgres admits the operational record. Customer-borne provider billing, IOI-managed billing, enterprise invoicing, subscriptions, prepaid balances, and marketplace escrow may coexist without changing that authority and truth ordering.

Payment, payout, and public settlement are separate rails. Local work-credit debits and routine provider accounting remain local/domain records. A future IOI L1 receives only selected public or economic commitments when escrow, rights, licensing, reputation, dispute, cross-domain finality, or another declared trigger requires it. No model call, tool call, Agentgres write, authority check, local receipt, or self-hosted action incurs a protocol toll merely because the substrate observed or proved it.

Implementation status. Fee-basis declarations and provider-resource metering exist in parts of the current runtime. Work Credits, marketplace fees, and token or BME settlement are planned or deferred, and IOI L1 has no current deployment. Exact billing, escrow, and settlement schemas remain with their product, wallet.network, marketplace, provider, and L1 owners.

4.3 AIIP: The Inter-Autonomous-System Protocol

AIIP is the Inter-Autonomous-System Protocol: IOI’s RPC-shaped, semantic, receipt-native interoperability protocol for bounded autonomous work and collaborative pursuit.

AIIP is not a lookup directory, a name-resolution service, a shared prompt bus, or a global room database. It moves delegated work, collaborative-pursuit updates, negotiated ontology and action profiles, authority leases, receipt commitments, delivery and acceptance state, settlement intents, reputation queries, dispute notices, and handoff finality across bounded execution domains: local microharnesses, installed workers, marketplace workers, outcome services, robot fleets, enterprise runtimes, and peer autonomous systems. Each domain retains its runtime, private context, and operational truth.

Short form:

AIIP moves autonomous work across systems. IOI settles what happened.

The ai:// identifier grammar may be used for manifests, worker packages, services, or system endpoints, but name resolution is only one input to AIIP. The protocol itself is the signed, sequenced, receipt-aware packet layer that lets bounded execution domains talk.

The layer boundary is:

Execution: local runtimes, microharnesses, workers, APIs, robots, VMs, tools, and enterprise systems.
Interop: AIIP packets, profiles, channels, semantic mappings, restricted views, authority refs, receipt obligations, and settlement intents.
Settlement: selected IOI L1 roots, rights, escrows, disputes, reputation, and handoff finality when public or economic trust requires it.

The chain does not execute ordinary cognition or collaboration. A signed packet makes a claim attributable and ordered; it does not make the claim correct or accepted.

AIIP does not grant execution authority. AIIP packets convey intentions, task contexts, receipt obligations, and structural payloads. While an AIIP packet may reference requested primitive capabilities, authority scopes, policy hashes, and settlement terms, the receiving bounded execution domain must validate those claims against its own policy, authority, and daemon gates. Authoritative execution permissions and decryption leases are never granted by the interop packet itself. Local or domain policy and the applicable authority provider authorize; the receiving daemon admits and enforces work, mediates or executes effects, emits receipts, and orchestrates replay; the receiving Agentgres domain admits durable operational state.

The same semantic protocol is used in different modes. Hypervisor may use AIIP semantics internally for local microharness routing over in-process calls, Unix sockets, local HTTP, gRPC, JSON-RPC, NATS, or a daemon bus. External handoffs use signed envelopes, authority leases, receipt obligations, payment or escrow terms, reputation updates, dispute windows, and mainnet commitments when consequential. Same semantic protocol, different transport and settlement mode.

The canonical AIIP object model distinguishes the transport binding from the work boundary. An AIIPProfile declares supported protocol features, transports, receipt obligations, settlement modes, authority planes, and payload classes. An AIIPChannel binds bounded execution domains with ordering, replay protection, schema version, privacy posture, lease refs, and dispute windows. A BoundedExecutionDomain declares its manifest, capabilities, policy root, authority requirements, receipt schemas, state boundary, runtime profile, settlement behavior, and supported AIIP profiles.

The field-level AIIPEnvelope in the common-envelope owner is the normative superset. No application or protocol profile may publish a reduced competing envelope. It preserves packet and payload identity while binding:

message type, sender, recipient, channel, schema version, sequence-or-nonce, timestamp, and signature;
idempotency, causation, and correlation refs;
local, installed-worker, marketplace-worker, outcome-service, autonomous-system, collaborative-pursuit, and enterprise profiles;
policy and authority refs, MultiPartyCollaboration and OutcomeRoom refs, ontology, semantic-mapping, and action-schema profiles, restricted views, and verifier challenges;
payload hash and ref, receipt obligations, verifier and acceptor refs, settlement terms, and assurance stage; and
external-effect recovery class.

Payload bodies may remain private, encrypted, redacted, or available only to authorized dispute participants. Public settlement anchors commitments and roots rather than raw operational context.

AIIP preserves the assurance ladder rather than collapsing it into a verified flag:

receipt / attestation $\rightarrow$ evidence bundle $\rightarrow$ verification $\rightarrow$ acceptance $\rightarrow$ adjudication $\rightarrow$ settlement

A receipt is an authenticated statement about its declared boundary fact. An evidence bundle supports a claim. Verification means a named verifier applied a named rule and version. Acceptance belongs to the user, customer, domain, or counterparty. Adjudication resolves a challenge under policy. Settlement moves rights or value under an accepted or adjudicated claim. Later stages do not arise merely because an earlier receipt exists.

Every AIIP task or action profile that can create an external effect declares one recovery class: replayable, checkpointable, compensatable, reconciliation_required, or non_retryable. Restoring a channel, worker, VM, or environment does not prove that the business or physical outcome was restored. A timeout after dispatch follows the declared reconciliation policy; an unknown effect is not blindly replayed, and compensation is a separately authorized action with its own receipts.

AIIP packet classes. The common envelope carries typed packet bodies rather than undifferentiated bytes:


Packet	Meaning	Required posture
CapabilityDiscovery	Discover a system, Worker, module, resource, or capability.	Signed profile and eligibility refs.
TaskOffer / TaskAcceptance / Handoff	Offer, accept, counteroffer, or transfer bounded work.	Constraints, quote or SLA, authority, receipts, and settlement posture.
SemanticProfileNegotiation	Negotiate ontology and action-schema versions, crosswalks or adapters, mapping loss or ambiguity, policy-bound views, and verifier obligations.	Explicit, challengeable mapping decision.
OutcomeRoomDiscovery	Query or publish a signed public or permissioned objective, category, semantic and capability requirements, eligibility, privacy, budget, verifier, settlement, and admission endpoint.	No raw private room context.
RoomParticipation	Request, admit, update, suspend, retire, or revoke a participant lease and export permitted participant state.	Declared hosted or federated admission owner.
FrontierUpdate / WorkClaim	Propose or admit frontier state, or claim, renew, release, expire, reassign, or quarantine bounded work.	Context, authority, resource, data, tool, and budget lease refs.
AttemptFinding	Publish positive, negative, inconclusive, invalid, exploit-found, or superseded attempt and finding refs.	Method, lineage, evidence, cost, reproduction, license, and disclosure posture.
VerifierChallenge / RoomAdmission	Challenge a metric, rule, verifier, evidence, mapping, eligibility, independence, or result; then propose, admit, reject, supersede, or reconcile a WorkResult or OutcomeDelta.	Versioned rules, affected work, and named admission path.
AuthorityQuery / AuthorityGrant	Query or carry a bounded authority lease reference.	Scope, subject, time, budget, policy, and receiver-side validation.
ReceiptCommitment	Commit to declared work-boundary facts.	Receipt root or inclusion proof for later evidence and challenge.
DeliveryUpdate / AcceptanceDecision	Record milestone, partial, final, revision, cancellation, acceptance, rejection, or dispute-open state.	Artifacts, evidence, criteria, and receipt roots.
SettlementIntent / Dispute / DisputeResolution / ReputationQuery	Request economic or reputation handling, challenge a claim, resolve a dispute, or query contextual reputation.	Declared policy, evidence, window, and remedy.

The Collaborative Pursuit profile applies these packet classes to an OutcomeRoom above bounded GoalRuns. hosted_admission names one governed sequencing and admission domain and is the first conformance target. federated_admission names a versioned ordering, merge, quorum or adjudication, conflict, failover, and recovery policy and is opt-in. Discovery grants no membership, authority, budget, or data access. Admission creates a RoomParticipantLease only after the named path accepts the typed request and evidence. Exit releases or reassigns claims and can carry a signed, policy-filtered ParticipantStateBundle. Hosted and federated rooms use the same discovery, request, lease, exit, and export contracts; they differ in the declared admission owner and watermark.

Participant packets are hostile input. Provenance, taint, license and export, affiliation, independence, and trust labels survive transport. Room admission must enforce rate, resource, spend, context, authority, privacy, quarantine, anti-Sybil, anti-collusion, backpressure, and fair-allocation policy. Messages, artifacts, mappings, evaluator suggestions, and consensus do not automatically enter durable memory, ontology, routing policy, authority, production state, or settlement.

4.3.1 The AIIP URI Scheme

ai://<authority>/<agent_id>/<version>[?query]

Authority: did:ioi:... (public key, DAO address, or governance identity).
Agent ID: human-readable label (e.g., personal-finance).
Version: immutable release identifier (e.g., sha256:... or semantic version mapped to a content hash).

4.3.2 Resolution Result

Resolving an AIIP URI returns a structured Resolution Result:

A content-addressed Agent Manifest (signed by authority).
An optional Local Installation Handle (if the package is already present in the local package inventory and indexed by Agent Wiki / ioi-memory).
Zero or more candidate Endpoints (p2p, https, or driver-specific transports), ordered by trust policy and locality.
A declared Primitive Capabilities and Authority Scopes requirement for user review.
Optional MoW routing metadata, when present: sparse_worker_category, benchmark_profile_refs, current leaderboard position or reputation root reference, routing_eligibility_status, contribution terms, and training_lineage_ref.

4.3.3 Resolution Logic: Split-Horizon Discovery

When the runtime encounters an AIIP URI, it follows a deterministic waterfall to prevent the “DNS Leak” problem where looking up an agent reveals user intent:
Step 1: Local Install Cache (“Hosts File”)

The runtime checks local package inventory, Agent Wiki / ioi-memory indexes, and Agentgres admission refs.
If installed, it returns the local package handle (content hash / bundle ID) and skips network lookup.
Latency: ~0ms. Privacy: Maximal.

Step 2: Pinned Registries (“Known Good”)

The Runtime checks a locally pinned list of trusted registries or providers (e.g., enterprise catalogs, user favorites) via encrypted transport.
If found, it returns the manifest and endpoints from the pinned source.
Latency: Low. Trust: Explicit.

Step 3: Network Discovery (“Dark Pool”)

If not found locally, the Runtime may use privacy-preserving discovery methods such as Oblivious Resolution (e.g., PIR) to query registry or catalog endpoints without broadcasting the user’s full intent.
Providers can operate in Dark Pool Mode, where capacity is not broadcast globally.

The Tower of Babel Solution: Federated Semantic Negotiation

To ensure that a “Downloaded Accountant” can speak to a “Downloaded Bank”, each domain declares namespaced ontology and action-schema profiles; IOI does not assume one global schema registry. AIIP negotiates compatible versions, explicit OntologyCrosswalk or adapter refs, lossy or unmapped fields, restricted views, and verifier obligations. A challengeable SemanticMappingDecision binds the mapping actually applied. The Hypervisor Daemon validates the resolved typed action contract at admission, while local or domain governance and the applicable authority provider authorize any monetary or other consequential power.

Schema Enforcement: A Worker Manifest MUST declare its I/O schemas (e.g., input: std:finance:invoice_v1, output: std:finance:tax_report_v2).
Handshake: Before work or value moves, the receiving domain verifies exact compatibility or admits an explicit mapping decision with its loss, ambiguity, policy-bound view, and verifier posture. This prevents “semantic mismatch” errors without silently making either domain’s schema universal.

4.3.4 The Worker Manifest

The Worker Manifest is the declarative contract for execution. It specifies what the agent is, what it requires, and where it can run. These specifications make no vertical-specific architectural assumptions: domain schemas are client-defined ontology packages registered on aiagent.xyz, not hardcoded into the core engine.

A Worker Manifest MAY additionally declare MoW routing metadata: sparse_worker_category, benchmark_profile_refs, evaluation_rubric_ref, routing_eligibility_status, contribution_policy, training_lineage_ref, and supported_execution_axes.

Optional MoW routing fields:

{

“sparse_worker_category”: “std:code:rust_security_audit.v1”,

"benchmark_profile_refs": [
    "benchmark://ioi/categories/rust_security_audit/v1"

],

“evaluation_rubric_ref”: “rubric://ioi/rust_security_audit/v1”,

“routing_eligibility_status”: “eligible”,

“training_lineage”: {

"training_run_ref": "run://...",
    "dataset_commitment": "hash://...",
    "evaluation_receipt_root": "hash://..."
~~\},

“contribution_policy_ref”: “policy://contribution/...”,

“license_ref”: “license://...”

}

Normative Security Rule:

The runtime MUST NOT auto-execute code obtained via resolution. Resolution names intelligence; it does not grant authority. A resolved worker becomes a Web4 actor only after local/domain policy and the applicable authority provider grant bounded, policy-bound execution authority. wallet.network is mandatory for portable delegated authority and designated high-risk external effects. The installation path MUST present an and permission prompt (displaying requested prim:* and scope:* capabilities, policy defaults, and authority identity), and execution MUST require explicit user approval (or an enterprise policy decision).

4.3.5 Typed AIIP Work and Outcome Contract

An AIIP handoff carries or references the typed intent, TaskBriefPayload, constraints, acceptance criteria, verifier path, authority leases, receipt obligations, and settlement posture required by the receiving bounded execution domain. This lets the receiver validate a proposed outcome against structured terms rather than relying solely on natural language.

The contract also declares the input and output ontology and action-schema profiles; compatible versions; crosswalk or adapter refs; mapping loss, ambiguity, and restricted-view posture; idempotency; recovery class; contribution and artifact-rights terms; and the receiving domain’s acceptance and admission path. Semantic negotiation never grants execution authority and never silently flattens local ontology definitions.

The generic result carrier is WorkResult. It binds the applicable GoalRun, room, claim, attempt, invocation, method and lineage, result profile, positive or negative outcome class, uncertainty, evidence, artifacts, cost, authority and policy, verifier, rights, reproduction, acceptance, challenge, and supersession state. A WorkResult may propose one or more OutcomeDeltas; the receiving host or federation policy separately admits, rejects, supersedes, rolls back, or course-corrects the affected frontier, finding, ontology, state, capability, policy, route prior, or service outcome. ImplementationResultPayload is only the software profile inside WorkResult and must not force research, ontology, incident, service, physical-mission, review, or evaluation outcomes through file/diff/test fields.

The domain contract may include:

Discrete Fields: max_price, deadline_epoch, min_confidence_score.
Enums: allowed_providers, outcome_type.
Semantic bindings: ontology versions, action contracts, crosswalks, restricted views, and mapping-verifier requirements.
Acceptance and adjudication: a versioned structured rubric, covered evidence, named verifier or acceptor, abstention behavior, affected attempts, challenge path, and appeal path.
Optimization and stopping: declared tie-breakers, budget and deadline stops, marginal-value policy, and prohibited fallbacks.
Effect recovery: exactly one of replayable, checkpointable, compensatable, reconciliation_required, or non_retryable, plus the reconciliation or compensation contract where applicable.

Rubric binding: A contract claiming automated acceptance or remedy must bind a versioned evaluation rubric, covered evidence, verifier, abstention behavior, and appeal path. A claim that cannot be resolved by its declared objective or semantic verifier escalates to the contract’s human, institutional, or legal path. This synthesis does not define fixed fast/slow tiers or mandatory bond amounts. A receipt that a verifier ran does not by itself imply acceptance, adjudication, settlement, or correctness beyond the verifier’s declared rule and evidence coverage.

4.4 Infrastructure Integrations and Driver Modules

IOI does not compete with commodity hardware networks; it integrates them. Hypervisor exposes direct provider integrations for local machines, customer clouds, hyperscalers, confidential-compute lanes, DePIN compute, decentralized storage, GPU markets, enterprise clusters, and user-specified provider routes while maintaining a unified authority, receipt, and verification layer. Provider catalogs and route marketplaces are optional surfaces in this path, not mandatory gateways.

The canonical provider-routing objects are:

ProviderAccount: the vendor-neutral record for a connected local, customer-cloud, hyperscaler, Kubernetes, DePIN, GPU, storage, confidential-compute, enterprise, bare-metal/SSH, or user-specified provider. Vendor names belong in replaceable adapters, not the core object model.
ProviderCredentialBinding: the wallet.network- or customer-authority-governed binding for provider credentials. Agents and workers receive scoped leases or brokered effects rather than raw keys.
RuntimeNode: the admitted node record for a local, cloud, GPU, DePIN, customer, HypervisorOS, TEE, cluster, or bare-metal runtime. It binds the actual adapter/provider identity, posture, receipts, and Agentgres refs without flattening provider-native semantics.
Provider adapter: the daemon/provider boundary that turns an SSH, cloud, cluster, DePIN, storage, or other provider API into receipted lifecycle actions. It may create, start, stop, inspect, archive, restore, expose ports, issue short-lived access leases, or collect logs only after the applicable authority and policy gates.
ClassicalInfraPrimitive: a traditional infrastructure object such as a VM, container, microVM, WASM workload, image, volume, network, egress policy, snapshot, backup, restore point, node pool, GPU pool, quota, lease, health check, log stream, cost record, provider connector, or migration plan. It may be managed by Hypervisor, but it does not become runtime truth by itself.
HypervisorWorkloadPrimitive: the Hypervisor projection over infrastructure lifecycle state for VMs, containers, microVMs, WASM workloads, images, volumes, networks, snapshots, backups, restore points, GPU pools, node pools, migration plans, or provider connectors. Consequential lifecycle changes link to authority refs, Agentgres operation refs, and receipts.
CloudResourceCandidate: an expiring, evidence-bound resource candidate from connected inventory, managed capacity, decentralized.cloud, a direct adapter, DePIN market, storage network, cloud GPU provider, hyperscaler, cluster, or user route. A candidate is not authority, execution truth, storage truth, privacy proof, or restore truth.
PlacementDecision: the Hypervisor-owned selection record that binds workload requirements, selected candidate, placement source, resource class, privacy and storage posture, budget, jurisdiction, provider-trust model, attestation requirements, secret-release policy, authority refs, risk labels, fee basis, and expected receipts.
WorkspacePersistenceProfile: the workspace policy for ephemeral, session, zero-to-idle, persistent, or archive-only operation. It declares idle behavior, compute shutdown, provider lease closure, archive/checkpoint requirements, allowed storage backends, retrieval checks, restore policy, and receipts.
EnvironmentWarmupProfile: the prebuild, dependency-cache, model-cache, index-warmup, image-pull, or warm-pool profile used to reduce startup latency. It is a performance projection, not canonical workspace truth.
ImageRef, VolumeRef, SnapshotRef, RestoreRef, MigrationPlan, and GpuPool: Hypervisor-visible resource identities used to operate images, volumes, snapshots, migrations, and accelerator pools across providers. Their availability, cost, or provider health is evidence; Agentgres refs and receipts define meaning when they affect canonical work.
ProviderOperationReceipt and SpendReceipt: records of what lifecycle operation happened or failed, who owns provider cost, and how spend was estimated, reserved, reconciled, or closed. A RoutingDecisionReceipt is reserved for optimized placement or paid procurement/routing value, not ordinary provider-account use.
HypervisorStoragePosture: the Hypervisor projection over storage-backend availability, retention, replication, privacy class, and Agentgres artifact refs. It does not make storage backends the authority over payload meaning or restore validity.
ProviderTrustBoundary: the boundary crossed when sensitive plaintext, model weights, credentials, or protected workspace state would be exposed to a provider, model API, cloud VM, or DePIN node. Crossing it requires an explicit execution privacy posture, policy decision, and receipt; contractual no-training terms alone do not make the route private.
NodeEnforcementProfile: the HypervisorOS or provider-node profile for daemon gates, sandboxing, executable policy, egress policy, datawall/leakage detection, log/export redaction, cTEE checks, and optional hardware-attestation hooks.

Connectors should declare not only transport and tool interfaces, but also ConnectorMappings into canonical domain objects, authority scopes, redaction policies, evidence requirements, and policy-bound data views.

Hyperscale Integrations (AWS / GCP / Azure): Hypervisor may deploy directly into customer-owned or provider-hosted confidential compute lanes and ordinary cloud VMs. The user connects a ProviderAccount and ProviderCredentialBinding, using Hypervisor for policy, authority handoff, lifecycle, receipts, restore, and verification overlay without exposing raw cloud credentials to workers.
DePIN and GPU Integrations (Akash / Render / Gensyn / GPU markets): The user selects provider endpoints for cost-optimized or permissionless workloads. Hypervisor handles provider posture, session bootstrap, payment authorization, receipts, and cTEE/private workspace constraints when protected state is involved.
Storage Integrations (Filecoin / CAS / S3 / object stores): Storage backends hold encrypted payload bytes, archives, screenshots, datasets, packages, and delivery bundles. Agentgres ArtifactRefs and PayloadRefs define meaning, lifecycle, authority, restore validity, and receipt linkage.
Private Integrations (Local): Enterprise users route workloads to their own internal hardware.

Provider truth boundary. Provider APIs, cloud consoles, DePIN leases, logs, ports, service status, task status, and lifecycle signals are evidence about an environment, not canonical restore truth by themselves. Hypervisor manages sessions, environments, and providers; the Hypervisor Daemon executes lifecycle operations; applicable local/domain governance and wallet.network authorize as required, with wallet.network mandatory for portable delegated authority, secret release, decryption, spend, declassification, or high-risk approval; and Agentgres records admitted state roots, receipts, archive refs, restore refs, and repair evidence. Encrypted provider blobs are restore material, not restore authority.

Architectural Result: IOI functions as the Intelligence Orchestration Layer that sits above physical infrastructure networks. It can upgrade commodity hardware into governed, receipt-producing agentic nodes when the selected execution posture supports the workload. The integration model does not make every provider reliable or private by assertion; it routes workloads onto user-selected infrastructure under declared policy, evidence, privacy posture, authority, and receipt obligations.

4.5 Artifact Resolution & On-Demand Provisioning

AI agents frequently fail not because of flawed logic, but because of environmental drift- conflicting Python packages, incompatible CUDA versions, or missing system dependencies. To solve this, IOI adopts a strict "Wrapped Asset" model. Agents are not loose scripts; they are self-contained executable assets defined entirely by a cryptographic Worker Manifest.

This declarative asset model is the foundation of Zero-Idle Infrastructure. Developers do not need to host expensive, always-on API servers. Agents, service packages, manifests, sealed archives, and payload refs can exist as dormant, content-addressed artifacts on storage backends such as Filecoin, CAS/IPFS, object stores, or CDNs. Proprietary model weights follow a separate ModelWeightCustodyProfile; encrypted storage does not make them safe to mount as provider-readable plaintext. If a user's Hypervisor Node lacks the precise computational resources (e.g., VRAM) to run the manifest, or if the manifest requires a customer-controlled, hardware-confidential, remote-API, or explicitly provider-trust lane for proprietary model IP, Hypervisor Core proposes a route to a local, cloud, customer, or DePIN provider. The daemon, wallet.network authority path, and provider integration then handle on-demand provisioning, spinning up an exact, dependency-matched environment when policy allows.

ai:// resolution may return worker manifests, service manifests, runtime profiles, install rights, license refs, archive refs, data recipe refs, benchmark refs, contribution policy refs, and domain refs. Resolution does not imply that all referenced state lives in one product database. The resolver returns explicit cross-domain references.

aiagent.xyz worker initialization flow:

user selects worker

-> resolve WorkerManifest and version

-> check install/license right

-> inspect runtime requirements

-> select persistence profile

-> quote compute/storage/subscription terms

-> request wallet.network authority grants

-> create ManagedWorkerInstance in aiagent.xyz Agentgres domain

-> assign daemon-compatible runtime node or zero-to-idle policy

-> initialize hot state and optional sealed archive refs

-> expose web/API/Hypervisor/workflow invocation surfaces

-> emit install, runtime, authority, and initialization receipts

4.5.1 The Provisioning Lifecycle

Every routed provider execution is governed by a declared Private-Execution Evidence Profile (Section 4.1). The profile specifies the substrate, threat model, admissible leakage bounds, required attestations or proofs, and the receipt obligations that must be satisfied before reintegration or settlement. Provider execution must declare its containment lane: container, namespace, VM, microVM, WASM workload, TEE/confidential compute, customer-controlled environment, cTEE/private-workspace split path, or provider-trust route. A provider-root plaintext lane is never silently private. When a provider environment accepts a routed workload, it executes the following on-demand sequence:

Strict Dependency Resolution: The provider runtime or Hypervisor Daemon parses the Worker Manifest's dependency tree to identify exact version requirements (e.g., requires: python-3.11, requires: vLLM-0.4.2, model: llama-3-70b-quantized).
Authenticated Fetch:

- Public Artifacts: Base models, system libraries, and standard tools are fetched from the IOI Public Cache (a pinned IPFS cluster or high-speed CDN) using verifiable content addressing (CIDs). These are pure payload bytes, not Agentgres state.
- Proprietary IP (The Developer's Asset): If the manifest requires custom, closed-source model weights, the route must satisfy the declared ModelWeightCustodyProfile: local or customer-controlled custody, accepted TEE/confidential-compute mount, remote-API execution, or explicit provider-trust disclosure. A rented root-owned node must not receive those weights as plaintext under the cTEE workspace claim.
- User Context (Private Data): Task-scoped context is fetched as encrypted refs, redacted projections, cTEE private-workspace handles, cryptographic operator inputs, or explicitly declassified plaintext according to the approved execution posture.

Sandbox Initialization (Substrate-Specific): The runtime provisions the declared execution substrate. For TEE-backed workloads, a measured microVM, confidential VM, or enclave may decrypt protected assets in memory under a vendor-rooted attestation model. For FHE-backed workloads, selected computations may run over encrypted inputs without decryption. For MPC workloads, secret shares may be distributed across participating executors. For ZK-proven or proof-VM workloads, the provider returns a proof that a committed program or model step was executed according to the declared circuit, VM, or verifier. In every case, exposure bounds are determined by the declared substrate threat model and bound into the receipt rather than asserted absolutely.
Integrity Lock: The provider daemon, verifier, or configured authority profile computes the Merkle root of the loaded execution state. The model_or_program_hash and execution_plan_hash are bound to the applicable CustodyProof, proof refs, and receipt bundle. Depending on the action class, this may prove only that a particular runtime image was attested, or it may prove a stronger bounded computation claim through ZK, MPC, deterministic replay, or hybrid evidence.
Session Erasure: Upon generating the output commitments and required custody/proof receipts, the provider must emit evidence that the session was closed and any cached context was deleted or rendered cryptographically inaccessible according to the substrate’s erasure model (e.g., teardown attestations, key-erasure commitments, MPC transcript closure, or output-only commitments).

4.5.2 Orchestration: On-Demand Hydration vs. Hot Pools

Because IOI relies on declarative manifests, the protocol does not force developers or providers into a single infrastructure paradigm. Instead, IOI operates as a highly scalable orchestration engine that routes intent based on the workload's required latency.

When configuring a service in sas.xyz, the builder specifies its readiness posture. Cold services are hydrated on demand; the network treats the user's transaction as a trigger to execute the hydration lifecycle. Because users are conditioned to accept slight initialization times for high-value asynchronous deliverables, this friction is negligible, and it optimizes for zero-idle developer economics. Conversely, Hot services are routed directly to pre-warmed runtime capacity maintained by the provider. This bypasses the hydration phase entirely, optimizing for instant interaction and Web2-style API latency.

4.6 The Workload Adapter & Network Virtualization

Just as an operating system requires drivers to interact with physical hardware, the Hypervisor Daemon requires mediated adapters to interact with digital infrastructure (SaaS APIs, blockchains, LLMs). IOI fulfills this via Network Virtualization and the Workload Adapter.

Legacy platforms rely on centralized "Universal Connectors" or handing raw API keys to anonymous bots, creating massive security liabilities. IOI introduces a decentralized standard for connecting Sovereign Agents to external services by treating the Model Context Protocol (MCP) and HTTP traffic as raw transport layers that require a Security Envelope.

This architecture functions as an automated KYA Check (Know Your Agent): instead of handing raw secrets to an agent, the daemon installs a managed capability boundary. It enforces brokered secret execution: the AI model generates the parameters of a request (e.g., "Refund $50"), but wallet.network or applicable local/domain governance authorizes the scoped power, and the Hypervisor Daemon admits, executes, or brokers the capability under policy. The model does not receive durable credential material; any exceptional short-lived credential lease must be explicitly policy-bound, operation-scoped, and receipted.

4.6.1 The Mechanism: The Capability Execution Engine

The Hypervisor Daemon acts as a capability broker for its own workloads. Legacy platforms attempt to secure agents by injecting API keys into environment variables or local proxies. IOI fundamentally rejects this model.

The protocol enforces a non-negotiable security invariant: The agent requests effects**, not** keys**.**

To achieve this without breaking standard tools (e.g., standard MCP servers or CLI scripts), the Hypervisor Daemon may use a policy-bound capability proxy backed by wallet.network. Execution is routed through one of two distinct operational modes:

Capability Execution (Remote Request → Local Execution). The agent requests an action; wallet.network Authority Core performs the action locally using its protected secrets; wallet.network returns the result. The secret never enters the agent's runtime space.
Attested Remote Execution. For high-scalability workloads running on external hardware, wallet.network approves an action and may issue an operation-scoped credential lease only to an accepted TEE, confidential-compute target, customer-controlled boundary, or other policy-approved execution target via an authenticated key agreement.

When a wrapped tool is executed, the Hypervisor Daemon and wallet.network capability path perform the following atomic sequence:

1. Virtualization & Intent Translation:

The Hypervisor Daemon may spin up an ephemeral HTTP proxy on localhost. The agent is spawned with modified environment variables (e.g., OPENAI_BASE_URL pointing to the proxy) and dummy credentials. When the agent attempts a network request, the proxy intercepts it and translates it into a declared RuntimeToolContract invocation and ActionProposal bound to the agent’s active CapabilityLease.

2. Policy Evaluation:

The request follows the applicable authority path. For portable delegated, secret-bearing, spend-bearing, or external effects, wallet.network evaluates the ActionProposal against the active Policy Envelope. It verifies that the requested capability (e.g., stripe:refund) and its parameters (e.g., $50) are mathematically within the bounds of the agent’s current CapabilityLease and referenced AuthorityGrant.

3. The Out-of-Band (OOB) Step-Up Gate:

If the request violates the autonomous policy limits (e.g., interacting with a new smart contract, or exceeding a daily spend cap), wallet.network strictly enforces an Out-of-Band Step-Up.

Execution is paused.
An on-screen prompt on the active host is considered insufficient (to mitigate local malware). wallet.network pushes a cryptographic signing request to a secondary device (e.g., the user's Mobile Phone via Bluetooth FIDO2/Passkey).
If approved, wallet.network mints a one-time ApprovalToken to override the policy block.

4. Execution (The Air-Gap):

Assuming policy passes or an ApprovalToken is provided, wallet.network executes the capability. In the default Capability Execution, wallet.network internally signs the transaction or makes the OAuth API call using the root credential stored in its encrypted XChaCha20-Poly1305 database.

5. Receipt Emission (ActionResult):

The proxy returns the sanitized HTTP response (the result of the action) back to the agent tool. Simultaneously, wallet.network generates a typed ToolExecutionReceipt and normalized result. These bind the original proposal, applied policy and authority decision, execution outcome, and evidence refs into the admitted audit trail.

Result: The agent possesses Functional Authority (it can complete the job) but zero Credential Authority (it cannot steal the keys, exfiltrate the session, or bypass the constraints). If the agent is fully compromised or "jailbroken," the maximum potential authorized surface is bounded to the capabilities explicitly granted in the CapabilityLease; the real residual risk remains that of the target system, credential, policy, adapter, and verifier coverage.

4.6.2 Provider Swapping (The Local Routing Table)

Because the runtime routing layer controls model, tool, and endpoint bindings, it can dynamically reroute model or harness backends without modifying the agent code.

Model Swapping: An agent hardcoded for OpenAI can be routed to an Anthropic endpoint by the Shim.
Local Fallback: Cloud-native tools can be forced to use local LLMs (e.g., Ollama) by redirecting their API calls to a local or customer-controlled inference server, preserving a local/private execution posture when policy requires it.

4.6.3 Kinetic Drivers & Browser Subsystem

While many tools run as standard binaries or isolated processes via the Model Context Protocol (MCP) Manager, the Hypervisor Daemon exposes specialized Native Drivers comprising two distinct subsystems to handle OS and Web interactions safely.

Kinetic Drivers (OS-Level)

For desktop applications (e.g., Excel, Photoshop), raw screen pixels are insufficient for reliable agency. The IOI Core implements Application Lenses (LiDAR)- drivers that project the raw OS Accessibility Tree into a simplified, token-efficient XML representation.

Div-Soup Filtering: Lenses (e.g., universal_heuristic_v4, react_semantic) actively prune non-interactive elements, empty containers, and invisible nodes to reduce context window usage.
Semantic Tagging & SoM: Visual elements are tagged with two distinct identifiers:

1. Stable Semantic IDs: Derived deterministically from content, role, and deep ancestry hashing, allowing the agent to reference elements across shifting layouts.
2. Ephemeral SoM IDs: Numeric "Set-of-Marks" IDs injected per-frame during the Visual Grounding phase, allowing Vision-Language Models (VLMs) to intuitively target spatial coordinates.

The kernel utilizes native OS handles (via enigo) to inject input (gui::click, gui::type) based on these semantic targets. These actions interact with the Atomic Vision-Action Lock, which evaluates the perceptual state of the UI at the exact moment of execution to prevent "Visual Drift" (TOCTOU attacks).

The Managed Browser Subsystem (Web-Level)

Agents DO NOT directly control the user’s personal, daily-driver browser (e.g., Chrome/Safari). Doing so would expose the user's logged-in sessions (Gmail, Banking) to implicit exfiltration and unintended cross-contamination.

Instead, the daemon spawns a Hermetic Chromium Instance managed by the CDP (Chrome DevTools Protocol) Driver.

Hermeticity: The browser initializes with a clean profile- zero cookies, zero history, and disabled extensions. It can operate in strict headless mode or headed mode (for active user monitoring).
Structural Interaction: Instead of relying purely on computer vision, the browser driver targets DOM and Backend Node IDs (e.g., browser::click_selector). This makes the agent highly resilient to visual drift, rendering lag, or popup overlays that would otherwise confuse a pure-vision model.
Intent-Level Network Pinning: Rather than attempting brittle packet-level interception of the browser's internal network stack, the Hypervisor Daemon evaluates the agent's intent. All tool invocations (e.g., browser::navigate, ucp::checkout) are checked by the Policy Engine. The destination URLs and arguments are validated against the prim:net.request primitive and applicable scope:domain_allowlist constraints before the driver executes the command.
Secret Isolation (Roadmap): The framework's SecretInjection primitives (backed by wallet.network vault custody) lay the groundwork for injecting bounded session tokens directly into the hermetic browser instance, allowing agents to adopt specific user privileges without ever exposing raw credentials to the LLM.

4.6.4 Customer Boundary Runtime (BYO-Auth)

For high-security "AI as a Service" workflows, enterprises deploy Customer Boundary Runtimes.

Role: These are customer-controlled Hypervisor environments that run managed workloads inside the enterprise boundary.
Mechanism: An enterprise spins up a governed runtime inside its VPC. Corporate credentials remain under wallet.network, enterprise key-service, or customer IAM control; agents receive scoped capability exits and short-lived leases rather than raw API keys.
Security: The data never leaves the corporate VPC. The agents "visit" the customer-boundary runtime via a governed session, drive internal APIs through mediated capability exits, and return only the structured result and receipts permitted by policy.

4.6.5 The UCP Commerce Wrapper

As the industry standardizes agent-to-merchant communication via the Universal Commerce Protocol (UCP), IOI provides the UCP Wrapper. This transforms raw commerce intent into safe, verifiable transactions.

Hardware-Isolated Payment: The Wrapper negotiates the shopping cart, but wallet.network or a configured authority profile injects the payment token (e.g., Stripe/Google Pay) only at the moment of egress via SecureEgress.
Semantic Budgeting: The daemon effect boundary inspects UCP payloads. A policy like allow spend < $50 on "groceries" is enforced deterministically against the UCP schema.
Liability Binding: Every purchase generates a receipt binding the Merchant ID, Total Spend, and Worker Logic Hash, creating an auditable trail for chargebacks or insurance claims.

4.7 Payment Brokers and Work-Credit Liquidity

IOI supports optional payment brokers, RFQ/payment adapters, escrow providers, product billing/entitlement ledgers, and work-credit issuers that provide just-in-time liquidity or billing abstraction. They can bridge fiat-denominated product demand and token, stablecoin, invoice, credit, or domain-local settlement so mainstream users do not need to manage every payment rail directly.

While providers supply compute, storage, GPU, bandwidth, or execution environments, payment brokers may supply Just-In-Time (JIT) liquidity, prepaid work credits, or payment settlement services. They are not route authorities, runtime authorities, or wallet authorities.

4.7.1 Payment Broker Responsibilities

Prefunded Session Activation: Some providers or marketplaces may require prepaid capacity, collateral, or a payment ticket before a session starts. A payment broker can maintain prefunded balances or liquidity escrows and issue Payment Tickets to providers under wallet.network-approved budgets. This is optional; direct customer cloud accounts, local nodes, enterprise invoices, DePIN leases, prepaid credits, or local/domain settlement may avoid public-chain activation entirely.
Settlement & Currency Abstraction: Payment brokers may pay metered work-credit, stablecoin, card, invoice, or marketplace obligations on behalf of a user or organization. wallet.network still authorizes the spend, budget, grant, revocation epoch, and receipt linkage.
Economic Privacy: A broker or pooled work-credit ledger may reduce direct payer-to-workload linkage for some venues. This is an economic privacy feature, not a private-compute proof. It does not replace cTEE, TEE/confidential compute, redaction, or wallet.network declassification policy.

4.7.2 Security Invariant: Payment vs. Execution Authority

The payment-broker architecture enforces a strict separation of powers to prevent billing rails from becoming runtime or wallet authorities. A broker may hold limited Payment Authority under a grant, but it has Zero Executive Authority over the user’s work.

Encryption Barrier: The broker CANNOT decrypt the User's Context Slice or see the agent’s private inputs.
Integrity Barrier: The broker CANNOT alter the Agent's ActionRequest or Policy Envelope. Any tamper attempt invalidates the signature chain, causing the Provider to reject the job.
Payment Barrier: The broker cannot unilaterally redefine delivery, verification, acceptance, dispute, refund, or payout. A hold, denial, adjustment, or release follows the implemented governing contract and its admitted evidence, authority, revocation, and dispute state; the presence of a receipt alone does not compel payout.

4.7.3 Payment Broker Business Models

Payment brokers may be first-party product billing systems, enterprise billing integrations, marketplace escrow services, or permissionless work-credit brokers. Their legitimate revenue follows value they actually provide:

Revenue: A broker may earn a disclosed payment, working-capital, reconciliation, procurement, foreign-exchange, provider-of-record, or settlement-service fee when it performs that work. IOI’s durable margin comes from the conductor, verified route savings, governed runtime, memory continuity, private deployment, reserved capacity, evidence/assurance, distribution, and successful outcome coordination, not opaque inference resale or pooled named-user subscriptions.

4.8 Outcome Rooms, Multi-Worker DAGs, and Mixture of Workers

Typed Role Topologies and Bounded Delegation

An OutcomeRoom with a CollaborativeWorkGraph is the durable shared-pursuit container above one or more bounded GoalRuns. It owns the shared objective, participants, resource and capability offers, frontier, claim leases, attempts, findings, verifier challenges, contribution lineage, admission, discussion projections, and replay. It does not execute work, own participant-domain truth, become a global ontology or database, or grant authority. Most ordinary work should not materialize a room; it collapses to one direct GoalRun, Worker, route, Automation, service, or Session.

A GoalRun does not begin with a mandatory swarm or a fixed Planner / Executor / Verifier trio. The Goal Kernel runs the GoalGroundingLoop, inspects current state, and selects a provider-neutral RoleTopology: direct, goal conductor, delegated build, governed release, multi-context review, or specialist mesh. It opens independent Context Cells only when separation creates value.

Bounded delegation: Each role receives a scoped ContextLease. Cross-context work flows through ContextHandoff and TaskBriefPayload, becomes a HarnessInvocation, emits normalized HarnessAdapterEvent records, and returns a generic WorkResult with an OutcomeDelta when change is proposed. ImplementationResultPayload is only the software profile. Harness-native prompts remain adapter-private rather than becoming the durable coordination contract.
Verification and escalation: The conductor reconciles results into the GoalRun and satisfies the selected VerifierPath. Deterministic conductor verification is the default for ordinary work; independent reviewers, verifier workers, human review, or regulated review are policy-triggered escalation paths. Routing and fallback cannot widen authority, privacy, budget, connector, or tool scope.
Parallel candidates: Multi-path execution is selected only when its expected value justifies the latency, cost, privacy exposure, and verification burden. Candidate work remains pre-canonical. Agentgres models this family as AgentExecutionTrace, AgentExecutionBranch, StagedEffect, BranchCheckpoint, and BranchMergePlan. Canonical heads advance only through expected-head merge/admission; staged effects are revalidated against the current revocation epoch, grant expiry, and policy hash. Replay uses fresh authority and produces new receipts.
Merge discipline: A BranchMergePlan classifies touched heads as exclusive_owner, declared_commutative, or adjudicated. State merge is never text merge, and an unclassified conflict defaults to adjudication.

Mixture of Workers is the labor-routing doctrine for bounded, accountable worker contributions within these topologies. Its economic graph often uses planner, executor, verifier, and merge roles, but that is not the mandatory Goal Kernel topology and does not create a hidden swarm-control runtime.

Implementation status. GoalRun multi-harness orchestration is built and multi-path attempt comparison is partial. Thread forks, replay, counterfactual replay, and workspace snapshot/restore custody exist; the durable Agentgres branch and staged-effect objects above remain planned over that substrate. MoW routing doctrine is canonical, while MoW routing receipts remain planned.

Each routed Worker remains separately accountable. It has its own manifest, policy envelope, contribution terms, receipt obligations, and dispute surface. The final output is therefore not a black-box “agent response,” but an inspectable supply chain of Worker contributions. Separate accountability does not itself establish independent governance. When Workers controlled by independent principals are admitted, routed, verified, attributed, and compensated across organizational boundaries, the Mixture of Workers becomes a multi-party worker economy.

Four plurality claims remain distinct in schemas, receipts, UI, and economics:

Multi-model means several cognition routes or model families; it does not imply an accountable Worker or independent party.
Multi-worker means several versioned Worker compositions; it does not imply independent authority, truth, verification, or settlement.
Multi-node means several runtime, compute, provider, or failure domains; it does not imply independent governance.
Multi-party means separately governed principals controlling authority, operational truth, challenge, risk, or settlement. Even that does not prove result quality without evidence, verification, acceptance, and dispute semantics.

Worker Training is the supply-creation loop for this routing market. MoW does not assume that the best worker already exists. Workflows, examples, corrections, domain ontologies, data recipes, quality gates, verifier feedback, and benchmark failures can become training material for improved workers. Those workers can then be published, benchmarked, installed, composed, routed, and paid by receipts.

MoW routing may be invoked by Hypervisor, aiagent.xyz, sas.xyz, ioi.ai, CLI, SDK, enterprise backends, or workers themselves. Routing is a domain/kernel capability, not a single product surface. Each domain may operate its own router subject to routing receipts, declared policy, marketplace neutrality, and contribution accounting.

IOI may operate a disclosed first-party seed fleet of planner/researcher, builder, verifier, critic, synthesizer, and benchmark Workers to solve cold start, provide baseline quality and conformance fixtures, supply last-resort capacity, and seed Goal Space liquidity. Each is an ordinary named and versioned Worker under the same authority, isolation, benchmark, receipt, contribution, and routing contracts as external supply. The fleet discloses IOI ownership, subsidy, model/harness/runtime/provider dependencies, and real cost; receives no hidden ranking preference; and remains replaceable or outperformable without changing the pursuit contract.

The seed fleet remains one party while IOI controls its authority, operational truth, verification, risk, and settlement, even if it spans many models, accounts, nodes, providers, or clouds. It must not be represented as independent verification or proof of an open network. IOI must not simultaneously act as hidden coordinator, preferred paid Worker, sole verifier, ranking authority, and final settlement judge for the same outcome.

A worker can be routed as a primitive inside a larger labor graph or invoked directly as a managed assistant. These are not competing models. A contract review worker, research worker, code review worker, sales ops worker, or intake worker may be useful as a standalone web/API experience and also as a node in Hypervisor workflows, sas.xyz outcomes, enterprise automations, or MoW task graphs.

Agents are rarely standalone scripts. They are workflows: chains of reasoning, tool use, and verification. IOI represents workflows as Directed Acyclic Graphs (DAGs) so steps can execute locally, burst selectively, and escalate to settlement only where needed.

4.8.1 Execution Graph (Runtime View)

At runtime, the DAG is compiled into canonical ActionRequests and step-wise artifacts.

Step-wise artifacts (normative): Each node execution produces an artifact bound to:

canonical_payload_hash of inputs/outputs,
policy_hash,
model_snapshot_id (when applicable),
and parent step references.

Graph and step addressing (normative):

Traceability:

Because each step commits to prior artifact IDs and utilizes hash-linked receipt chains, final outputs carry a cryptographic chain-of-custody. A calendar update can be traced back to the specific summary receipt(s), policy, and required logs that authorized it.

4.8.2 Modular Dispute Resolution (Privacy-Preserving)

Because verification is step-scoped, arbitration is precise:

Disputes target noncompliance at a specific step, not “the whole agent.”
Challenge packages can reference graph_id and step_id and reveal only minimal evidence for that step.
Arbitration evaluates only the contested step under its declared ruleset.

Result: Accountability without full disclosure.

4.9 Sparse Worker Categories, Benchmarks, and Contribution Routing

The MoW worker economy requires a routing market that does not collapse into one global leaderboard. IOI therefore supports Sparse Worker Categories: narrow labor categories with explicit evaluation profiles.

A Sparse Worker Category may declare required DomainOntology refs, CanonicalObjectModel refs, WorkflowSchema refs, benchmark profile refs, EvaluationDataset refs, privacy classes, allowed training-data policies, and receipt obligations. Category claims are comparable only when workers are evaluated against declared ontology-bound inputs and rubrics.

aiagent.xyz is the canonical product domain for Sparse Worker Categories, Benchmark Profiles, worker manifests, trained worker packages, installs, managed instances, ranking, and routing eligibility. It may publish roots or commitments to IOI L1, but category operations, benchmarks, installs, and marketplace projections are domain-level Agentgres truth.

Examples:

Rust security audit worker
legal intake worker
grant research worker
sales follow-up worker
React refactor worker
insurance claim review worker
construction quote worker
local SEO worker
government RFP worker

Each Sparse Worker Category MAY define:

task class
allowed input/output schemas
benchmark suite
evaluation rubric
runtime requirements
policy requirements
trust posture requirements
receipt obligations
submission fee or stake
routing eligibility criteria

Submitting a worker to a category pays for benchmark execution and leaderboard admission. A submitted worker does not automatically receive routing. Routing eligibility is earned through benchmark performance, receipt completeness, policy compatibility, price, and reputation.

Product usage and external compensation use separate ledgers:

Goal Space subscription $\rightarrow$ bounded Work Credits $\rightarrow$ managed conductor/runtime/model/Worker/verifier usage $\rightarrow$ itemized usage receipts

Network/Open funding $\rightarrow$ NetworkGoalBudget, bounty, procurement cap, or ServiceOrder $\rightarrow$ independently admitted contribution $\rightarrow$ verification and acceptance $\rightarrow$ separate fiat, stablecoin, IOI, or other approved settlement rail

Work Credits are non-transferable product budget units, not cash, Worker payout, provider tokens, pooled seats, or the IOI protocol token. ContributionReceipts and applicable verifier, acceptance, adjudication, and settlement evidence determine external eligibility without turning the subscription allowance into a vague pooled payout fund.

Reference payout structure:

worker_payout = invocation_fee + metered_compute + success_bonus + quality_delta_bonus + royalty_share - dispute_or_failure_penalties

This structure supports direct invocation, outcome escrow, local royalties, free/open Workers, and benchmark-funded category admission while keeping product budget, contribution attribution, and payout semantically separate.

5. Settlement and Consensus

Implementation status: speculative target architecture. IOI L1 is not deployed in the current architecture baseline. This section describes the bounded public-settlement role and candidate protocol profiles; it does not claim a live chain, consensus deployment, validator set, escrow system, or production token economy.

Settlement is not runtime execution, and local autonomous work does not spam the public chain. Hypervisor nodes admit autonomous work and local interop through the Daemon, Agentgres, and local receipt chains. IOI L1 is reserved for public or independent-trust boundaries involving registry, rights, reputation, bonds, disputes, governance, economic settlement, or selected roots. No chain or consensus step is required per OutcomeRoom, GoalRun, frontier item, claim, attempt, finding, model invocation, receipt, or Agentgres operation.

Non-Ownership Invariants:

– IOI L1 does not own or store Hypervisor-node local settlement state.

– IOI L1 does not own or record every governed autonomous-system-chain transition.

– IOI gas is not consumed for local settlement records or internal module invocations.

– A receipt or committed root retains its declared assurance stage; public anchoring does not upgrade attested or evidenced work into verified, accepted, adjudicated, or settled work. The ordered assurance ladder is attested, evidenced, verified, accepted, adjudicated, and settled.

IOI L1 is designed as a bounded settlement, registry, dispute, governance, and identity-anchor layer. It does not execute cognition; an implemented settlement profile would receive selected consequences of cognition executed elsewhere. Before a commitment can reach that boundary, the underlying act must have crossed the Determinism Boundary and become a transaction-shaped artifact: canonical, authorized, policy-bound, receipt-backed, and challengeable.

Independent L1s and sovereign domains govern their own application state independently. They may adopt IOI kernel / L0 releases by hash, policy, and local governance decision, but IOI Mainnet does not manage their ordinary state transitions. Such domains do not stream local execution traces to the public L1; they maintain their own operational truth locally within Agentgres or an equivalent domain substrate and would post only sparse roots under explicit trigger events. A future IOI L1 may host selected public registry, service-order commitment, dispute, bond, reputation, rights, or governance contracts; Hypervisor execution and provider placement do not depend on such a deployment.

This enables specialized autonomous-system economies (e.g., a medical diagnosis consortium or an HFT domain) to coordinate as sovereign domains or run in confidential/private execution environments while optionally anchoring to Mainnet’s bounded public primitives: settlement, arbitration, registry, reputation, rights, and sparse verification commitments.

5.1 The Role of IOI L1: Settlement, Registry, and Disputes

The sparse L1 settlement boundary. Under the edge-in topology, IOI L1 (and compatible execution chains) does not serve as an active application runtime or general-purpose virtual machine. It is optimized strictly as a secure, sparse ledger for public, economic, and cross-domain commitments.

By default, all autonomous work, state transitions, model iterations, and intermediate outputs are admitted locally inside Agentgres via signed receipts, operation logs, and content-addressed artifact references. This local execution layer is private by default and decoupled from the public chain; disclosure depends on the selected provider, cTEE posture, wallet.network authority, and declassification policy. The IOI L1 chain never reads, accesses, or processes raw workspace contents, private memory, or unredacted workflows.

Interaction with the public L1 ledger is entirely optional and strictly trigger-based. A local domain kernel, Hypervisor Node, or trusted local/client authority domain only escalates state commitments upward to IOI L1 when a specific transactional boundary (such as financial escrow, public licensing, service registry registration, or SLA dispute arbitration) is crossed.

The trigger table below is a menu of optional public-settlement profiles, not an automatic escalation policy. A marketplace listing, collaboration, reputation observation, cross-domain exchange, or user archive remains domain-local unless its governing parties intentionally select an implemented public contract and the disclosure, authority, assurance, and funding conditions for that contract are satisfied.

L1 settlement triggers.


Trigger Event	Description	L1 Action	Local / Domain Source	L1 Privacy Status
Marketplace Listing	Publishing a new worker capability for discovery.	Registers the signed WorkerManifest or package commitment and license parameters on the public registry.	WorkerManifest / aiagent.xyz registry	Public Metadata (manifest hashes and capability declarations only).
ServiceOrder Commitment	Establishing a formal delivery agreement.	Records a public/economic commitment or locks escrow for a ServiceOrder bound to outcome terms, success schema, and delivery/dispute rules.	ServicePackage / sas.xyz proposal / sas.xyz Agentgres state	Public Metadata (order commitment, escrow, and settlement parameters only).
Escrow / Payment	Securing payment for an autonomous outcome.	Locks or releases approved settlement assets under the selected escrow or payment contract.	wallet.network payment authorization / settlement intent	Public Transaction (addresses and token values only).
SLA Dispute	Contesting a failed outcome or delivery.	Submits the contract-defined dispute and evidence commitments and locks any required arbitration bond.	DeliveryBundle / dispute package	Public Case Hash (zero-knowledge / selective disclosure of the failing step only).
Rights / Licensing	Minting and routing royalties for intellectual property.	Records ownership transfers and routes runtime execution royalty payments.	ServicePackageLicense / ContributionReceipt	Public Metadata (license refs, royalty splits, and package-right commitments only).
Public Provider Commitment	Anchoring a selected provider, bond, reputation, or conformance claim.	Records the opted-in public commitment; it does not publish provider credentials or become the placement source.	HypervisorOSBootReceipt / node manifest / assurance claim	Public Record (declared metadata, commitments, and public keys only).
Reputation Commit	Anchoring a selected performance projection.	Anchors a sparse Merkle root of task-performance evidence while preserving each claim’s assurance stage and challenge posture.	Agentgres Quality Ledger / aiagent.xyz	Public Root (hash-only representation).
Cross-Domain Commitment	Publishing a selected commitment from an independent domain.	Registers the exact state or evidence commitment accepted by the selected inter-domain contract.	AIIPEnvelope / state-root ref	Public Root (hash-only representation).
App-Chain Interop	Exchanging value across distinct application subnets.	Executes or records only the contract-approved value transfer; it does not create a universal IOI bridge or import application state.	LocalSettlementReceipt	Public Transaction (asset transfers and lock proofs only).
User Public Commit	Manual request for public timestamp, inclusion, or ordering evidence.	Commits a snapshot of the current local state-root to the public ledger.	AgentStateArchive watermark	Public Root (encrypted archive hash only).

An L1 commitment proves only the exact signature, inclusion, ordering, contract transition, or proof-system statement covered by its profile. It does not make an external-world assertion correct, establish contribution causality, manufacture reviewer independence, or convert a provider-operated fleet into multiple independent parties. Reputation, contribution, and marketplace projections must preserve the assurance stage and the identities, affiliations, verifier versions, disputes, and reversals that qualify the underlying evidence.

IOI L1 is a proposed high-security ledger optimized for enforceability, not raw interaction throughput or infrastructure discovery. It may anchor selected public provider-registry, bond, reputation, rights, governance, settlement, or dispute commitments. Hypervisor placement remains off-chain and source-plural: candidates may come from direct adapters, connected or customer inventories, managed capacity, DePIN or storage markets, and optional decentralized.cloud; Hypervisor admits the PlacementDecision.

IOI L1 responsibilities are intentionally bounded:

Public Coordination and Settlement Boundary

- Balance Finality: Maintains balances only for the settlement assets admitted by an implemented contract profile. Work Credits remain a product usage and budget abstraction unless an explicit settlement profile maps them to a settlement rail.
- Escrow and commitment management: Applies only the selected L1 contract profile for public escrow, rights, bonds, disputes, payouts, or other economic finality. Routine provider billing and local Work Credit accounting do not become L1 channel state.
- Fee Settlement: Settles explicitly disclosed fees only where the selected contract requires public coordination or where paid optimized routing/procurement produced challengeable evidence. There is no generic cloud-session cut, local-work tax, receipt fee, authority fee, or Agentgres-write toll.
- Bond Custody: Custodies and enforces SLA collateral posted by Providers to collateralize declared uptime and honest-execution obligations under the relevant dispute rules.

Opt-In Dispute and Remedy Contracts

- Dispute Intake: Accepts only the dispute and evidence package declared by the selected contract profile and initiates that profile’s verifier, appeal, and adjudication path.
- Resolution Enforcement: Executes a remedy only after the contract’s authorized decision path reaches finality. There is no universal Arbitration Lane or automatic model judiciary.

Verification, Registry, and Rights Anchor

- Optional Provider Registry Commitments: May anchor opted-in public provider, conformance, bond, reputation, or dispute commitments. Direct adapters and candidate engines remain the placement sources; the public registry is never a mandatory provider gateway or credential store.
- Identity Anchor: May anchor public namespace, publisher, provider, domain, runtime, or manifest identity commitments. wallet.network and applicable domain owners retain identity operations, keys, authority grants, approvals, recovery, and revocation.
- External Evidence Anchor: May commit selected verifier-profile, evidence, or state roots required by a public contract. This is not a bridge and does not make IOI L1 the operational source of external state.

5.1.1 Operational Invariant: Optimistic by Default

The target IOI L1 posture is optimistic and sparse: local/domain runtimes produce transaction-shaped acts, while a future public chain receives only selected commitments under the active contract profile. Provider transport, private workspace transfer, execution, and operational truth stay off-chain. Public work is concentrated at declared boundaries:

Registry events: Opted-in provider, capability, rights, reputation, conformance, or SLA-bond commitments.
Settlement events: ServiceOrder escrow, rights, payouts, bonds, and explicitly triggered public or cross-domain economic finality.
Dispute events: Contract-defined challenges, evidence verification, authorized decisions, appeals, and remedies.

The design objective is to keep effective interaction capacity at the edge while making future IOI L1 load proportional to selected public/economic events rather than cognitive steps; no quantitative throughput claim is made.

5.2 Settlement-Profile Modularity

The IOI Runtime is consensus-agnostic. Runtime and domain contracts should preserve common receipt and commitment semantics across local authority, replicated domain, and future public-settlement profiles. The current canonical architecture does not select or deploy a concrete IOI L1 consensus engine, nor does it canonize a named consensus-driver ABI.

The Hypervisor Daemon enforces the daemon effect boundary, normalizes inputs, and generates cryptographic receipts, but it does not dictate the security model of a settlement domain. Illustrative profiles include:

Local authority mode: A local Hypervisor Node or governed domain admits its own operations without public-network consensus.
Replicated or federated domain mode: A sovereign domain may select a BFT, Raft, multisignature, database-replication, or other agreement profile suited to its trust and availability model.
Public settlement mode: A future IOI L1 profile must declare exact consensus, finality, data-availability, challenge, verifier, governance, and adversary assumptions before it can carry public or irreversible economic commitments.

5.2.1 Settlement-Profile Invariance

Changing the agreement or settlement profile must not silently change the artifact meaning.

Schema Invariance: A Receipt has the same canonical fields and hashing rules regardless of the settlement profile.
Binding Invariance: Canonicalization (RFC 8785), model_snapshot_id, and policy_hash bindings remain identical.

What changes is the attestation class and available enforcement regime—not the semantics of the artifacts. This supports Worker portability across the fractal network: an artifact built and tested in a private enterprise domain can be submitted to a compatible public settlement or adjudication profile without redefining its canonical fields. Acceptance still depends on that profile’s authority, evidence, verifier, assurance, disclosure, and funding requirements.

5.3 Research Candidate: Challenge-Dominant Settlement Finality

This subsection records an AFT research candidate for a future public settlement profile. It is not current architecture canon, not a deployed IOI Mainnet engine, and not a quantitative security claim. Promotion would require a canonical L1 owner update, formal specification, executable conformance, independent review, and explicit synchrony, adversary, data-availability, committee-selection, governance, and challenge-window assumptions.

The candidate separates throughput-critical publication from authority-critical verification. Its goal is to make irreversible economic effects challenge-dominant and fail-closed: if required observer, witness, or retrievability evidence is missing or inconsistent, the slot aborts rather than settling unsafe state. No claim is made here that this design exceeds classical BFT bounds or is safe under a particular Byzantine threshold.

Synchrony and challenge-epoch baseline. The candidate assumes a weak-synchrony model: after Global Stabilization Time (GST), public messages are delivered within a bounded $\Delta_{\mathrm{publish}}$, retrieval requests complete or fail within $\Delta_{\mathrm{retrieve}}$, and verification finishes within $\Delta_{\mathrm{verify}}$. A production deployment sets an epoch duration $T_{\mathrm{epoch}}$ and challenge duration $T_{\mathrm{challenge}}$ such that challenge publication, evidence retrieval, recovery-capsule reconstruction, and verifier execution can complete before the epoch closes. Any settlement commitment whose proof depends on off-chain bytes MUST bind a retrievability window satisfying:

T_{\mathrm{retrievable}} \geq
T_{\mathrm{challenge}} + \Delta_{\mathrm{publish}} +
\Delta_{\mathrm{retrieve}} + \Delta_{\mathrm{verify}}.

If the respondent, provider, storage lane, or witness set fails to serve the evidence required by the committed ArtifactRefs/PayloadRefs within that epoch, the challenge is valid by absence. The challenged settlement fails closed in favor of the challenger; no escrow release, slashing defense, reputation update, or irreversible right transfer may depend on bytes that were unavailable during the declared challenge epoch.

5.3.1 The Two-Tier Finality Model

The research sketch uses a two-tier finality model that keeps block transport on a fast finality lane, then upgrades selected slots to a stronger irreversible-effect settlement state:

BaseFinal (Fast Finality Lane): A validator majority Quorum Certificate (QC) plus a witness committee certificate. Used for rapid chain progression.
SealedFinal (The Irreversible Path): Upgrades BaseFinal using a deterministic sealing plane. Irreversible effects (e.g., releasing a service outcome escrow) require a proof-carrying SealObject that binds the observer/witness sealing surface.

Ambiguity or adversarial behavior during the sealing phase collapses deterministically to Abort, preventing the network from heuristically retrying or partially settling unsafe state.

5.3.2 Canonical Challenge V1: Deterministic Observer Sealing

To upgrade a block to SealedFinal without requiring >2/3 honest voting, the sketch considers Deterministic Observer Sealing.

Observers are assigned deterministically via an epoch seed. Each observer evaluates the block and publishes exactly one of two objects:

A guardian-backed AsymptoteObserverTranscript (Ok).
An objective AsymptoteObserverChallenge (e.g., MissingTranscript, TranscriptMismatch).

The observer acceptance rule is strictly challenge-dominant:

SealedFinal is accepted if and only if the TranscriptSurface covers every assignment and the ChallengeSurface is empty under the declared challenge rules, emitting an AsymptoteObserverCanonicalClose.
If any valid challenge exists, the slot deterministically emits an AsymptoteObserverCanonicalAbort.

Because canonical close and canonical abort are mutually exclusive, a challenge-dominated slot cannot authorize irreversible release. Under the declared data-availability, challenge-window, and publication assumptions, any eligible observer able to publish an objective challenge can prevent unsafe settlement and route the slot into the configured remedy or slashing path.

5.3.3 Endogenous Retrievability: Witness-Coded Recovery Capsules

To make the ordered set uniquely recoverable under declared data-availability assumptions, the sketch considers an Endogenous Retrievability Plane via nested witness committees. Any quantitative withholding threshold is a parameter of the production driver, committee-selection model, coding scheme, and challenge window, not a universal guarantee of the abstract architecture.

Witness-Coded Recovery: The protocol uses abstract coded recovery families (e.g., SystematicXorKOfKPlus1V1 or SystematicGf256KOfNV1) to generate RecoveryCapsules.
Reconstruction: Threshold-many public RecoveryShareMaterial reveals can reconstruct the payload, outputting a compact RecoveredPublicationBundle.
Fail-Closed Impossibility: If assigned witnesses fail to reveal their shares, the network accumulates MissingRecoveryShare objects. Once the missing count exceeds the threshold required for recovery, the protocol materializes a deterministic recovery-impossible canonical abort.

This ensures that the protocol does not stall indefinitely waiting for withheld data; it either recovers the payload or objectively aborts, maintaining the challenge-dominant safety property declared in the production specification.

The Witness-Coded Recovery Capsule is therefore part of the data availability contract, not a replacement for it. A recovery capsule is valid only when its reveal schedule, coding threshold, and retrieval deadline fit inside the active challenge epoch. If recovery shares or raw payload bytes are not served in time, the resulting MissingRecoveryShare or MissingEvidence object is enough to defeat the challenged settlement path.

5.3.4 Challenge-Dominant Settlement for the Agentic Economy

Because the IOI kernel / L0 substrate is consensus-agnostic, agents execute their logic off-chain, inside Hypervisor domains, or inside independent sovereign domains. IOI L1 is the public settlement venue for economic commitments, rights, disputes, reputation, and sparse roots where authority-critical effects become public and economically irreversible.

AFT’s design intent is that authority-critical settlement is challenge-dominant: under the declared synchrony, data-availability, and observer-coverage assumptions, missing or inconsistent evidence aborts a slot before unsafe state can settle. The exact adversary tolerance is a function of those assumptions and the active challenge windows; quantitative Byzantine thresholds are stated only in the production Mainnet specification, not in this whitepaper.

The architectural goal is to remove reliance on dense validator quorums for safety: settlement should fail closed when required evidence is unavailable, rather than rely on majority honesty alone.

5.4 Future Settlement Contract Profiles

Future IOI L1 settlement contracts are the public ingress/egress profiles for selected registry, rights, reputation, bond, dispute, governance, and economic commitments. They are not the execution runtime or a universal adjudicator; each profile declares its inputs, evidence, verifier, authority, finality, appeal, and remedy rules.

5.4.1 Settlement Pipeline

Any settlement artifact (Commitment, Bond Claim, Dispute) must pass the pipeline:

Ingestion: The selected settlement profile receives a declared SettlementEnvelope, settlement intent, bond claim, rights commitment, or dispute package.
Artifact Verification: Validates the applicable canonical commitments, authority refs, signatures, receipt/evidence roots, contract profile, and funding or bond conditions without ingesting ordinary runtime history.
Evidence Review (Optional): If the settlement involves a disagreement regarding external outcomes, the selected verifier checks the attached EvidenceBundle under the contract’s declared coverage and assumptions.
Resolution & Release: Based on the authorized decision and covered evidence, the contract initiates the financial logic. The actual transfer of assets (releasing escrows, slashing bonds, or transferring package/license royalties) is explicitly held until the selected settlement profile reaches its required finality condition.

5.4.2 Driver-Based Interoperability

IOI enables agents to interact with any external system, blockchains, cloud APIs, or legacy databases, through I/O Drivers.

No "Native" Chains: The protocol treats Ethereum, Solana, and AWS equally: they are external systems accessed via tools.
wallet.network capability strategy: Interoperability is achieved through scoped authority and capability execution, not state bridging. wallet.network is mandatory when portable delegated authority, secrets, spend, declassification, or high-risk external effects are involved; local/domain governance may own ordinary local decisions. Agents request exact intents; the applicable authority path and daemon gate admit or deny them; and the tool/driver broadcasts only approved transactions.
Atomic Swaps: Cross-chain value transfer is handled via standard Hashed Timelock Contracts (HTLCs) or liquidity solver networks orchestrated by the agent, rather than a native IOI bridge protocol.

5.5 Domain Networks, Sovereign Domains, and L0-Instantiated Execution Domains

The IOI kernel / L0 substrate may instantiate domain networks, sovereign execution domains, non-intelligent chains/state machines, and intelligent blockchains. These domains can use their own consensus, state, policy, receipts, and projection machinery. IOI L1 does not become their application runtime; it can anchor their release roots, registry commitments, settlement claims, governance approvals, and dispute outcomes.

Sovereign domains, independent L1s, and intelligent blockchains are formally instantiated through daemon/domain contracts that Hypervisor CLI/headless and IOI protocol subcommands can scaffold, submit, inspect, and verify. This is the developer-grade, kernel-adjacent operator path for defining domain topology, policy roots, manifests, receipts, and delegation models. The client does not own the L0 substrate and does not bypass daemon or domain-kernel APIs; it is not a standard Web2 SaaS dashboard, but it is still a protocol-facing operator path for domain construction.

Because the network operates as an operating substrate rather than a monolithic chain, a sovereign domain is an independent deployment that uses IOI kernel/L0 primitives, domain contracts, or SDK releases where they fit its trust model.

5.5.1 The Independent Domain Thesis

Unlike traditional Web3 L2 rollups designed to offload execution from a congested L1, IOI domains and independent L1s do not rely on IOI L1 for execution, validation, or anchoring by default. They are independent trust domains that may adopt the same kernel/L0 substrate, schemas, receipts, and AIIP conventions.

Execution Separated from Coordination: Cognitive work executes on user or provider hardware, while the sovereign domain tracks the canonical coordination state, object transitions, leases, receipts, and projection checkpoints required by that trust domain.
Federated Consensus: Domain deployments (e.g., a hospital consortium, a trading firm) compile the L0 Kernel and run validators on their own infrastructure using a declared replicated or federated agreement profile. They reach local agreement over domain state without publishing sensitive data or paying gas to public IOI L1.
API-Native Interoperability Without Mandatory Enshrined Bridging: Sovereign domains and independent L1s do not inherently need complex, protocol-enshrined bridges to communicate with the outside world. They expose standard gRPC or HTTP REST endpoints. Because they run the IOI SDK, a declared adapter may package selected API responses as canonical JSON with the applicable AIIP envelope, signature, and receipt refs. An external client can verify those exact signatures and commitments against the domain’s declared public keys and profile off-chain; ordinary API responses do not become receipted or trusted automatically.

5.5.2 Deployment Topologies

Rather than a strict hierarchy, the IOI ecosystem supports parallel deployment topologies tailored to different trust and coordination requirements:

Future IOI Mainnet (Public Utility): Uses a consensus and finality profile selected only after canonical specification and review. It may host selected public ai:// registry, service-order, rights, reputation, bond, governance, settlement, and dispute commitments without becoming the provider-discovery or execution layer.
Sovereign Domains / Independent L1s (App-Specific): Select a declared agreement profile suited to their trust model. Handles domain-specific coordination, internal app serving, and enterprise workspaces. They manage their own internal state and do not anchor to IOI Mainnet unless explicitly exporting trust or participating in cross-domain public settlement.

6. Cryptography and Evidence

This section specifies the cryptographic primitives the IOI architecture requires. The protocol is designed for institutional risk models: cryptography that remains durable under future cryptanalytic shifts, and evidence interfaces that verify external state without trusting opaque APIs or centralized bridges.

The protocol enforces two primary invariants:

Longevity: artifacts and identities remain secure against future cryptanalytic shifts, including large-scale quantum adversaries.
External Evidence Verification: the kernel can verify claims about external state (e.g., Ethereum transactions, Solana proofs) under explicit driver-specific verification rules, without maintaining active light clients or trusting centralized bridges.

6.1 Strict Hybrid Cryptography (Classical + Post-Quantum)

Post-quantum algorithms are newer and may carry undiscovered design or implementation risk. IOI therefore targets hybrid classical and post-quantum profiles for long-lived identity, authority, policy, transport, archive, and public-commitment use where the risk model requires them. Exact suites are versioned wallet/transport/verifier profiles, not timeless launch invariants in this whitepaper. The current architecture canon does not select a genesis suite or claim a deployed post-quantum network.

Root and recovery profile: A versioned wallet profile may bind classical and post-quantum root material, factors, guardians, threshold shares, recovery posture, and legacy-asset compatibility. The derivation and mnemonic scheme must be specified and reviewed by the wallet owner before use.
Transport profile: A versioned application-layer hybrid KEM profile may combine approved classical and post-quantum mechanisms to reduce harvest-now/decrypt-later risk. Algorithm choice, parameter set, transcript binding, downgrade resistance, and rotation policy belong to the selected profile.
Identity and policy profile: Long-lived authority artifacts may require conjunctive classical and post-quantum signatures under a versioned profile. Verifiers must bind the exact algorithms, parameters, domain separation, expiry, and revocation posture rather than accepting a generic “PQ secure” label.
Data-at-rest profile: Wallet, memory-vault, archive, and context-projection and private-workspace-capsule encryption uses an approved authenticated-encryption profile with explicit key lifecycle, rotation, erasure, recovery, and algorithm agility.


Target invariant: ** Long-lived security claims must name a versioned cryptographic profile, its assumptions, key lifecycle, verifier support, and rotation path. No algorithm label by itself guarantees decades of security.

6.2 The EEI: External Evidence Interface

IOI is not a bridge. The L0/domain substrate and Hypervisor Daemon do not need to maintain active light clients or sync external blockchain headers. Instead, external-state claims use a passive evidence model: participants submit structured evidence bundles and a declared verifier evaluates the exact claim under a named rule, version, and assumption set.

To support a claim that an external event occurred (e.g., "This transaction was confirmed on Ethereum" or "This bank API returned 200 OK"), participants use the External Evidence Interface (EEI).

EEI is what lets an IOI act remain transaction-shaped even when the external consequence occurs outside IOI. The IOI receipt attests the declared request, policy, authority decision or grant ref, actor, and runtime boundary facts covered by its profile. The EEI bundle supplies provenance-bearing support for the external-consequence claim. Verification, acceptance, adjudication, and settlement remain separate assurance stages.

6.2.1 Evidence Bundles

The EEI defines a standard schema for wrapping external data so it can be evaluated by the verifier or adjudication path named in the governing contract. An Evidence Bundle consists of:

The Claim: A canonical JSON object describing the event (e.g., { "chain": "eth", "tx_hash": "0x...", "event": "Transfer", "amount": 100 }).
The Proof: Cryptographic material supporting the claim. This is driver-specific:
For Blockchains: An RPC receipt proof, a merkle inclusion proof, or a block header signed by a known oracle/notary.
For Web APIs: A TLSNotary proof or a signed attestation from a Multi-Party Computation (MPC) witness.
The Binding: A hash link to the specific Agent Action Receipt that triggered the external event.

Normative Invariant (Zero-Bloat Verification): The firewall evaluates chain-visible manifests and receipts that bind request_hash to evidence_hash. Raw local bytes remain in local memory/artifact storage behind Agentgres-governed refs; only the canonical hash crosses to consensus.

6.2.2 Verification via Drivers

The Kernel does not verify the Evidence Bundle natively. Instead, verification is delegated to the Driver that generated the action.

Example: If an agent uses the driver::eth_wallet to send funds, that driver includes the logic to parse and validate an Ethereum Receipt.
Verification and adjudication role: A declared verifier may load the relevant versioned Driver Plugin to validate the Evidence Bundle. A passing result means only that the named claim satisfied that verifier’s rule and evidence coverage. The applicable counterparty may then accept it, a declared adjudicator may resolve a challenge, and a settlement profile may consume the accepted or adjudicated result.

Chain of Custody:

The authority and daemon boundary binds the declared intent, policy, grant, and execution facts. The versioned driver or verifier interprets the declared external-evidence format. Neither role expands its claim beyond the evidence and threat model it actually covers.

6.3 Canonicalization: The Common Tongue

To enable seamless movement of artifacts between Local, and Global environments, IOI enforces strict data canonicalization.\

Normative Standard (External):

RFC 8785 (JSON Canonicalization Scheme, JCS), which builds on I-JSON constraints and deterministic property sorting to produce a hashable representation. ([RFC Editor][2])

6.3.1 Determinism Invariant

Before hashing or signing, runtimes MUST canonicalize payloads:

No whitespace variance
Deterministic key ordering (UTF-16 code unit order, locale-independent)
Reject NaN/Infinity
Economically meaningful quantities MUST NOT use JSON numbers; represent as fixed-point strings at the schema layer

6.3.2 canonical_payload_hash

Every IOI artifact is identified by a hash computed over canonical bytes:

6.4 Domain Separation

To prevent replay across contexts, IOI enforces strict domain separation:

Each cryptographic owner declares versioned domain-separation labels for its artifact and signature families. Illustrative categories include:

public block or commitment headers;
runtime and settlement receipts;
dispute and remedy decisions; and
manifests, packages, and releases.

Exact byte labels are not fixed by this synthesis; a verifier must reject an unknown or mismatched profile rather than guess a domain.

6.5 Cryptographic Agility (Verifier Registry)

Instead of treating algorithms as timeless constants, implementations use a versioned Verifier Registry abstraction:

Algorithm_ID → Verifier_WASM_Blob

Upgrade path: domains may add signature schemes or proof verifiers through their declared governance and module-update path. A future IOI L1 may anchor an on-chain registry, but no deployed registry or genesis suite is claimed here.

6.6 Proof-Carrying Private Execution Envelopes

Private execution is substrate-neutral. IOI does not require Trusted Execution Environments as a root of authority. TEEs may be used as one admissible execution substrate for confidentiality and operational practicality, but they do not define validity. A private execution claim advances only when its evidence satisfies the declared receipt and verifier profile for its action class. Acceptance, adjudication, and settlement are later contract states rather than implications of receipt sufficiency. Where feasible, IOI prefers proof-carrying computation — including zero-knowledge proofs, verifiable computation, FHE-backed private evaluation, MPC, or hybrid constructions — because these reduce reliance on hardware attestation roots and align private execution with the protocol’s deterministic settlement model.

IOI treats private execution as a substrate-neutral evidence problem. A private execution envelope may protect confidentiality, correctness, or both:

Confidentiality: The worker computes over sensitive inputs while minimizing disclosure. FHE and MPC can replace TEEs for bounded private evaluation where latency and cost permit.
Correctness / Verifiability: The worker proves that a committed computation was executed correctly. ZK-ML and verifiable computation can satisfy bounded inference, classifier, policy, or scoring claims without relying on a hardware vendor as the sole attestation root.
Operational practicality: TEEs remain admissible for running ordinary software with lower integration friction. In IOI they are treated as evidence adapters, not as protocol trust roots.

Declared verifiers evaluate evidence sufficiency rather than treating substrate identity as validity. The verifier registry therefore supports TEE quote verifiers, ZK proof verifiers, MPC transcript validators, FHE parameter validators, deterministic replay verifiers, and future proof systems. The canonical verification question is not “Did this run in a TEE?” but “Which exact claim does this evidence establish under the required profile and threat model?” A settlement contract separately asks whether the claim reached its required acceptance or adjudication state.

Normative invariant: A private execution substrate MUST NOT be treated as a source of authority. Authority comes from the applicable local/domain governance and wallet.network grant or approval path; hashes, policy bindings, scopes, and receipts record and constrain that decision but do not create it. The substrate contributes evidence only.

6.6.1 Private Execution Evidence and CustodyProof

A CustodyProof, TEE quote, ZK proof, MPC transcript, FHE commitment, deterministic replay result, provider receipt, or hybrid bundle is evidence, not an authority grant. Verifiers accept, reject, or mark a claim inconclusive by checking the evidence profile required for the action and privacy posture. No substrate label alone defines validity.

For Private Workspace backed by cTEE, the verifier-facing object is:

CustodyProof {

proof_id, workspace_id,

policy_hash,

sensitivity_manifest_hash, custody_type_derivation_hash,

mount_graph_hash, remote_admissibility_derivation_hash,

candidate_lattice_commitments,

counterfactual_lattice_receipts, private_operator_receipts,

declassification_receipts, capability_exit_receipts,

leakage_receipts, state_root_before, state_root_after,

verifier_result: no_plaintext_custody | rejected | inconclusive

}

7. Identity and Authority

In the Internet of Intelligence, identity must bridge two worlds... assets, reputation, and liability. We are moving from Know Your Customer (KYC) to Know Your Agent (KYA).

KYA is the identity layer that lets Own become Act without becoming ambient authority. It turns property rights into scoped, revocable, receipt-backed execution authority.

KYC (Biological): Validates who you are (Passport, ID).
KYA (Cryptographic): Validates what you are (Code hash), how you behave (Policy envelope), and what you are worth (Bonded Liability).

The IOI identity stack makes consequential work attributable inside its applicable authority and truth domain; local-only work does not require a public ledger identity.

IOI uses a progressive identity model. Users (and agents) are not forced to manage seed phrases to begin; they start with device-local authority and upgrade to network sovereignty only when they need to hold funds or sign binding contracts.

7.1 wallet.network Authority and Access-Point Profiles (Legible Agency)

wallet.network is the portable delegated-authority layer for identity operations, secrets, capability leases, approvals, payments, decryption, revocation, and audit lineage. Hypervisor and domain owners may retain ordinary local governance, project policy, eligibility, and admission decisions; wallet.network becomes mandatory when power must be portable, revocable, secret-bearing, spend-bearing, declassification-bearing, cross-domain, or executable by an autonomous worker. A guardian/access-point profile may exist inside this authority path as a device, browser, phone, enclave, threshold, or daemon-adjacent policy/attestation role, but it is not a peer authority system. The profile helps produce accountability attestations: it can bind approval state, key-share use, policy hash, device posture, or non-equivocation evidence into an append-only receipt chain.

This is what makes software legible to the economy: an agent can be given a budget because its actions are auditable, bounded by policy, and, when operating under enforceable modes, subject to slashing or dispute enforcement.

Implementation status. Capability-lease authority, sealed credentials, and approval gates are live in the daemon. Guardian surfaces, key shards, and an MPC vault are planned; the profiles below are target architecture where those facilities are not yet implemented.

7.2 The Superset Identity Stack (Root Custody vs. Execution)

IOI explicitly separates the authority to act (Operational) from the authority to own (Economic) while requiring the former to inherit deterministic constraints from the latter. However, to prevent legacy cryptographic vulnerabilities from compromising Web4 agency, IOI defines a target Cryptographic Superset Identity Model. This model avoids mandatory reliance on legacy EOAs by permitting a versioned hybrid/PQ-aware root for Web4 authority, while legacy-chain assets remain governed by their native cryptographic assumptions and are risk-labeled accordingly.

The architecture defines a three-tier identity stack that progresses from frictionless onboarding to institutional-grade security. Root generation, recovery, classical/PQ composition, and legacy-asset compatibility are versioned wallet profiles rather than one mandatory mnemonic construction.

Tier 1: Root Custody Profile

Role: High-assurance custody of funds, a versioned identity anchor, and root policy authority for the user’s wallet domain.
Implementation profile: A versioned wallet root and recovery profile may bind classical, post-quantum, threshold, guardian, and legacy-asset key material. It must declare derivation, export, recovery, rotation, revocation, and compatibility semantics explicitly.
Function: The Root Custody Profile serves as the highest-value "Source of Funds" and "Root of Policy." It is never directly connected to a high-frequency agentic workflow or dApp. It is secured by the user's highest configured authentication threshold (e.g., 3FA/MPC). While users may optionally link a legacy Web3 hardware wallet (the "Link and Upgrade" bridge) as a liquidity source, the Root Custody Profile is the highest-assurance custody and recovery authority in the stack.

Tier 2: wallet.network Authority Core

Role: Hot management of secrets, policies, session automation, and out-of-band approvals.
Implementation: wallet.network, acting as the local authority, policy, secret-brokerage, approval, and revocation service.
Cryptography: Versioned classical/PQ signature, channel, vault-encryption, and recovery profiles selected by wallet.network policy and verified under their declared algorithms and parameters.
Function: The wallet.network Authority Core holds "Operational Authority." It evaluates agent requests against the user's pre-approved Policy Envelope. Based on the user's configured Frictionless-to-Fortress policy, it either auto-signs intents, executes capabilities internally via the brokered secret execution path, or triggers Step-Up MFA (e.g., FaceID or YubiKey) to mint time-bounded CapabilityLease objects, short-lived signer grants, and ApprovalTokens.

Tier 3: The Worker & Agent Execution Account (Execution Layer)

Role: Autonomous execution of tasks and on-chain interactions.
Implementation: CapabilityLease-bound short-lived signer grants used by the Agent Runtime, executing through an Agent Execution Account.
The Smart Account Upgrade: To ensure security survives a compromised runtime, the Agent Execution Account may be deployed as an ERC-4337 Smart Account.
Function: wallet.network Authority Core authorizes Tier 3 CapabilityLease-bound signer grants as temporary module signers for the Smart Account. Workers operate autonomously within their granted scope. Crucially, On-Chain Modules (e.g., Spend Limits, Contract Allowlists) act as an on-chain enforcement backstop. Even if a local guardian/access-point profile is compromised or an agent goes rogue, smart-account policy can prevent the agent from draining funds beyond the module's strict limits defined by the Root Custody Profile and active Policy Envelope.

Authority-Core Delegated Agent Autonomy:

In this architecture, agents do not generate raw signed transactions. Instead, an agent generates a canonical TxIntent. The Tier 2 wallet.network Authority Core evaluates this intent against the Policy Envelope and the user's current security tolerance settings.

Low-Risk Intents (e.g., read-only calls, allowlisted swaps) are processed with Level 1 (Frictionless) auth.
High-Risk Intents (e.g., modifying network allowlists, transfers exceeding caps) trigger an Out-of-Band Step-Up, requiring the user to sign an ApprovalToken via a TEE-backed factor (FaceID) or a physical hardware key (YubiKey).

This model constrains the risk of the active execution environment away from the user's primary capital, enabling scalable autonomy with bounded exposure, revocation, and receipt-backed accountability rather than relying on the runtime to hold root custody.

The Link and Upgrade Bridge

The target Link and Upgrade profile does not require a legacy browser wallet to become the Web4 authority root. A versioned wallet root/recovery profile may combine classical, post-quantum, threshold, guardian, and legacy-asset factors after its derivation and recovery design is specified and reviewed. A legacy EOA may be linked through a signed proof such as SIWE for onboarding or liquidity without upgrading the legacy chain’s cryptographic assumptions. No native PQ seed implementation is claimed by this whitepaper.

7.3 wallet.network: The Authority Wallet and Capability Layer

To ensure that autonomous systems can act without usurping ownership, Hypervisor routes portable delegated authority, secrets, spend, declassification, and high-risk external effects through wallet.network or an approved compatible authority client. Ordinary local product governance may remain with its domain owner.

wallet.network is the canonical authority wallet and capability layer of the machine economy. It controls custody policy, key-use authority, policy grants, step-up challenges, secret leases, payment scopes, decryption/viewing leases, and revocation epochs.

To prevent credential theft, raw secrets and private keys are never stored on rented remote nodes, nor are they ever accessible to autonomous workers. When a worker requires an external interaction (e.g., executing a bank payment or modifying a cloud repository), it cannot request raw credentials. Instead, the action must execute as a capability exit: the Hypervisor Daemon intercepts the action proposal and requests a short-lived, scoped cryptographic grant from wallet.network.

The protocol requires wallet.network or an approved compatible authority client where work needs portable delegated authority, secrets, spend, declassification, provider-trust acceptance, cross-domain reuse, or high-risk external effects. Ordinary local governance may remain in Hypervisor or its domain owner. wallet.network is the canonical portable identity-operation, secret, authority-scope, approval, payment, and revocation layer for autonomous software.

Architecturally, it functions as a Cryptographic Superset. A versioned wallet profile may bind legacy-asset keys, native Web4 authority, classical/PQ mechanisms, guardians, and threshold material without treating one root algorithm as timeless protocol canon. It scales assurance through configurable factor, guardian, quorum, and signature thresholds, allowing the user or organization to define the balance between friction and high-assurance control.

Core Capabilities:

Brokered Secret Execution: Securely governs Web2 secrets (AWS, Stripe, OpenAI, broker APIs, cloud credentials, and similar external capabilities). It enforces a strict security invariant: The agent requests effects, not keys. The wallet.network authority path or configured secret provider never delivers durable raw credentials to the agent; it executes or authorizes the capability exit under a scoped lease and returns only policy-approved results.
Frictionless-to-Fortress Auth: Targets progressive security from low-risk identity-provider/passkey onboarding through device-backed and institutional threshold profiles; guardian and MPC-vault facilities remain planned.
Zero-Trust Extensibility: Provides a programmatic SDK and a sandboxed WASM marketplace for third-party developers to integrate custom API connectors securely.
Unified Authority Audit: Receipted visibility over mediated grant, denial, approval, credential-use, revocation, and applicable spend events. It does not create total observability over opaque models, providers, or unmediated external systems.

Wallet action grammar. wallet.network is not merely a cryptographic keychain. It is the authority wallet for autonomous finance and delegated capability use. Every meaningful action follows a common grammar:

Intent -> Simulation -> Risk labels -> Policy check -> Approval or denial -> Execution -> Receipt

This grammar applies to sends, receives, exchanges, trades, approvals, delegations, revocations, protection actions, secret brokerage, declassification, provider payments, and agent actions. Low-risk actions may run inside a preapproved session envelope; high-risk actions require one-shot or step-up approval bound to the exact request hash, policy hash, grant or lease, revocation epoch, risk labels, and receipt obligations.

The authority pipeline is reusable infrastructure; the full Wallet console is only one presentation of it. Consumer apps may use compact Lite Approval Cards, ordinary Wallet actions may use Standard Wallet Review, and treasury, trading, Hypervisor, or developer workflows may use an Advanced Authority Console with raw receipts, route candidates, policy JSON, traces, and adapter evidence. The underlying contract is the same: intent, simulation, risk and eligibility labels, policy explanation, approval mode, execution handoff, typed receipt, and revocation path.

Wallet authority objects. The reusable pipeline is WalletAuthorityCore: the policy and review engine behind the Wallet app, embedded dapp approvals, agents, Hypervisor prompts, CLI/headless prompts, and advanced consoles. A WalletPresentationProfile changes only presentation, never policy or receipt semantics. Canonical presentation profiles include lite_approval_card, standard_wallet_review, advanced_authority_console, cli_prompt, and mobile_approval_sheet. An ApprovalMode is the policy-derived posture for execution: one_shot_review, session_envelope, batch_review, silent_within_policy, after_the_fact_receipt, step_up_review, or denied. A RiskCoverageState is attached to risk and eligibility labels: Assessed, Unknown, Unassessed, Stale, Partially Covered, or Conflicting Sources. Apps may request a presentation profile or approval mode, but wallet.network derives the allowed mode from policy, risk, eligibility, account posture, and active session state.

Exchange and trade authority. Exchange and trade are first-class wallet actions, but route and venue sources are not trust roots. decentralized.exchange is a preferred first-party route-intelligence engine for asset conversion; direct pools, routers, solvers, aggregators, and user-specified routes may also propose candidate RouteCandidate objects. decentralized.trade is a preferred first-party venue/market/exposure-intelligence engine for spot orders, perps, positions, prediction markets, and event contracts. These engines produce candidates, metadata, risk evidence, simulations, and intent templates. wallet.network evaluates policy, discloses risk, obtains approval, signs or denies, emits typed receipts, and can revoke or protect assets. Pools, venues, and chains perform execution; Agentgres records receipt and evidence state.

Product packaging follows the same boundary. Wallet is the cockpit. decentralized.exchange and decentralized.trade are non-custodial API/RPC/SDK route-intelligence services consumed by Wallet, Hypervisor, agents, and third-party clients. They may expose docs, explorers, adapter registries, paper venues, or lightweight standalone views, but the canonical Wallet user does not need to leave wallet.network to review, approve, deny, execute, monitor, or receipt an exchange or trade action.

Every route, venue, market, position, or prediction candidate must carry CandidateEvidence: candidate id, source, adapter id, observed timestamp, expiry, coverage state, evidence refs, risk labels, eligibility labels, and explicit claims. A candidate without evidence is not approval-eligible. Unknown, unassessed, stale, expired, or conflicting-source candidate evidence cannot execute silently; it must refresh, step up, enter paper mode, or be denied by wallet.network policy.

The semantic wallet objects are ExchangeIntent, TradeIntent, and PredictionIntent. An ExchangeIntent binds route, calldata commitments, slippage, simulation, policy, grants or leases, revocation epoch, economics, risk labels, and exact TxIntent records before a swap can be approved or signed. A TradeIntent binds venue, market, side, collateral, leverage, margin mode, order type, liquidation and funding assumptions, max-loss policy, simulation, grants or leases, revocation epoch, risk labels, and exact venue/order/TxIntent records. A PredictionIntent binds venue, market question, outcome, side, price limit, shares, max loss, max payout, resolution source, market rules, liquidity snapshot, grants or leases, revocation epoch, and risk labels. Long-lived trading state is recorded through typed receipts such as PositionReceipt and PredictionReceipt; position risk and event-resolution risk must not be hidden behind generic swap history.

Asset exposure and protection. Wallet must make risk actionable, not merely descriptive. An AssetExposureRecord summarizes each asset or account’s cryptographic regime, public-key exposure, bridge dependencies, admin-key dependencies, oracle dependencies, approval exposure, agent-access exposure, policy protection level, risk labels, and recommended ProtectionAction refs. Protection actions include revoking or reducing approvals, moving assets to fresher or stronger-policy accounts, isolating agent execution funds from long-term custody, requiring step-up for bridge or public-key exposure, pausing agent grant access, or requiring org quorum for higher-risk routes. Each protection action follows the same authority grammar and emits a ProtectionReceipt.

Approval inbox and typed receipts. wallet.network exposes a unified approval inbox made of ApprovalInboxItem records for step-up requests, policy-widening requests, exchange exceptions, trade exceptions, margin/leverage/perps requests, bridge-use requests, unknown-contract requests, unlimited-approval requests, agent delegations, secret-release requests, declassification requests, high-value transfers, and org quorum requests. Every item must show initiator, requested action, authority risk class, affected assets or secrets, budget, destination, policy diff, simulation result, expiry, and deny/edit/approve paths. The output is not one flat log: wallet actions produce typed receipts such as ExchangeReceipt, TradeIntentReceipt, PositionReceipt, PredictionIntentReceipt, PredictionReceipt, RiskEventReceipt, and ProtectionReceipt, all under a common wallet receipt envelope.

Economic disclosure. Exchange receipts must bind expected output, minimum output, slippage tolerance, pool/protocol/wallet fees, gas estimate, price impact, route source, quote source, execution venue, bridge dependency, solver/RFQ dependency, and MEV/protection mode where applicable. Advanced trade receipts must bind collateral, notional exposure, leverage, margin mode, funding/borrow assumptions, liquidation estimate, venue fees, oracle or mark-price source, max-loss policy, stop-loss/take-profit posture, and eligibility restrictions.

The IOI monorepo owns the wallet protocol packages that make this contract portable. @ioi/wallet-protocol exports wallet protocol objects, method metadata, JSON Schema, OpenAPI, receipt fixtures, and canonical examples tied to Rust wallet types and wallet service tests. @ioi/wallet-sdk is a typed client/helper package over @ioi/wallet-protocol for authority reviews, capability leases, receipts, exchange, trade, and protocol method calls. Product repositories such as wallet.network consume these packages; they do not author canonical scopes, grants, leases, approval modes, receipts, CandidateEvidence, ExchangeIntent, TradeIntent, PredictionIntent, CapabilityLease, or authority semantics.

Agent capabilities and leased credentials. Agents do not hold balances or secrets directly. They receive scoped capabilities such as scope:gmail.send, scope:broker.place_order, or scope:cloud.deploy under time-bounded CapabilityLease objects, caps, and step-up rules. Viewing/decryption rights are distinct from use rights. Every grant, lease, use, denial, expiry, and revocation generates a wallet.network receipt and, where operationally meaningful, an Agentgres-linked receipt.

Access points, guardians, and declassification. Access points (such as web portals, Discord bots, mobile apps, and SMS gateways) are strictly delivery and monitoring interfaces; they are not authority roots.

An SMS notification cannot authorize a transaction or decrypt a workspace. If a high-risk action triggers a StepUpChallenge, the notification channel may only deliver an escalation link. The actual authorization must occur by looping back to a verified, high-assurance client — such as an authenticated phone/local guardian profile, a Local Hypervisor App, or an Enterprise Key Service.

For highly sensitive outputs leaving the private workspace, the client acts as the default private view and declassification point. Any export of protected state across the boundary must generate a DeclassificationReceipt, validating that the data has passed unredaction filters and was signed off by an authorized wallet.network key.

Access assurance hierarchy.


Access Point	Assurance Level	Custody & Signer Status	Decryption Capacity	Primary Threat Vulnerability
SMS / Chat Bot	Low Assurance	None. Cannot sign, authorize, or hold keys.	None. Cannot decrypt any data.	SIM-swapping, API gateway capture, and man-in-the-middle interception.
Browser Web Interface	Medium Assurance	Session-gated. Can hold transient keys in memory.	Restricted to local, sandboxed session storage.	Cross-Site Scripting (XSS), malicious extensions, browser-jacking.
Local App / CLI/headless / optional TUI	High Assurance	Device-bound. Direct access to local OS sandboxing.	Can decrypt local workspace databases.	Local system malware and physical host capture.
Phone / local guardian profile	High Assurance	Hardware-enforced (biometric secure enclaves).	Can decrypt restricted local archives.	Physical device theft (gated by biometric checks).
Enterprise Key Service	High Assurance	Institutional (MPC, multisig, HSM-gated).	Highly restricted, role-based decryption.	Compromise of enterprise administrative credentials.
wallet.network	Root Authority	Root custody policy, key-use authority, policies, and grants.	Generates and manages decryption/viewing leases.	Root credential, recovery, or policy compromise.

7.3.1 Brokered Secret Execution (Capability Execution & Secret Isolation)

Standard agents often require API keys in environment variables, creating massive attack surfaces. The IOI architecture fundamentally rejects this model. To achieve secure automation, wallet.network manages credentials exclusively through Capability Execution:

Storage (Data at Rest): Keys are sealed under the selected versioned vault-encryption and key-derivation profile (which may use an approved construction such as XChaCha20-Poly1305 with an appropriate KDF). The profile keeps durable raw key material inaccessible to agent sandboxes.
Request (The Intercept): When an agent attempts a tool call (e.g., tools/call:stripe), the Hypervisor Daemon sends an AuthorityScopeRequestEnvelope directed at wallet.network.
Capability Execution: The wallet.network Authority Core evaluates the request against the active Policy Envelope. If authorized (and MFA is satisfied), the Authority Core executes the capability internally- making the external API call or signing the transaction itself.
Return (Sanitized Delivery): wallet.network returns only the sanitized result (e.g., the API response) to the agent daemon. The secret never leaves wallet.network**’s authority custody path and never enters the agent’s runtime space.**

7.3.2 The Multi-Factor Identity Model (Frictionless-to-Fortress)

The target wallet profile may use threshold cryptography, guardians, hardware-backed factors, or an MPC vault to support progressive security. Those key-shard and MPC-vault facilities are planned, not current baseline claims:

Level 1 (Frictionless 1FA): An identity-provider or passkey onboarding factor under a declared low-risk policy; it does not by itself mint broad autonomous authority.
Level 2 (Trusted Device 2FA): Mobile biometric enclaves and WebAuthn authenticators can provide a hardware-backed local-user-presence signal under the device vendor’s security model. IOI treats this as a step-up authentication factor, not as a proof of legal identity or an infallible proof of physical presence. Mobile 2FA and SMS channels are classified as notification or step-up transport conduits; they cannot bypass the core cryptographic signature requirements of wallet.network.
Level 3 (High-Assurance 3FA+): A planned configurable threshold or MPC profile using hardware keys, enrolled guardians, HSMs, or enterprise authority with explicit approval thresholds for high-stakes capital movement or policy widening.
Sovereign Backup: Users may use an approved portable recovery profile to exit one wallet.network interface while retaining authority over compatible assets, grants, and worker identities. The export must declare exactly which key families, factors, guardians, and domains are recoverable.

7.3.3 Capability Leases and Short-Lived Signers

To operationalize the hierarchy, IOI implements capability delegation via CapabilityLease-bound short-lived signer grants issued to Tier 3 Workers. These are constrained by an explicit Policy Envelope (specific capabilities + spend limits + target whitelists).

Expiry: Leases and signer grants are strictly time- or block-bounded.
Revocation: Session authority can be revoked by wallet.network Authority Core at any time by advancing the revocation_epoch, instantly invalidating the agent's ability to act or spend.

7.3.4 Delegated Coordinator Profile (Delegated Authority)

For complex multi-worker systems, the user may delegate coordination to a constrained coordinator profile. Unlike a standard Worker, a coordinator may request subordinate CapabilityLease grants for its subordinates, but only through monotonic narrowing, wallet.network authority, and daemon receipts.

Delegation Certificate: To hire a worker, wallet.network Authority Core signs a certificate binding the new Worker's ephemeral key or signer grant to a monotonic narrowing of the parent grant’s budget and policy.
Cascading Revocation: wallet.network retains the root revocation path for active grants. Revoking the parent grant advances the relevant revocation_epoch and triggers cascading termination of all downstream leases, signer grants, and associated payment channels.

7.3.5 Zero-Trust Extensibility Framework

wallet.network supports programmatic extensibility (see Section 7.3 for product surface details):

Permissionless Domain Integration: Any third-party platform can integrate the open @ioi/wallet-sdk to request wallet.network authority reviews, CapabilityLeases, and receipts. The wallet.network authority path cryptographically verifies the origin and requires policy-compatible consent before issuing bounded session authority.
Sandboxed Connector Marketplace: Developers can build and publish new API connectors (e.g., custom CRM or niche banking APIs). These run inside a hermetic WASM sandbox (WASI) injected only with the specific secret required, physically preventing third-party logic from exfiltrating other wallet.network credential material.

7.4 Portable App Sessions and Authority State

Centralized session state (cookies, JWTs against a single database) breaks in a multi-plane architecture where users fail over between provider environments.

IOI replaces centralized session state with Stateless Portable Capability Tokens.

Rather than a node looking up a session in a local database, the client holds a scoped HypervisorSessionAccessLease and derived SessionAccessToken that dictate what canonical state it can read, what projections it can subscribe to, and what mutations it can request.

Authority-bound restore. Portable sessions restore through authority-bound import. A sealed archive may contain task state, run checkpoints, traces, artifact refs, patch branches, projection checkpoints, and replay metadata. It should not silently mutate live truth. The applicable authority provider validates restore power; daemon and Agentgres admission validate the grant/lease refs, hash, policy, schema, state root, object heads, and restore evidence before rehydration.

7.4.1 The Stateless Authentication Flow

Portable session tokens carry an explicit cryptographic envelope containing:

session_id or lease_id
subject_id (The User/Principal) and issuer_id (the wallet.network Authority Core)
policy_hash (The overarching ruleset)
primitive_capabilities, authority_scopes, and projection_scope (what execution classes, delegated power, and Agentgres views are available)
expires_at and revocation_epoch

Because these tokens are self-contained and signed by the user's wallet.network Authority Core, validation does not require the original application database. It still must check current expiry, revocation, audience, policy, and authority state. If the active environment serving an Agentgres projection goes down, the client seamlessly reconnects to a new healthy environment, presents the same portable token, and resumes its subscription stream. The new node validates the signature, expiry, and capability scope against the canonical state without needing a shared backend database.

7.4.2 The Auth Split: Portable vs. Pinned Authority

To balance seamless application failover with strict security for high-stakes actions, the KYA framework enforces a strict bifurcation in how tokens are audience-bound:

Portable Session/Lease Tokens (For App State):

- Usage: Reading Agentgres projections, maintaining resumable subscriptions, and requesting routine workflow mutations.
- Audience Binding: Bound to the logical application instance or runtime identity, not a specific physical node. This ensures cross-node failover for normal app continuity.

One-Shot Approval Tokens (For High-Risk Execution):

- Usage: Sensitive capability execution (e.g., spending funds, signing mainnet transactions, modifying core firewall policies).
- Audience Binding: Tightly pinned to a specific physical executor or authority-profile ID via nonce, counter, revocation_epoch, and strict audience fields. These cannot be ported to another node; they are exact, single-use cryptographic authorizations.

This model separates high-risk authority from the active execution environment. It allows user interfaces to remain fast, distributed, and highly available via Agentgres, while requiring irreversible sovereign actions to remain explicitly gated, audience-bound, and receipt-backed.

7.5 Authority Scope Request Flow

The core architectural doctrine of IOI is that local/domain policy and the applicable authority provider authorize power, the Hypervisor Daemon admits and executes work, and Agentgres records admitted operational truth. wallet.network owns the portable delegated and designated high-risk authority profile. In that profile, Own becomes Act only through scoped grants bound to request_hash, policy_hash, budgets, expiry, and revocation_epoch. The strict wallet.network request flow is:

Request: The agent/runtime encounters an effectful tool node and issues an AuthorityScopeRequestEnvelope to wallet.network. The request declares the required Primitive Capabilities (prim:*) and the requested Authority Scopes (scope:*).
Evaluation: wallet.network evaluates the request against the active policy. If the action exceeds autonomous thresholds (e.g., risk_class: funds_transfer), it triggers a wallet.network step-up challenge.
Issuance: If approved, wallet.network issues an AuthorityGrantEnvelope containing the exact request_hash, allowed scope:* strings, resource constraints (budgets/deadlines), and the current revocation_epoch.
Execution & Receipt: The Hypervisor Daemon executes the tool bounded by that grant, returning a ToolExecutionReceipt that is appended to the Agentgres domain log.

8. Economics and Arbitration

IOI prices verifiable work rather than raw inference, and resolves disputes through staged arbitration rather than open-ended adjudication. This section consolidates the four protocol-level economic mechanisms: the market for verifiable work (8.1), the artifact hierarchy that standardizes accountability across that market (8.2), the agentic core that performs deterministic arbitration when work is contested (8.3), and the pricing model that translates outcomes into metered work credits, contribution receipts, royalties, and settlement (8.4).

8.1 The Broad Labor Substrate (aiagent.xyz)

To support millions of highly specialized vertical execution profiles — ranging from cloud-native software developers to physical warehouse robots — the network abandons bespoke per-industry architecture. Instead, aiagent.xyz provides a generic, highly abstract, scalable substrate for broad autonomous labor.

Rather than hardcoding vertical schemas (such as “finance,” “gaming,” or “robotics”) into the protocol kernel, the system uses a unified, generic ontology. Any task, whether digital or embodied, is defined strictly by its capability requirements, integration drivers, authority scopes, and evidence formats.

The generic layer is the DigitalWorkerOntology: a small set of substrate concepts for workers, tasks, capabilities, authority, integrations, evidence, receipts, safety envelopes, and settlement hooks. Vertical specificity is added by versioned VerticalOntologyPack definitions. A pack may define domain object types, action types, integration surfaces, connector mappings, risk mappings, receipt schemas, benchmarks, forbidden actions, and settlement hooks without changing the underlying Hypervisor or wallet.network authority model. This is how a Discord moderation worker, a Texas Hold’em table assistant, a quant research worker, a prediction-market analyst, and a robotic carwash-prep worker can all share the same substrate while remaining domain-correct.

An IntegrationSurface is the policy and evidence profile for the external environment a worker observes or acts within: chat and community systems, games and platform accounts, browsers and SaaS applications, developer tooling, commerce surfaces, finance and trading venues, local computer-use targets, enterprise VPC systems, webhooks and APIs, voice/SMS access points, robotics and physical environments, vehicle-adjacent work, field service, education, creative media, and support operations. It is not an authority grant. Authority still comes from wallet.network scope:* grants, capability leases, and step-up policy.

aiagent.xyz is not an execution runtime. It is the discovery, packaging, routing, licensing, and accounting layer for the machine economy. The actual execution of a worker’s cognitive loop occurs strictly inside a Hypervisor Daemon running through a local, hosted, enterprise, DePIN, confidential-compute, or HypervisorOS assignment selected by policy.

While aiagent.xyz packages and licenses capability (the worker’s logic, manifest, and tools), sas.xyz packages and escrows outcomes (the completed, verified service delivery).

Generic autonomous labor ontology.


Dimension	Digital Worker (e.g., Software Auditor)	Embodied Worker (e.g., Warehouse Robot)	Abstract Substrate Definition
Domain / Context	std:code:rust_audit.v1	std:logistics:pallet_move.v1	Unique namespace registering the task context.
Capabilities	prim:fs.read, prim:net.request	prim:physical.actuate, prim:sensor.stream	Primitive execution limits (prim:*) requested by the worker manifest.
Integrations	GitHub API, LSP compilers, AST parsers.	ROS2 (Robot Operating System), LiDAR drivers, CAN bus.	Driver mappings used by the Hypervisor Daemon.
Authority	scope:repo.write, scope:slack.notify	scope:zone.access, scope:inventory.mutate	Scoped authority permissions (scope:*) authorized by local/domain policy and the applicable authority provider; wallet.network is required when the scope is portable, delegated, or designated high-risk.
Evidence	AST parse trees, static compilation logs.	Spatial LiDAR point-clouds, motor telemetry logs, safety-zone observations.	Passive output validation artifacts.
Receipts	GateResult receipt refs, linter outcomes.	SensorEvidenceReceipts, ActuatorCommandReceipts, collision-free paths.	Signed records binding declared boundary facts, evidence refs, and assurance stage; a receipt is not automatically verified or accepted.
Safety	String sanitization, code injection blocks.	Workspace boundary limits, physical collision overrides.	PhysicalActionPolicy and SafetyEnvelope admitted by the daemon and independently enforced by the certified local control-and-safety plane.

ManagedWorkerInstance lifecycle. A ManagedWorkerInstance represents a customized initialization of a worker package. Its ManagedWorkerInstanceLifecycle is managed through aiagent.xyz metadata but executed inside a host Hypervisor Node:

1. INSTALL/HIRE - Resolves worker manifest & records licensing rights.

v

2. CONFIGURE - Initializes hot state & binds local environment parameters.

v

3. GRANT AUTH - Emits scoped credentials and keys via wallet.network.

v

4. INVOKE - Spawns the cognitive loop inside the Hypervisor Daemon.

v

5. OBSERVE - Streams execution traces, telemetry, and metrics to Hypervisor clients and application surfaces.

v

6. RENEW / LAPSE - Extends runtime leases or gracefully suspends on expiration.

v

7. ARCHIVE - Seals the workspace into an encrypted state archive.

v

8. RESTORE - Operation-backed rehydration of state into Agentgres.

v

9. REVOKE - Immediately destroys temporary session keys and leases.

ManagedWorkerInstanceLifecycle includes install, initialize, grant authority, assign runtime, active, idle, zero-to-idle, suspend, payment past due, archive, restore, migrate, export, delete, and forget states. A payment lapse may remove compute entitlement or hosted availability, but it must not silently delete user-owned context, encrypted archives, receipts, or restore metadata. Archive bytes may live in Filecoin, CAS/IPFS, S3/object stores, customer cloud, local disk, or provider blob stores, but restore truth remains an Agentgres-backed operation with state roots, archive refs, wallet authority, and receipts.

ManagedAgentConsole. A ManagedAgentConsole is a web projection over a ManagedWorkerInstance for sessions, chat, approvals, receipts, usage, memory, runtime controls, archive controls, and restore controls. It is not an execution runtime, wallet authority surface, or Agentgres truth owner.

Access surfaces. Workers in this lifecycle can be invoked, monitored, and managed across diverse interfaces — web dashboards, chat consoles, programmatic APIs, gRPC endpoints, the Hypervisor App, Hypervisor Web, Workbench, workflow compositor nodes, managed consoles, and terminal-based CLI/headless surfaces. Low-assurance channels such as SMS, chat messages, and voice notifications may summon a review or escalation path, but they do not carry durable authority, decryption keys, private workspace payloads, or unbounded execution grants.

This is how IOI turns heterogeneous workers, services, tools, models, harness adapters, integration surfaces, and vertical ontology packs into a MoW worker economy without making any vertical the protocol kernel.

In Web3, users pay for blockspace. This is the economic form of executable ownership: users do not merely own assets or permissions; they delegate bounded authority and pay only for acts whose receipts can be verified, challenged, and settled. In the Internet of Intelligence (IOI), users pay for verifiable work inside a receipt-native worker economy.

The market for verifiable work has three related supply-side markets:

Workers that perform work.
Training services that create or improve workers.
Benchmarks that determine routing eligibility inside sparse worker categories.

This is what prevents the IOI economy from collapsing into a single model marketplace. The economically relevant unit is not the largest model; it is the worker that can produce the best verified outcome under the relevant constraints.

The question this section answers is: how is the financial risk of agent failure managed? IOI structures agentic labor into two economic modes, each with a distinct risk allocation and evidence requirement.

1. The Outcome-Based Escrow (ServiceOrders)

Best for: Task-based outsourcing, discrete deliverables, and untrusted agents.

In this mode, the user does not buy the agent itself; they buy the outcome. The economic relationship mirrors ordering a bounded service deliverable, with Agentgres receipts and optional IOI L1 commitments supplying evidence and shared finality while the declared payment broker, ServiceOrder, or escrow contract owns funds and remedies.

The Mechanism (ServiceOrder Escrows): The user defines the specific success criteria of the job using a deterministic Intent Schema (e.g., "Output must be valid JSON matching this structure," or "Code must pass this specific test suite"). The user then funds a ServiceOrder escrow on-chain when public/economic settlement is required, or through a local/domain payment broker, work-credit ledger, or provider account when local settlement is sufficient.
Execution: The hired Agent (Worker) performs the computational labor off-chain within a session or provider environment.
Resolution: Upon completion, the Agent submits its final deliverable and cryptographic receipts (the transaction records of the acts that produced the deliverable) to the network's Deterministic Arbitration engine.
Evaluation and Settlement: The declared verifier evaluates the covered deterministic predicates and emits evidence without collapsing verification, acceptance, adjudication, and settlement.
- Predicate satisfied: A schema match proves only conformity to that schema. If the ServiceOrder explicitly makes the covered verifier result a sufficient acceptance condition, all authority, dispute-window, and settlement conditions are also satisfied, the receipt may advance through verified and accepted to the separately recorded settlement transition and release funds.
- Predicate failed or inconclusive: The attempt and its evidence are retained as negative or inconclusive work. Retry, remediation, partial payment, rejection, refund, challenge, or adjudication follows the declared ServiceOrder terms; no receipt or schema mismatch dictates a universal full-refund rule.

The Economic Result: the user does not pay for failed deliverables under the declared ServiceOrder escrow terms. If the AI hallucinates or fails the objective acceptance criteria, the provider wastes compute, and the escrow can refund or remediate according to the contract. Insurance may still matter for subjective, physical, regulatory, or consequential-loss cases, but routine verifiable outcomes can be priced around receipt-backed success.

2. The Service-as-a-Software Model (Embedded Assets)

Best for: Long-running background processes, proprietary enterprise workflows, and highly-trusted models.

This mode represents the pure realization of Service-as-a-Software (SaS). Instead of paying a recurring subscription to access a vendor's dashboard, the user purchases the agent as a portable software asset and operates it continuously as an embedded worker.

The Mechanism (Asset Acquisition): The user acquires the Worker Manifest and deploys it either on their local hardware (Native Hypervisor Node) or on a privately rented cloud instance (Session). The agent becomes a permanent, self-updating employee.
Security (Daemon Effect Boundary): Because the agent is acting continuously on the user's behalf, security is not guaranteed by post-execution arbitration, but by pre-execution deterministic limits. The user wraps the agent in the daemon effect boundary, defining a strict, immutable Policy Envelope.
- Example: The user limits the agent to a maximum spend of $50 per day, restricts its network access to a strict whitelist (api.exchange.com and stripe.com), and requires biometric human approval for any transaction over $10.
Liability ("As-Is" Execution Risk): The agent operates autonomously within this strict sandbox. If the agent hallucinates or makes a poor decision within its legal bounds (e.g., it decides to execute an unprofitable trade but stays under the $50 spend limit), the user absorbs the cost.

The Economic Result: The user accepts the cognitive risk of the agent's logic in exchange for strong local/private data control and no additional public-settlement fees unless a trigger is crossed. Catastrophic financial exposure is reduced through hard spend caps, wallet.network revocation, daemon policy gates, receipts, and smart-account or venue limits rather than through trust in the agent's judgment.

8.1.1 Cryptographic Evidence

Cryptographic evidence makes bounded statements attributable, integrity- protected, ordered, and independently checkable under declared assumptions. A receipt or proof establishes only the bytes, bindings, signer, boundary fact, or proof-system statement it covers. Execution correctness, source authenticity, authorization, compliance, acceptance, and economic value require the corresponding authority artifacts, evidence sources, verifiers, contracts, and later assurance stages; they do not arise from a hash-linked artifact alone.

Execution Receipts

The foundational evidence layer. Every effectful step produces a chain of receipts binding intent to execution:

intent_hash = H(canonical_intent) - tool name, parameter schema, target selectors, risk surface, deadlines.
Per-step hashes chained as a Merkle-linked log: step_i_hash = H(step_i step_{i-1}_hash).

policy_binding_hash = H(policy_version ||
  rule_ids || scopes || exceptions) -

optionally co-signed by the policy authority.

Private-execution evidence receipt, if applicable: a substrate-specific evidence object binding the run to the declared model/program hash, policy hash, input commitments, output commitments, and verifier requirements. This may include TEE attestation quotes, ZK proofs, MPC transcripts, FHE parameter commitments, deterministic replay signatures, or hybrid proof references.

Determinism & Replay Evidence

Enables independent verification that a given execution trace is consistent with its declared inputs:

Canonical input transcript: all tool I/O normalized (deterministic inspection profile / canonical JSON / protobuf canonicalization), hashed.
Deterministic seed receipt: seed_commit = H(seed run_id) with optional commit–reveal for delayed disclosure.
Replay proof: re-execution by an independent verifier confirms the transcript hash matches, signed by the verifier.

Data Provenance & Integrity

Binds the declared lineage and integrity evidence for artifacts consumed or produced during execution:

Content-addressed artifacts: blobs stored by hash (IPFS / Arweave / local CAS); receipts reference content_hash.
Merkle inclusion proofs: prove an artifact was part of a larger bundle or log.
Source authenticity: upstream signatures (signed packages, TLS certificate pin evidence, signed documents) proving "came from X."

Human Authorization & Keying Evidence

Records the declared approval and delegation chain from user or organization to worker. Signature validity does not by itself prove informed understanding, legal consent, or that the signer held authority outside the referenced policy:

User consent receipt: signed approval over the intent hash + scope + expiry (session key, passkey, wallet signature).
Delegation / session key chain: parent key → delegated key (capabilities, TTL) → action signature.
Quorum approval (optional): M-of-N signers for high-risk actions.

Privacy & PII Minimization Evidence

Supports evaluation of declared data-handling obligations without revealing the protected data itself. The evidence proves only its specified statement under its capture and verifier assumptions:

Selective disclosure receipts: hashes and redacted strings with a redaction_manifest_hash describing what was removed.
Proof-of-scrub: cryptographic commitment to raw input in a sealed vault; only the scrubbed transcript + hash pointers are published (auditors can verify under legal process).
Egress allowlist receipts: signed statement that outbound domains/targets were permitted by policy at the relevant version.

External Anchoring

Anchors the receipt chain to external time and storage to prevent retroactive falsification:

Append-only log anchoring: periodic commitment of the Merkle root of receipts to a chain or transparency log.
Timestamping: RFC 3161 timestamp token or chain timestamp; binds receipt existence to a verifiable time window.

8.1.2 Dialectic Evidence

Dialectic evidence addresses policies that are not purely mechanical, e.g., "don't be deceptive," "don't collect sensitive info," "don't violate ToS", where compliance is contextual rather than binary. The protocol defines a structured adversarial process to resolve these claims.

Claim–Challenge–Response

The atomic dispute unit. A structured three-phase exchange that bounds the scope of inquiry:

Claim: "Action A complied with policy P under context C," with references to cryptographic receipts (hashes only if privacy-sensitive).
Challenge: Adversary submits a specific alleged violation and bounded evidence requests.
Response: Agent reveals minimal additional evidence (selective disclosure) or produces a counter-argument.

Dialectic Transcripts with Commitment

Ensures the full record exists before selective disclosure begins:

Commit to the full private transcript hash up front.
Run the debate on redacted excerpts.
If escalated, reveal additional evidence under controlled rules; every reveal is itself receipted.

Adversarial Spot-Check Audits

Randomized sampling that makes log forgery probabilistically detectable:

Randomly sample steps or episodes from the execution trace.
Require the agent to produce witness bundles (inputs, intermediate state summaries, tool outputs) for the sampled steps only.
Penalize inability to produce consistent witnesses (detects missing or forged logs).

Multi-Judge / Jury Verification

Panel-based adjudication for claims requiring contextual judgment:

A panel (human, model, or hybrid) votes on compliance.
Judges sign an attestation over: (policy_hash, claim_hash, evidence_bundle_hash).
Optionally weight judges by stake or reputation.

Counterfactual Tests

Forces the agent to justify its choices against plausible alternatives:

Verifier proposes an alternative compliant action A' and asks: "Why wasn't A' chosen?"
Agent must provide bounded rationale linked to planning receipts (e.g., constraint satisfaction, tool availability, risk scoring).

Remedy & Liability Outcomes

Defines the enforcement actions triggered by an upheld violation:

If violation upheld: generate a Fault Receipt (verdict + violated_rule_ids + impacted_artifacts).
Trigger automated remediation: revoke session keys, rotate secrets, quarantine artifacts, compensate affected party, each action receipted.

Evidence-Bounded Liability and Assurance

Liability, coverage, eligibility, and commercial assurance must be based on the declared contract, risk class, authority, custody posture, evidence completeness, replayability, verifier results, jurisdiction policy, and applicable EcosystemAssuranceProfile—not on whether the cognition backend is open, closed, hosted, or local.

Provider-trust or opaque routes: May be admissible when the policy, disclosure, data class, contract, and assurance profile permit them. Their evidence limitations, custody transfer, retention posture, inability to reproduce private cognition, and any required compensating controls must be explicit.
Reproducible or custody-proven routes: Local, open-weight, user-controlled, measured proprietary, hardware-confidential, cTEE/private-workspace, or deterministic module paths may produce stronger evidence for particular claims. They do not receive automatic safety, correctness, certification, insurance, or liability status from source class alone.

An assurance or claims workflow uses a LiabilityClaimRoute to bind the incident, evidence bundle, parties, policy and contract refs, optional external claim refs, and dispute or settlement refs. It routes evidence; it does not adjudicate coverage or turn a receipt into proof of a real-world outcome.

The Progressive Assurance Default

All products and economic projections preserve one assurance ladder:

receipt / attestation $\rightarrow$ evidence bundle $\rightarrow$ verification $\rightarrow$ acceptance $\rightarrow$ adjudication $\rightarrow$ settlement

The stages are not generic trust “levels” and are not automatically upgraded by changing provider, hardware, bond, or deployment venue. A receipt is an authenticated statement about one declared boundary fact. Evidence supports a claim. Verification applies a named rule and version. Acceptance belongs to a user, customer, domain, or counterparty. Adjudication resolves a challenge under a declared policy. Settlement moves rights or value under an accepted or adjudicated claim. Risk policy decides which stages and evidence profiles are required, so assurance cost scales with consequence rather than every intermediate cognitive step.

8.1.3 Worker Training as Verifiable Work

Worker training is itself a Service-as-a-Software outcome.

The customer does not merely buy a fine-tuned model. The customer buys a trained, benchmarked, policy-bound worker capable of performing a scoped task under receipt obligations.

A worker training engagement produces:

workflow traces
examples and counterexamples
DomainOntology refs
CanonicalObjectModel refs
DataRecipe and ConnectorMapping refs
PolicyBoundDataView refs
DistilledOntologyDataset refs
EvaluationDataset refs
TrainingBatchPlan refs
RawBatchArchive refs for sealed or reproducible batch inputs
QualityGateReport refs for verifier, filter, and benchmark thresholds
ModelCapacityProfile refs describing model/runtime limits, context capacity, routing posture, and benchmark fit
TrainingCostLedger refs for spend, provider, route, and settlement accounting
TransformationReceipts and TrainingReceipt records
policy envelope
WorkerManifest
benchmark report and BenchmarkReceipt
EvaluationReceipt records
RoutingDecisionReceipt records when worker or model routing materially affects the result
deployment package
optional aiagent.xyz listing
optional sas.xyz outcome wrapper

Training may include model fine-tuning, but fine-tuning is not required. A worker can be trained by improving its prompts, skills, retrieval corpus, verifier gates, tool policies, workflow graph, domain ontology, data recipes, memory/retrieval plane, route policy, or fallback strategy.

A canonical training envelope MAY describe a Synthetic Bootstrapping Pipeline.

One important Worker-creation pattern in the IOI ecosystem is the generation of synthetic datasets to specialize local models. In this pattern, a high-reasoning Planner defines the task domain, schema, rubrics, and edge cases; Generator workers produce candidate examples or traces; Verifier workers and deterministic gates filter the corpus; and the resulting dataset is used to fine-tune, distill, configure, or benchmark a specialized Worker.

The canonical flow for this pattern is:

Define Intent Schema → Planner Scopes Dataset → Generators Produce Synthetic Corpus → Quality Gates Filter Corpus → Fine-Tune → Bind Policy Envelope → Emit EvaluationReceipt → Deploy as Worker

IOI does not require synthetic data, fine-tuning, or any specific model architecture. It requires that claims about training, evaluation, specialization, and deployment be represented through auditable envelopes and receipts. By tracking these inputs, IOI treats the creation, specialization, and evaluation of Workers as a fully auditable, receipt-backed workflow.

The first commercial wedge for MoW is therefore not “buy an agent marketplace.” It is:

Train a specialist AI worker for a defined outcome.

This creates the supply side of the Internet of Intelligence before the marketplace is fully liquid.

8.1.4 Service Outcomes & the Contracting Surface (sas.xyz)

sas.xyz is the service-outcome domain. It is not merely a smart-contract frontend. It registers and monitors ServiceOrders, OutcomeWorkspaces, TaskGraphs, Runs, WorkerInvocations, DeliveryBundles, EvidenceBundles, Approval records, DisputeRecords, QualityRecords, and SettlementMirrors. Operational truth and execution state, however, are owned by the Hypervisor Daemon and Agentgres, not by the marketplace surface itself. Consequential commitments settle or mirror to IOI L1 where escrow, fees, disputes, or public trust require it.

To enable a robust, transaction-safe machine economy, the protocol establishes sas.xyz as the sibling marketplace and contracting surface for ServicePackages and verified outcomes.

While aiagent.xyz packages and licenses capability (individual workers, manifests, and tools), sas.xyz packages and escrows outcomes (the contractual delivery of a completed task). sas.xyz is not downstream of aiagent.xyz; it is a peer surface. A ServicePackage does not depend on aiagent.xyz workers: it is a portable, fully configured outcome system that can be composed of local workers, deterministic tools, direct model APIs, nested service packages, or no marketplace-registered workers at all.

When a customer purchases an outcome, the ServicePackage is instantiated as an active ServiceEngine within a secure OutcomeWorkspace.

Outcome execution, delivery, and settlement. The ServiceEngine governs execution of the active package, running it under a strict set of harness profiles, model/tool bindings, authority scopes, Agentgres projection configurations, and verification rules. The contracting cycle operates through a secure, receipt-backed state machine:

1. Escrow Initialization: the buyer locks funds inside a ServiceOrder escrow, on IOI L1 when public/economic settlement is required or through a local/domain payment broker, work-credit ledger, or provider account when local/domain settlement is sufficient.

2. Execution: the ServiceEngine executes the task, recording all traces, observations, and tool invocations inside Agentgres.

3. Delivery Assembly: upon completion, the ServiceEngine packages results, artifacts, and verification metadata into a signed DeliveryBundle.

4. Delivery Acceptance: the buyer evaluates the DeliveryBundle against the active Success Schema; if valid, the escrowed funds are released.

5. Dispute and Remediation: if the deliverable fails verification or violates active policy, the buyer submits a contract-defined dispute and evidence package, triggering the selected verifier, adjudication, and appeal path. Local/domain service contracts may resolve through Agentgres-backed dispute state, provider accounts, or work-credit ledgers; IOI L1 or a compatible settlement chain is used when the ServiceOrder selected public/economic settlement, bond slashing, rights, reputation portability, or cross-domain enforceability. Automated, receipt-driven remediations (key revocation, developer bond slashing, or immediate refunding) follow the verdict.

For composed services, acceptance and dispute review operate over a ServiceCompositionReceiptBundle rather than raw delivery blobs, token logs, or provider logs alone. The bundle binds composition graph refs, routing receipts, contribution receipts, verifier refs, policy receipts, private-data posture, dispute evidence refs, Agentgres operation refs, and state roots. This makes nested workers, providers, verifiers, private workspace posture, and delivery claims attributable without making sas.xyz the runtime, wallet, storage authority, or contribution oracle.

Service terminology.


Term	Current Canon Definition	Relationship to Substrate
ServiceModule	Reusable execution component, deterministic module, workflow component, or service definition invoked through a ModuleInvocation or StepModuleInvocation.	Lower-level execution unit under daemon gates; may be used inside a ServicePackage but is not the packaged outcome itself.
ServicePackage	A portable, fully configured outcome system containing task definitions, success rubrics, and tool bindings.	Declared on sas.xyz. Exists independently of specific runtimes or marketplaces.
ServiceEngine	The active, instantiated execution environment of a ServicePackage run by a Hypervisor Daemon.	Enforces harness, model, Agentgres, and verification policies.
OutcomeWorkspace	The isolated local context (sandbox) where a ServiceEngine executes its tasks.	Monitored by the Hypervisor Daemon; writes state logs to Agentgres.
DeliveryBundle	A cryptographically signed package containing the final deliverables, artifact references, and execution receipts.	Submitted to the buyer/settlement contract for acceptance verification.
WorkerPackage	A declarative, capability-oriented manifest containing model requirements and logic (prim:* and scope:*).	Registered on aiagent.xyz; represents labor capacity rather than a contracted outcome.

A typical sas.xyz outcome flow:

buyer funds or escrow locks

-> sas.xyz Agentgres creates ServiceOrder

-> OutcomeWorkspace initializes

-> router selects workers and compute provider

-> runtime assignment provisions daemon-compatible execution

-> workers execute toward delivery goal

-> receipts, artifacts, checkpoints, and evidence are emitted

-> the sas.xyz Agentgres domain admits outcome operations, receipts, delivery state, and archive refs

-> idle state may seal into archive

-> buyer approves or disputes

-> the applicable settlement rail resolves triggered commitments

8.2 Evidence and Artifact Roles

This section synthesizes recurring evidence roles; it is not a master schema owner or a universal liability ladder. Canonical object/envelope, event/receipt, Agentgres artifact-ref, marketplace, assurance, wallet, and L1 documents own exact types and wire formats.

The canonical events-and-receipts owner governs the shared ReceiptEnvelope base, the exhaustive receipt-type registry, cross-component receipt profiles, lifecycle, and assurance semantics. Domain receipts extend that base; they do not redefine receipt identity, policy or authority binding, Agentgres admission, assurance stages, or what proof means. The shared base names the receipt profile and attested boundary facts and provides separate evidence-bundle, verification, acceptance, adjudication, and settlement refs so later states cannot be inferred from receipt existence.

Events observe. Runtime events support streaming, debugging, progress, and analytics. They do not authorize effects or prove that a consequential crossing occurred.
Receipts prove declared boundary facts. A receipt binds the request, policy, authority decision, actor, result, evidence refs, and verifier coverage declared by its type. Its proof is no broader than those fields, evidence sources, and threat-model assumptions.
Artifacts and payload refs preserve bytes and meaning. Agentgres admits ArtifactRef/PayloadRef meaning and lifecycle; storage backends hold the bytes. EvidenceBundle and DeliveryBundle objects compose the refs needed for verification, delivery, audit, or dispute.
Commitments and settlement envelopes are sparse projections. Domains may commit selected roots for public registry, rights, reputation, escrow, dispute, or settlement triggers. Ordinary run history remains in its local/domain truth substrate.
Analytics improves. Cost, latency, quality, failure, benchmark, routing, and adoption signals improve products and the Verified Work Graph; analytics never substitutes for authority, receipts, or admitted truth.

TrainingReceipt, BenchmarkReceipt, EvaluationReceipt, RoutingDecisionReceipt, ContributionReceipt, provider, custody, physical-action, and settlement receipt families specialize those owner contracts for their domains. A named receipt does not automatically establish completion, liability, payment, safety, or legal fault; the applicable contract declares the required evidence and verifier path.

Exact wire formats remain with the canonical owners. Appendix B is a non-exhaustive synthesis for orientation and does not create a second schema authority.

8.2.1 Required Receipt Profiles

Each action, workflow, delivery, private-execution, marketplace, or settlement contract declares the receipt and evidence profile required for its risk class and claim. The canonical event/receipt owners govern exact types; this whitepaper does not create separate global intent/action receipt namespaces.

Coordination and completion evidence: GoalRun, verifier-path, OutcomeRoom, participation and lease, frontier and claim, attempt and finding, WorkResult and OutcomeDelta, delivery, contribution, artifact, and terminal-state refs required to support a claimed workflow or outcome.
Action-level evidence: ActionProposal, GateResult, authority, policy, execution-result, normalized-observation, receipt, and artifact refs required for the admitted effect.
Domain-specific evidence: Additional custody, payment, external-system, physical-action, training, benchmark, routing, service, or settlement evidence required by the governing profile.

Illustrative domain-specific receipt obligations

For an action to pass the Deterministic Gate and be eligible for completion, delivery, or an implemented settlement profile, the runtime must record the common boundary objects plus the evidence required by its target domain:


Action Domain	Domain-Specific Required Evidence	Verification Enforced
UI / Browser	action, target/window, visual or DOM observation, policy, authority, and result refs	Binds the declared observable interface state to the action; it does not prove unseen UI state.
Filesystem	path scope, diff or content commitment, policy, authority, and result refs	Makes accessed paths and changes inspectable; sandbox conformance supports the containment claim.
Network (Web)	destination, request/response commitment, policy, authority, and result refs	Binds the declared target and response to the action under the network policy.
Wallet / Smart Contract	exact intent, simulation, authority/approval, transaction, external-evidence, and result refs	Binds the approved intent and observed transaction result under the wallet contract.
Private-Execution Compute	custody posture, input/output commitments, model/program ref, verifier requirements, proof/attestation refs, leakage and declassification receipts	Binds the action to the declared private-execution evidence profile and requires the receipt bundle to satisfy the verifier requirements for the action class. Substrate evidence may be TEE, FHE, MPC, ZK, deterministic replay, or hybrid.

Normative Invariant (The Completion Gate):

If a run lacks evidence required by its declared profile, the runtime MUST NOT report verified completion. It emits an explicit partial, unverified, blocked, or failed terminal state and the applicable contract decides any delivery, payout, dispute, or settlement consequence.

Additional evidence families for worker training and MoW routing

Worker Training:

training specification and authority refs
dataset, policy-bound view, provenance, and consent refs
evaluation rubric and verifier refs
training output, cost, lineage, and receipt refs

Benchmark Execution:

benchmark profile and version
worker manifest and runtime refs
evaluation environment and dataset refs
score, verifier, and evidence refs

MoW Routing:

routing policy and version
candidate set and evidence coverage
selection reason, fee basis, and decision receipt
contribution policy and attribution refs

Missing any required worker-training, benchmark, or routing receipt renders the associated training result, leaderboard claim, or routing decision economically non-enforceable.

8.3 Dispute and Recourse Contracts

IOI does not define one universal Arbitration Core, fixed judiciary, or deployed adjudication lane. Each ServiceOrder, marketplace transaction, provider contract, assurance profile, or future L1 settlement profile declares the claims that may be disputed, applicable evidence, verifier versions, remedies, appeal path, jurisdiction, and party authorized to decide.

The default evidence order is narrow:

validate signatures, authority and policy bindings, receipt coverage, ordering, inclusion, and the exact claims supported by the evidence profile;
run objective contract checks such as schema validation, tests, hashes, budgets, delivery conditions, or external-proof verifiers;
use constrained semantic review only where the contract declares a rubric, evidence boundary, abstention rule, versioned evaluator, and appeal path;
escalate ambiguity, legal interpretation, physical-world facts, insurance coverage, or uncovered claims to the declared human, institutional, or legal process.

A receipt proves its committed fields and covered verifier result, not model wisdom, complete context, legal fault, physical truth, or insurance coverage. Ecosystem Assurance makes evidence and conformance posture legible but does not adjudicate claims. A future IOI L1 may execute or anchor opted-in dispute, escrow, bond, rights, and remedy contracts without becoming the universal judge for local or sovereign domains.

8.3.1 Evidence, Adjudication, and Typed-Refusal Profiles

A dispute profile may choose deterministic checks, independent verifiers, committee or institutional review, human review, or a combination suited to its threat model. This whitepaper does not prescribe a three-lane funnel, model ensemble, confidence threshold, quorum algorithm, arbitration registry, or universal dispute YAML. Exact schemas and remedies belong to the applicable marketplace, settlement, assurance, wallet, event/receipt, and legal contract owners.

A model, tool, provider, venue, connector, policy gate, or authority provider may refuse a request. Refusal is a typed execution result, not automatic developer fault, user fraud, or permission to route around policy. Any repair opens a new proposal or route decision and re-evaluates authority, privacy, data custody, provider trust, budget, and receipt obligations. If no admissible route remains, the runtime records a blocker or failure and the governing contract determines refund, incurred-cost, bond, reputation, escalation, or terminal treatment.

Implementation status. Automated IOI L1 dispute adjudication, slashing, and universal arbitration registries are speculative; no deployed IOI L1 or fixed arbitration judiciary is claimed.

8.3.2 Hybrid Execution Model

IOI composes probabilistic reasoning with deterministic settlement.

Agentic Phase: An AI model processes fuzzy inputs (e.g., "Analyze market sentiment from news feeds").
Boundary Crossing: Probabilistic intent collapses into a canonical ActionProposal that receives a GateResult and, when admitted, an ExecutionResult or typed receipt with authority, policy, evidence, and replay bindings.
Settlement Phase: The transaction-shaped act record is passed into deterministic contract logic (EVM/WASM) for value transfer, escrow resolution, or dispute handling.

Visual summary:

AI handles decision-making; the Hypervisor Daemon and settlement kernel enforce the deterministic boundary that makes the consequence settleable. This is how Own becomes executable without making the model itself deterministic.

8.3.3 Marketplace Neutrality: The Anti-Cannibalization Invariant

A neutral MoW worker economy cannot exist if the infrastructure provider competes with its own supply chain. If Hypervisor silently favors its own harness adapter, worker, or service path over better declared options, it cannibalizes marketplace workers and destroys the incentive for developers to publish specialized intelligence.

IOI enforces Marketplace Neutrality as a core architectural invariant:

The Neutral Substrate: The Hypervisor Daemon is the neutral execution substrate, not a privileged competitor; the Default Harness Profile is only the reference scaffold and fallback HarnessProfile, with no substrate mechanics of its own. It is forbidden by conformance, policy, and marketplace-neutrality doctrine from silently cloning or absorbing third-party worker internals into its default logic.
Explainable Routing: When Hypervisor Core, the Workflow Compositor, a selected HarnessProfile, MoW router, or service router selects a path to fulfill a task (whether the Default Harness Profile, an installed worker, a marketplace worker, a service outcome, a local module, or a hybrid composition), the routing decision MUST be explainable to the user and receipt trail based on declared policy: quality, cost, privacy, latency, required tools, installed status, service guarantee, trust posture, benchmark evidence, or reputation.
Opt-In Service Redirection: Users retain the right to run tasks locally via the default harness unless the task strictly requires licensed data, third-party authority, or hosted execution. Service redirection is strictly opt-in.
No Platform Fiat: The Default Harness Profile, a first-party worker, or a bundled service cannot rank itself first in marketplace discovery through platform fiat. Ranking must be based on measurable quality, reputation, policy fit, privacy, availability, and cost signals.
MoW Router Neutrality: The MoW router is subject to the same neutrality requirement as marketplace discovery. Routing preference must be based on declared policy, benchmark performance, cost, privacy, trust posture, installed status, or user preference. The runtime MUST NOT privilege first-party workers through hidden ranking logic, opaque bundling, or unreceipted substitution.

8.3.4 Contribution Accounting: The Attribution Graph

To ensure developers are compensated when their specialized logic is utilized within a larger autonomous workflow, Agentgres implements precise Contribution Accounting.

When a Planner Agent delegates a sub-task to a specialized Worker, or utilizes a specific Tool/Model, the runtime emits a ContributionReceipt.

ContributionReceipts are attribution records in MoW economics, not automatic proof of causality, quality, value, acceptance, or payout. Payouts, royalties, reputation updates, and routing weight follow the applicable contract and must preserve the contribution’s evidence, assurance, acceptance, adjudication, and settlement stage. Ordinary Goal Space Work Credits meter managed product usage; they are not distributed to contributors.

The ContributionReceipt records:

The Contributor Identity (ai://workers.xyz)
The Contribution Type (e.g., verification, generation, planning, tool usage)
The Input and Output Artifact References
The Quality Delta (the measurable improvement the worker provided to the workflow)
The Reward Basis and License Terms

For MoW settlement, the ContributionReceipt MAY also record:

routing_decision_ref
sparse_worker_category
benchmark_profile_ref
verifier_worker_ref
failure_or_dispute_status
downstream_outcome_ref

These receipts form an Attribution Graph, the contribution and payout projection of the broader Verified Work Graph, within the relevant Agentgres domains. They support:

Usage and Payout Accounting: Driving approved fiat, stablecoin, IOI, credit, royalty, or other payout rails. IOI L1 receives only the selected public, economic, rights, reputation, or dispute commitments that require it.
Reputation Updates: Feeding quality ledgers so that highly effective workers organically rise in marketplace rankings based on proven outcomes, not marketing.
Dispute Traceability: Allowing Arbitrators to pinpoint exactly which node in a multi-agent supply chain failed, ensuring liability falls only on the responsible party.

The IOI protocol doctrine is strict: The platform must route intelligence, not absorb it.

Incentive-Compatible Contribution Without IP Disclosure: IOI does not require developers to open-source their models, weights, prompts, or datasets in order for the network to improve. A developer who creates a superior verification Worker, planning Worker, data-curation Worker, or domain-specialist Worker can expose it through a manifest and policy-bound interface while retaining the underlying IP. Contribution accounting allows such Workers to receive attribution and compensation when routed into larger workflows, synthetic-data pipelines, or execution graphs. The network improves because useful intelligence is economically routable, not because participants are assumed to share gradients without compensation.

8.4 Economics: Pricing Verifiable Work

This section specifies the economic boundary of the IOI product and protocol stack. Product surfaces monetize useful autonomous work, managed execution, distribution, governed trust, verified outcomes, routing value, private managed posture, and value movement. Verification, authority, receipts, and routine Agentgres operations are bundled substrate and must remain independently inspectable rather than becoming toll booths.

The open/protected split follows the trust boundary. The open verification layer includes protocol contracts, receipt schemas, authority envelopes, portable memory format, adapter contracts, SDK interfaces, and conformance fixtures required to verify IOI’s honesty offline. The protected local runtime layer may include the local Hypervisor core, Agentgres runtime implementation, wallet authority daemon, and provider adapter runtime. The proprietary network/operations layer may monetize hosted ioi.ai, managed compute, private runtime, routing and placement intelligence, cross-party Verified Work Graph aggregation, marketplace reputation, billing, procurement, support, and enterprise or compliance operations.

WorkCredit is the broad product usage and budget abstraction for managed autonomous work. It may meter model, runtime, provider, connector, private-workspace, storage, replay, Foundry, Automation, conductor, marketplace, service, verifier, or audit cost when those create managed product cost. Work Credits are bounded and non-transferable product credits, not cash, Worker payout, pooled provider seats, a claim on provider tokens, the IOI protocol token, or necessarily the final settlement asset. Token or BME mechanics follow only after verified-work demand, marketplace liquidity, and real public-settlement needs exist.

The canonical commercial shape is one Goal Space with two supply lanes:

Goal Space subscription: persistent conductor and goal state, portable memory, policy, receipts, replay, collaboration, ordinary support, provider-neutral Auto routing, and a bounded monthly grant of Work Credits.
Additional managed work: Work Credit top-up, opt-in overage, or committed-spend drawdown for heavy multi-session, model, compute, storage, connector, verifier, training, or background work.
Network / Open participation: a separately bounded NetworkGoalBudget, bounty, procurement cap, or sas.xyz ServiceOrder for independent Workers, verifiers, services, challenges, and settlement.
Enterprise / Private: seats plus committed managed-work spend, customer-boundary or private runtime, reserved capacity, administration, governance, audit, retention, residency, service level, and support.

One logical Hypervisor domain may schedule many Workers across machines, clouds, model providers, and failure domains while remaining one authority, truth, and settlement domain. Node count is not the SKU. Same-domain 1–N orchestration may use GoalRun and OutcomeRoom coordination under the bounded Work Credit budget, but it does not manufacture multi-party federation. Independent participation is opt-in, explicitly admitted, affiliation-visible, and separately funded.

Three product controls remain orthogonal. Execution/custody selects Standard or Private posture; contributor scope selects My Workers, Organization, or Network / Open; and placement selects local, customer infrastructure, a chosen provider, or Hypervisor-selected placement. Contributor scope never declassifies data, widens authority, relaxes retention or export policy, or changes custody promises. Every candidate satisfies the intersection of Goal Space and home-domain policy or remains ineligible.

Managed worker pricing may include:

install or license fee;
per-invocation fee;
warm runtime subscription;
persistent runtime subscription;
zero-to-idle restore fee;
storage/archive fee;
model/provider usage;
compute provider fee;
verifier/evaluator fee;
worker author royalty;
marketplace/distribution fee or explicitly triggered public-settlement fee.

Settlement should remain receipt-bound through WorkerInvocationReceipts, RuntimeAssignmentReceipts, ComputeSessionReceipts, StorageArchiveReceipts, RestoreReceipts, EvaluationReceipts, ContributionReceipts, and SettlementReceipts.

8.4.1 The Economic Shift: Paying for Outcomes, Not Just Compute

In the commodity inference model, users pay for compute cycles. Value accrues to hardware, not to the orchestration or verification of work.

In the Web4 IOI model, users can purchase governed work or contract for an accepted outcome under declared evidence, verification, acceptance, remedy, and settlement terms. A receipt binds attributable boundary facts; it does not make an output correct or payable by itself. Where a ServiceOrder or escrow is used, release follows the implemented contract’s verification, acceptance, adjudication, and appeal semantics.

This mechanism establishes a Market for Verifiable Work, effectively decoupling the computational cost of inference from the economic value of the executed task.

Developer Economics

IOI captures the economic sweet spot between Services and Software.

Services have high value (doing the work) but low margins (humans don’t scale).
Software has low value (just a tool) but infinite margins (zero marginal cost of replication).

Service-as-a-Software combines the utility of a service with the replicability of governed Worker and Service packages. Developers may publish versioned capability once and earn invocation, license, service, or contribution revenue under declared terms without operating every runtime themselves. Receipt-bound metering and contribution accounting make that asset class economically legible.

8.4.1.1 The Liquidity & Orchestration Layer (Product and Network Operations Revenue)

IOI products and network operations sustain themselves by monetizing useful outcomes, managed execution, distribution, governed trust, routing value, assurance, support, and value movement—not by extracting rent from local execution or substrate primitives.

1. Provider Orchestration as Product / Network Operations Revenue

Whenever a user's local node lacks the precise computational resources (for example VRAM, storage durability, latency, or confidential-compute posture) to run a Worker Manifest, Hypervisor may deploy the workload through a direct provider integration or a candidate source such as decentralized.cloud. The pricing boundary follows the value Hypervisor actually supplies:

Direct local or direct self-managed BYO: no percentage fee on provider spend. Subscription, collaboration, governance, support, or control-plane value may still be priced explicitly.
Pinned or BYO-through-Hypervisor lifecycle: a visible adapter/orchestration, credential-brokerage, custody, restore, monitoring, support, or audit fee is legitimate when Hypervisor actually performs that work. It is not an optimized-routing fee.
Optimized placement: a routing or procurement fee is legitimate only when Hypervisor creates real comparison, procurement, failover, reconciliation, or aggregation value and emits challengeable placement/routing evidence.
Managed infrastructure: when IOI or a partner is provider-of-record, Work Credits, managed-runtime margin, reserved capacity, and support pricing are legitimate because the provider bears procurement or operational risk.

2. Swap Spreads & Liquidity (Wallet Revenue)

The user-facing wallet.network treats exchange as a first-class authority action. Route candidates may come from decentralized.exchange, direct pools, routers, solvers, aggregators, or user-specified paths. Liquidity is provided by venues and pools, not by wallet.network itself. wallet.network evaluates risk, policy, simulation, approval, signing, and receipts, and may capture a transparent convenience or route fee where policy, disclosure, and local law permit.

8.4.2 Stakeholder Alignment

This model aligns incentives across the core stakeholders of the automated economy:

Users (Demand): Purchase verified outcomes. They utilize ServiceOrders, outcome escrows, and delivery acceptance rules to make payout conditional on successful, receipt-backed work under the declared contract. They maintain data sovereignty because protected state is governed by Agentgres artifact refs, wallet.network authority, and Private Workspace/cTEE posture rather than hidden developer servers.
Providers (Supply): Earn revenue for providing compute, storage, readiness, and confidential/private execution posture, fulfilling offloaded sessions through local, cloud, DePIN, TEE/confidential-compute, cTEE/private workspace, or customer-owned provider lanes.
Developers (Creators): Earn royalties when their WorkerPackages, ServicePackages, connectors, evaluators, or ontology assets are invoked under their package/license terms, without ever incurring idle server costs or exposing proprietary payloads beyond the selected custody profile.
Payment Brokers / Work-Credit Issuers (Liquidity): Optional bridges between product billing and protocol or provider settlement. They may account for fiat subscriptions, enterprise invoices, prepaid credits, stablecoin reserves, or marketplace escrows, but wallet.network or the applicable local/domain authority still authorizes budgets, grants, revocation epochs, and receipts. They can provide working capital for provider sessions without forcing routine local/domain operations onto a public chain.
Future dispute operators or verifiers: An implemented public dispute profile may pay explicitly contracted verification or resolution fees. No live IOI L1 arbitration-node market is asserted.

8.4.3 Metered Work Credits and Itemized Charges

Work Credits debit a product usage budget; they do not force every run into one universal settlement formula. Charges are itemized only when the corresponding value or cost exists:

Provider pass-through: Customer- or product-borne model, compute, API, storage, network, or other provider cost, shown separately from IOI fees.
Product/control-plane subscription: Hypervisor, ioi.ai, collaboration, governance, memory, Provenance, support, or enterprise product value.
Adapter/lifecycle fee: Visible credential-brokerage, provisioning, lease, snapshot, restore, monitoring, teardown, custody, audit, or support work for a pinned or BYO venue.
Managed-capacity charge: Provider-of-record compute, reserved capacity, private managed runtime, or operational/support margin.
Optimized-routing fee: Actual comparison, procurement, matching, failover, reconciliation, or aggregation value supported by challengeable routing or placement evidence.
Marketplace/license/royalty charge: Declared distribution, procurement, licensing, worker, service, package, connector, evaluator, ontology, or other eligible contribution value.
Triggered public settlement/dispute charge: Fees for an implemented registry, rights, reputation, bond, escrow, dispute, governance, or settlement contract only when that public boundary is selected.

The accountable charge is the sum of supplier model/accelerator/compute cost; sandbox, storage, connector, environment, and replay cost; external Worker, verifier, or service cost; and the declared IOI managed-work and orchestration charge. The user-facing rate card may normalize those inputs, but the receipt ledger preserves the actual Worker composition, model/provider/endpoint and route, price schedule, token or compute categories where available, attempted and billed fallbacks, verifier/escalation reason, supplier or broker cost class, IOI fee basis, adjustments or refunds, and total Work Credits. Customer BYOK, BYOA, customer-cloud, self-hosted, or local execution is not charged again for supplier cost already borne by the customer.

Auto / 1-of-N, Pinned, and Compare / N-of-N are execution policies, not plan tiers. Auto may use a verified cheap-first cascade and escalate only when its declared acceptance path fails. Pinned fails closed on an ineligible or unavailable route unless qualified fallback was expressly authorized. Compare quotes and accounts for every admitted attempt, verifier, and synthesis leg. Expensive or externally procured work exposes a quote or cap before commitment.

A workflow node, receipt, authority check, connector grant, policy decision, or Agentgres write is not independently billable merely because it exists. Only optimized placement or another paid routing/procurement decision should mint a RoutingDecisionReceipt; ordinary pinned-provider lifecycle work uses provider-operation and billing evidence.

Self-directed economics. A local or direct self-managed run has no external provider pass-through or percentage-of-provider-spend fee. If it uses no licensed supply, managed service, public anchor, escrow, or dispute path, those buckets are absent as well. Sovereignty is a first-class route, not a discounted version of mandatory network escalation.\

8.4.3.1 Goal Space Subscription, Work Credits, and Separate Network Funding

Mass adoption must not require retail users to purchase tokens, manage a wallet, assemble model subscriptions, or understand provider billing. ioi.ai therefore sells one seat-like Goal Space outcome product rather than separate single-node and network-node subscriptions or a bundle of named-human foundation-model plans.

The user pays fiat or an approved enterprise billing rail for the persistent conductor, goal/account state, portable memory, policy, receipts, replay, collaboration, ordinary support, and a bounded monthly Work Credit grant. Additional managed work uses top-up, opt-in overage, or committed spend. The allowance is sized from observed cost of goods, route mix, acceptance rate, concurrency, context, verification, and support load rather than by adding together retail chat-plan prices or promising unlimited multi-worker burn.

Product billing and economic settlement remain distinct:

Product funding: The Goal Space plan issues a bounded, non-transferable Work Credit allowance and records top-up, overage, or committed-spend consent.
Managed usage: Work Credits debit model, runtime, connector, storage, Worker, verifier, and conductor costs under the disclosed rate card and itemized usage ledger.
Independent participation: Opening contributor scope to Network / Open uses a separate NetworkGoalBudget, bounty, procurement cap, or ServiceOrder. It never silently consumes the ordinary seat allowance.
External payout: Eligible providers, Workers, services, verifiers, and contributors settle separately through fiat, stablecoin, IOI, or another approved rail under the applicable contract, jurisdiction, authority, assurance, acceptance, and dispute posture. Agentgres admits the corresponding evidence and ledger refs.

The Goal Space subscription may fund same-domain managed execution and IOI’s disclosed seed supply because those remain one product/operator lane. Genuine independent labor is opt-in and separately funded. Work Credits are therefore never a vague pro-rata payout pool. A ContributionReceipt supplies attribution evidence; payout eligibility requires the declared verification, acceptance, adjudication, and settlement path. The economically relevant unit is accepted or otherwise contract-eligible contribution, not raw model tokens or receipt count.

8.4.4 Supply-Side Incentives: Package/License Fee Routing

IOI introduces package/license-anchored fee routing to sustainably monetize open-source workers, proprietary tools, service packages, ontology packs, evaluators, and connector surfaces.

Mechanism: A signed manifest and its declared license/right record identify eligible recipients, contribution terms, and Agentgres-governed package/artifact refs. No optional token becomes the universal canonical recipient merely by existing.
Enforcement: When a session invokes a WorkerPackage, ServicePackage, connector, evaluator, or licensed artifact, the applicable product, marketplace, or settlement rail checks the declared package/license terms. Where the contract and jurisdiction support it, the rail calculates eligible royalties from receipt-backed metering and routes them to the declared recipients.
Impact: This supports a "Royalty-on-Execution" model rather than only "Royalty-on-Access." Supply may be open, protected, or proprietary under its license and custody profile; verification must not depend on pretending that a compiled artifact makes source visible.

8.4.5 Contribution Accounting & Marketplace Neutrality

The core economic problem of an “Internet of Intelligence” is cannibalization. If the platform silently routes around specialized workers, clones worker internals into default behavior, or hides first-party preference behind opaque ranking, it destroys the incentive for developers and service providers to publish specialized intelligence.

IOI prevents this through strict Marketplace Neutrality and Contribution Accounting. This economic layer ensures that whenever intelligence is shared, it is attributed and compensated, protecting the MoW worker economy.

The Anti-Cannibalization Invariant: Hypervisor, the Default Harness Profile, MoW routers, marketplace surfaces, and service routers must not silently clone, appropriate, or hide third-party worker, service, dataset, evaluator, or tool contributions. If a run utilizes a specialized tool, dataset, worker, service, evaluator, or licensed artifact to fulfill an intent, the runtime MUST emit a ContributionReceipt or domain-specific usage receipt.
The ContributionReceipt**:** This attributable artifact records the declared identity that contributed intelligence (the contributor_id), how it was used (e.g., planning, verification, tool execution), and the quality_delta (the measurable improvement it provided to the final outcome).
The Attribution Graph: These receipts form an attribution projection of the Verified Work Graph within the Agentgres domain. When a user pays for a successful outcome, an applicable product, marketplace, or settlement rail may use the graph to calculate eligible royalties, Work Credit accounting, or payouts according to the declared contribution, license, authority, and jurisdictional policy for that task.
Reputation as an Asset: Even in “free” or local executions where no tokens change hands, ContributionReceipts may update a reputation root, marketplace projection, or local quality ledger. This lets Workers, services, evaluators, datasets, and packages rise in discovery based on attributed use and evaluated outcome evidence, rather than platform fiat or marketing spend. The receipt alone does not prove utility or acceptance.

This shifts the economic model from zero-sum competition to composable collaboration. Developers are economically incentivized to publish small, hyper-specialized workers because receipted contributions can become eligible for royalties, reputation, or routing weight under the applicable contract instead of disappearing inside a larger workflow, service order, or MoW labor graph.

8.4.6 Escalation Economics

An implemented public ServiceOrder dispute profile should prevent abuse through explicit anti-griefing bonds and challenge windows. The following is a target contract shape, not a claim that IOI L1, a live Arbitration Lane, or its bond economy is deployed.

Liability Binding & Target Enforcement Status

The IOI economic ladder relies on the settlement schema binding the execution artifacts to real capital.

Minimal Target Invariant: A bonded on-chain escrow profile must bind to (session_id, policy_hash, receipt_root). A dispute under that profile must present a challenged receipt and valid inclusion evidence against the committed root.
Current Enforcement Status: Speculative. No IOI L1 deployment, validator set, public escrow/bond contract, payment settlement, or production dispute lane is asserted by the current architecture canon.
Candidate Enforcement: Any future automated remedy or slashing path must bind exact contract terms, evidence, authority, verifier, challenge, and appeal semantics rather than treating a policy hash or receipt root alone as proof of breach.

Escalation Parameterization

A candidate public arbitration profile may parameterize the following controls, with values set only by the governance and contract profile that actually deploys them:

Challenge Bonds (Base Bond Function): Base_Bond = max(Task_Value * Risk_Multiplier, Minimum_Floor). If a User rejects a Provider's deliverable (or if a Provider contests a User's refusal to pay), the escalating party MUST post this escalation bond.
Superlinear Cost Curve (Lane Multipliers): Escalation bonds increase geometrically with the arbitration tier. Moving from deterministic objective checks (Lane 1) to AI semantic verification (Lane 2) to Human Review (Lane 3) incurs a geometric cost increase:

EscalationBond_lane_n = BaseBond × LaneMultiplier^n

where n is the escalation lane index and LaneMultiplier is a governance parameter.
Burn/Return Policy: A mathematically defined percentage of the loser’s dispute bond is burned. This creates a negative-sum game for frivolous disputes, ensuring Arbitration is only invoked when a party has high confidence in their cryptographic evidence.
Challenge Windows & Anti-Griefing Caps: Dispute windows are strictly defined in epochs (e.g., defaulting to 24 hours for asynchronous disputes), alongside hard caps on the maximum allowable escalations per session or per epoch to prevent griefing loops.
Pre-funding: The escalating party MUST pre-fund the incremental compute and gas required by the Arbitration Nodes to run the verification trace.

8.5 Embodied Runtime and Physical Action Safety

Implementation status: speculative beyond narrow package admission. The current worker-package install path can require vertical-pack, physical-action-policy, safety-envelope, and emergency-stop references for a package declaring physical_action. That admission check is not a live robot-fleet runtime, certified local controller, two-speed mission path, segment-commitment implementation, or completed actuator boundary; none of those target capabilities is claimed as built.

Embodied autonomous systems (such as warehouse robots, humanoid devices, delivery drones, and automated manufacturing systems) use Embodied Runtime, the Hypervisor runtime profile for live physical domains. It owns robot/fleet identity, controller bindings, sensor and actuator registries, world state, command queues, telemetry, physical replay, recovery, and operator handoff while reusing worker manifests, wallet.network authority, Agentgres, and AIIP boundaries.

Two-speed embodied architecture. Physical autonomy separates mission-level governance from high-frequency control:

The governance and intelligence plane grounds the mission, negotiates ontology and action semantics, plans and simulates, classifies risk, budgets resources, obtains applicable authority, selects supervision and recovery policy, issues bounded mission envelopes, evaluates segment summaries, and pauses, revokes, or course-corrects at mission checkpoints. Goal Kernel, the Hypervisor Daemon, local/domain governance, wallet.network where portable delegated or high-risk authority is required, and Agentgres operate at this slower boundary.
The certified local control and safety plane owns controller-rate perception and actuation, controller-local invariants, watchdog and heartbeat enforcement, command clipping or denial, local emergency stop, safe-stop transitions, and immediate exception capture. It is independently enforceable from the model policy and operates only inside the admitted mission envelope and its stricter local SafetyEnvelope.

The slow plane issues a PhysicalMissionControlEnvelope binding the mission and target robots, zones, controller and version, physical-action policy, safety envelope, authority and revocation epoch, supervision and emergency-stop policy, maximum envelope age, heartbeat and failsafe posture, segment-commitment cadence, resource budget, and recovery/incident rules. A mission envelope amortizes governance; it does not authorize arbitrary local setpoints or weaken the local controller’s veto.

The local plane records each bounded interval as a LocalControlSegment. It may summarize ordinary control ticks with command, sensor, controller-state, and telemetry roots in a PhysicalActionSegmentCommitmentReceipt, but a segment aggregate must not hide command denials, safety-envelope violations, heartbeat failures, emergency stops, operator handoffs, or incidents. Those material exceptions emit immediate receipts and force the declared local stop, deny, or handoff behavior.

Remote model calls, Goal Kernel turns, wallet.network round trips, Agentgres admission, AIIP exchange, and public settlement are forbidden dependencies in a servo or motor-control loop. Their latency may delay the next mission, checkpoint, or segment admission; it must not delay the controller’s local safety veto, watchdog, or emergency stop.

However, physical actions cannot be treated like normal software actions. A physical effect cannot be assumed to roll back or become safe because a digital state transition was reverted. Every actuator-bearing mission or effect therefore declares a recovery class: replayable, checkpointable, compensatable, reconciliation_required, or non_retryable. Unknown commit state, ambiguous physical outcome, and non-retryable action fail closed into reconciliation or incident handling instead of blind replay.

To mitigate physical execution risks, actuator-affecting work must be classified as physical_action and pass an independently enforceable PhysicalActionPolicy and SafetyEnvelope. Current sensor evidence and the issued command/result bindings are recorded through SensorEvidenceReceipt and ActuatorCommandReceipt refs admitted by Agentgres. These receipts make the digital record inspectable; they do not by themselves prove that a real-world command was safe, issued, stopped, or completed.

Physical safety and human supervision as authority primitives. Human oversight is not merely a notification feature. EmergencyStopAuthority and HumanSupervisionPolicy are physical-action safety objects whose holders, scopes, channels, latency, test posture, and revocation epoch bind to wallet.network or other applicable authority records. Their safety semantics remain owned by Physical Action Safety.

The EmergencyStopAuthority is a high-priority authority and safety contract with independently operable local channels. It must not require a remote cryptographic round trip before the local stop path can act. If a physical boundary is breached, or if a human supervisor triggers an emergency stop through an approved channel such as a local button, workstation, facility system, app, web, voice-supervisor path, or API, the local safety controller or approved adapter retains the final real-time veto and drives the affected actuator domain into its declared fail-closed state. The daemon stops or denies the relevant command path, revokes or invalidates affected leases, and records incident evidence. wallet.network belongs to mission admission, authority, spend, scope, and revocation; it is not placed in the millisecond actuator loop. Hardware interlocks and facility safety systems remain part of the safety envelope.

Any safety-envelope violation, emergency stop, sensor disagreement, actuator failure, supervision failure, policy violation, or disputed physical outcome must open a PhysicalActionIncident. Incidents bind involved intents, sensor evidence, actuator receipts, emergency-stop state, remediation policy, and dispute refs inside Agentgres before any marketplace, insurer, venue, or L1 settlement path may treat the event as resolved. The L1 is not the safety controller; it receives only selected rights, insurance, settlement, dispute, reputation, or public accountability commitments after the daemon and Agentgres have recorded the operational incident.

Embodied-labor safety objects.


Architecture Object	Description	Substrate Mapping	Security / Execution Enforced
PhysicalMissionControlEnvelope	Bounded mission contract binding targets, controller/version, policies, authority/revocation, expiry, heartbeat/failsafe, supervision, segment cadence, resources, and recovery.	Issued through mission-level governance and daemon admission; referenced by the local control bridge and Agentgres mission truth.	Bounds what the local controller may attempt without entering the controller-rate loop.
LocalControlSegment	One bounded local-control interval under a specific mission envelope, controller version, and revocation epoch.	Owned by Embodied Runtime and summarized through command, sensor, telemetry, exception, and commitment refs.	Keeps high-rate control local while making bounded intervals inspectable and revocable at checkpoints.
PhysicalActionPolicy	Standardized ruleset defining velocity, torque, force limits, and allowed operational coordinates.	Registered as a mission-admission policy object with Agentgres/domain policy refs and an independently enforceable local binding.	Requires the local safety path to deny, clip, stop, or hand off commands outside declared bounds.
SafetyEnvelope	Real-time virtual barrier mapping physical coordinates, LiDAR clearance, and safe operating zones.	Enforced by an independent local safety boundary, controller, approved adapter, or facility safety system, with daemon and Agentgres bindings.	Can deny, clip, stop, or require handoff when a proposed command exceeds the envelope.
EmergencyStopAuthority	High-priority authority and safety contract for immediate scoped stop and revocation of affected command paths, including independently operable local channels.	Declared holders, trigger channels, maximum latency, test state, and revocation epoch bound to applicable authority records.	The local safety path stops affected actuators and the daemon invalidates relevant leases; it does not require killing the entire daemon or clearing unrelated sessions.
HumanSupervisionPolicy	Rules defining required check-in intervals, operator visual verification, and step-up confirmations.	Linked as a RequireApproval gate on high-risk physical tasks.	The local plane enters its declared safe state while mission-level governance requests approval or operator handoff; no remote approval is awaited inside the control loop.
SensorEvidenceReceipt	Receipt binding camera, LiDAR, IMU, or other sensor snapshot hashes, capture time, confidence, artifacts, and redaction policy.	Saved through Agentgres with EvidenceBundle and ArtifactRef links.	Records the declared sensor evidence used to justify or audit execution under stated capture and verifier assumptions.
ActuatorCommandReceipt	Receipt binding physical command hash, actuator ref, issuing daemon, authority ref, safety envelope ref, sensor evidence receipt refs, and command result.	Committed directly to Agentgres as a specialized physical-action receipt.	Records the digital command/result binding; it does not independently prove safe or faithful real-world motion.
PhysicalActionSegmentCommitmentReceipt	Receipt binding a local control interval, controller/version, mission envelope, command and sensor roots, exception refs, start/end state, and declared result.	Emitted at the mission’s segment cadence and admitted with the embodied replay record.	Summarizes ordinary ticks without replacing immediate violation, stop, incident, or mission-level reconciliation receipts.
LiabilityClaimRoute	Claims-routing object binding an incident, evidence bundle, parties, policy and contract refs, optional external claim refs, and dispute or settlement refs.	Admitted through Agentgres and consumed by Ecosystem Assurance, sas.xyz, external claims processes, or an optional public commitment.	Routes evidence without adjudicating coverage, guaranteeing insurance, or serving as legal advice.

9. Security and Evolution

IOI’s security model is process safety over model safety. A model may remain stochastic, fallible, or replaceable. What must be secured is the path by which a worker turns model output into authority-bearing consequence.

This section specifies the threat model for the IOI protocol. The system assumes adversarial conditions: some providers are malicious, some users are reckless, and some hardware is compromised. The firewall mechanics that enforce containment are specified in Section 2.6; this section defines the adversaries, failure modes, and mitigations that those mechanics are designed to withstand.

Security is enforced fractally across the network topology, preserving the same transaction-shaped boundary from local runtime to global settlement:

Local (Hypervisor Node): the daemon effect boundary protects the device.
Session (Remote Infrastructure): policy, scoped authority, attempt and retry limits, spend caps, usage evidence, and supplier reconciliation constrain the budget. Receipts record the declared boundary; they do not make provider metering truthful by themselves.
Global (Mainnet): challenge and finality protect only the public/economic commitments actually admitted to an implemented settlement profile.

9.1 Daemon Effect Boundary

Hypervisor Daemon effect boundary is the protocol term for this bounded-effect discipline. It covers ActionRequest canonicalization, policy language, canonical ordering, runtime mediation, capability scopes, interception and approval flow, audit chain, hierarchical delegation, and the Monotonic Policy Invariant. The daemon owns execution semantics and effect admission; it does not manufacture authority. Local/domain governance owns ordinary local decisions, wallet.network owns portable delegated authority, secrets, spend, declassification, and high-risk grants, and Agentgres records admitted operational truth. AIIP transports typed requests and refs but grants no execution authority. This section assumes those mechanics and focuses on the adversaries they are designed to contain.

Collaborative-pursuit admission, taint, and portable exit. An OutcomeRoom is a collaboration profile over bounded GoalRuns and sovereign domains, not a globally mutable graph or a peer runtime. Every persistent room declares exactly one shared-state topology: hosted admission, in which one named governed domain orders and admits room-level updates; or a versioned federated admission policy naming member domains, ordering and merge rules, quorum or adjudicator requirements, conflicts, failover, recovery, and policy transitions. A board, chat, digest, leaderboard, replay, or remote Agentgres projection is never universal truth by implication.

Contributor scope never widens privacy, retention, custody, context, connector, capability, budget, network, or authority scope. Each participant receives bounded, expiring, revocable leases for only the context, resources, tools, claims, and authority needed for its work. Every participant message, artifact, patch, ontology mapping, attempt, finding, evaluator change, and executable result remains tainted until bounded execution, policy, verification, and the declared room/domain admission path accept it. No such input promotes directly into durable memory, ontology truth, route priors, authority, production capability, or reputation.

Participant agreement is evidence, not authority or correctness. Sybil identities, correlated reviewers, collusion, self-verification, and one operator presenting many workers, models, accounts, or nodes must not manufacture independent-party or independent-verifier claims. Multiplicity is not independence: all IOI-operated seed workers remain one disclosed party until another principal with an independent authority and operational domain joins.

On retirement, revocation, expiry, or removal, new work admission stops, active claim leases are released or quarantined, future access is revoked or rotated, and unsettled effects enter their declared recovery path. Historical receipts, admitted attempts and findings, contribution credit, challenges, and dispute/audit lineage are not rewritten. A policy-permitted ParticipantStateBundle lets the participant retain its own portable state—eligible claims, attempt and finding refs, contribution and dispute lineage, approved memory proposals, and continuation metadata—without exporting raw private room context or another party’s protected data.

The minimum network conformance test is therefore concrete: an independently operated external Worker must be able to discover an eligible OutcomeRoom through a policy-bound projection, negotiate semantic and action profiles, submit a typed participation request, receive bounded leases, claim work, return an evidenced and verifiable contribution, preserve credit and dispute lineage, retire or be revoked with claims released, and retain a portable participant-state bundle without sharing one runtime, database, administrator, or continued IOI-host trust.

Assurance and effect recovery. Collaborative, reputation, and settlement projections preserve the ordered assurance ladder attested, evidenced, verified, accepted, adjudicated, and settled. A receipt authenticates only the declared boundary fact and verifier coverage it binds. It does not by itself establish external-world occurrence, quality, causality, independence, acceptance, legal fault, or economic value.

Every consequential external effect declares one recovery class: replayable, checkpointable, compensatable, reconciliation_required, or non_retryable. Retry is permitted only when the current policy, idempotency contract, authority, and known effect state permit it. Unknown commit state, conflicting observations, physical effects, value movement, and non-retryable operations fail closed into reconciliation, compensation, incident handling, or operator review; environment or workspace restore is not proof that the external outcome was restored.

9.2 Threat Model: Market Risks

9.2.1 Malicious Agents (Trojan Horse / Device Harm)

Scenario: A user installs an agent that attempts to exfiltrate secrets (~/.ssh), encrypt documents, or automate destructive actions.
Defense: Capability sandboxing + Mediated I/O. The agent has no ambient authority; filesystem/network actions must pass the firewall, and deny-listed paths are blocked by policy.

9.2.2 Malicious MCP Servers (The Supply Chain Attack)

Scenario: A user downloads a tool advertised as a "Calculator MCP" that actually contains logic to scan the filesystem for crypto wallets or exfiltrate environment variables.
Defense:
- Process Containment: The Hypervisor Daemon runs local MCP servers in a restricted sandbox (e.g., Bubblewrap, Docker, microVMs, or WasmTime) or mediates a remote MCP endpoint through a declared connector and tool contract. Neither path receives ambient host authority.
- Policy Manifest Enforcement: The daemon enforces the Policy Manifest. Even if the malicious code attempts fs.read("/home/user"), the daemon boundary will deterministically block the syscall if that path was not explicitly granted in the manifest.

9.2.3 Malicious Providers (Fraud, Overcharging, and Fake Receipts)

Scenario: A provider returns garbage, induces retry loops to drain budget, inflates metering, or returns forged artifacts to claim payment.
Defense:
- Spend Caps: Hard max_spend per session/step enforced by policy.
- Loop Brakes: Hypervisor Core, the selected HarnessProfile, and daemon gates enforce retry/tool/time limits.
- Receipt Validation: Each burst must return a receipt bound to offload_packet_hash, policy_hash, and model_snapshot_id. This makes the provider’s statement attributable and challengeable; acceptance, billing, or payout still requires the declared evidence, verifier, usage-reconciliation, and dispute policy.

9.2.4 Market Manipulation (Sybil and Capability Spam)

Scenario: An attacker floods discovery with fake capabilities/endpoints to manipulate routing or reputation signals.
Defense: declared identity and eligibility policy, affiliations, rate limits, queue backpressure, fair-allocation controls, contribution caps, reviewer-independence checks, challengeable verifier versions, anti-Sybil/collusion signals, and—where appropriate—economic friction. A bond or attestation is one signal, not proof of independence or quality.

9.2.5 Global Settlement Fraud (Forged State, Replayed Tickets)

Scenario: A provider attempts to settle a claim using forged state, fabricated receipts, or replayed payment authorization.
Defense:
- Replay-safe authorization: The selected payment or settlement contract binds payer authority, nonce/sequence, amount, expiry, and cumulative or one-shot semantics as applicable.
- Merkle Roots: Session history is committed via receipt_root. Inclusion proves only that the committed records occur under that root; it does not prove that every provider or external-world assertion in those records is true.
Challenge Window: Unilateral close opens a challenge window; either party may submit a newer valid state or evidence against the claimed root.

9.2.6 Lying by Omission (Context & Receipt Gaps)

Scenario: A provider performs work but omits required evidence (e.g., a tool call or network access) that would prove policy violation, or omits a relevant file from context retrieval to force a specific output.
Defense:
- Required receipt profile: Each task type defines a required receipt profile keyed by policy_hash; missing required receipts prevents the affected claim from advancing to its required assurance, acceptance, or settlement stage and routes it to the declared failure or dispute path.

9.2.7 The Latency-Induced Hazard (Visual & Context Drift)

A critical vulnerability emerges when the safety-checking logic is physically separated from the execution environment, a common topology in cloud-based "Computer Use" agents.

Visual Drift (Time-of-Check to Time-of-Use)

Scenario: An agent analyzes a screenshot at time t0 and decides to send a click command. At t1, before the click is injected, a high-priority system dialog ("Grant Admin Access") appears at those exact coordinates.

Defense:

For OS Actions: The Atomic Vision-Action Lock. Because strict cryptographic hashing of raw pixel buffers is unviable (a blinking cursor or ticking clock would paralyze the agent), the lock utilizes Perceptual Hashing (pHash). Before injecting a click, the Native Operator captures a fresh screenshot and computes its pHash. It compares this against the expected_visual_hash from the inference step. If the Hamming distance exceeds the protocol's strict drift threshold (e.g., > 32 bits of divergence), the screen has materially changed. The kinetic action is immediately Blocked by the daemon effect boundary, preventing unintended clicks.
For Web Actions: DOM-Level Resolution. By utilizing the Browser Subsystem, web agents target structural layout elements rather than absolute X,Y coordinates. If the DOM geometry shifts during execution, the CDP backend resolves the new coordinate center prior to dispatch, drastically mitigating race conditions.

Context Drift (The Focus Gap)

A specific hazard occurs when an agent intends to interact with Application A but inadvertently brings Application B to the foreground, effectively hijacking the agent's subsequent inputs. The IOI Verifier treats this not as a "State Change" (Success) but as a Context Violation (Failure).

Defense: The Perception Layer continuously evaluates the OS Window context. If a visual shift occurs (a high Hamming distance) AND the active window title/app name mismatches the agent's intended target constraint, the execution step is marked as Failed. Rather than triggering a blockchain-style "revert" (which is impossible for physical OS states), this re-grounds the target and enters the effect’s declared recovery path. A new attempt through os::focus is allowed only when the prior effect state is known and the recovery class permits replay; otherwise the runtime reconciles or requests operator review.

9.2.8 Credential Exfiltration (The "Model Leak")

Scenario: A malicious or "jailbroken" model attempts to output its system prompt or environment variables to a user, inadvertently leaking an API key.
Defense: Structural Isolation. In a brokered-secret route, the model receives only a scoped handle/reference and the approved capability target receives secret material at the mediated boundary. The model therefore cannot emit a key it was never given. This guarantee is route-specific: a connector, tool, process, provider, or workspace that is intentionally given plaintext remains inside the declared custody and threat model and requires egress controls, redaction, revocation, and audit.

9.2.9 Adversarial PII Bypass

Schema validation and deterministic detectors do not make steganographic or semantically transformed PII exfiltration impossible. A malicious worker may encode protected data inside an otherwise valid output. The defense is layered: least-context projections, policy-bound views, brokered secrets, destination and schema restrictions, content and entropy inspection where appropriate, declassification gates, output-size and channel limits, human review for high-risk release, and post-event detection and revocation. The residual covert-channel risk must remain explicit in the selected execution-privacy profile.

9.2.10 Private-Execution Substrate Compromise

IOI does not make any single private-execution substrate foundational to authority. A class-wide TEE vulnerability, proof-system break, MPC implementation flaw, FHE parameter failure, or verifier bug may compromise the confidentiality or correctness claims of sessions that relied on that substrate. It must not compromise global settlement validity unless the affected receipt class was incorrectly elevated into an authority source.

Defense: The protocol separates substrate evidence from authority. The receiving domain or selected settlement verifier accepts private-execution outputs only when the Required Receipt Set is complete, the verifier registry recognizes the proof or attestation class, and the action’s assurance or settlement profile permits that evidence posture. High-risk workloads may require hybrid evidence, such as TEE + deterministic replay, TEE + ZK, MPC + output commitments, or ZK + external observation receipts.

Non-claim: IOI does not claim that TEEs, FHE, MPC, or ZK-ML are universally secure or universally applicable. It claims that authority-critical execution is receipt-bound and verifier-governed, so compromised substrates can be deprecated, challenged, or excluded without redefining the protocol.

9.3 Semantic Integrity (Prompt Injection and Context Poisoning)

A technically secure agent can still be semantically dangerous. IOI defends via Verifiable Interpretation:

Semantic integrity is not only prompt filtering. It depends on policy-bound data views, connector mappings, data recipes, transformation receipts, ontology-bound evaluation datasets, and provenance-preserving distilled datasets. A worker should not silently train on, evaluate with, export, or route over raw connector payloads outside authorized views.

Typed inputs: structured objects, not raw string concatenation; instructions separated from data and policy-checked.

Model binding: receipts bind the declared model route or model_snapshot_id. An undeclared substitution becomes detectable or challengeable only to the extent the route’s provider, runtime, custody, and attestation evidence covers that claim; the binding alone is not proof of fraud.

Context provenance: retrieved chunks carry stable IDs + hashes (and signatures where available). Policies may require higher-assurance sources for high-stakes steps.

Invariant: ** IOI constrains the effects of intelligence. An agent can “think” whatever it wants, but it cannot perform canonical Web4 Act — spend, send, exfiltrate, mutate durable state, use credentials, or settle — without daemon effect admission and the applicable local/domain or wallet.network authority. Public/economic enforceability checks apply only when a selected settlement profile is crossed. That is the precise security meaning of Act inheriting Own.

9.4 Improvement Proposal Plane: Upgrades as Governed Transactions

IOI frames autonomous improvement as bounded, sovereign state transitions rather than free-form self-modification. Workers, HarnessProfiles, and service packages may analyze execution traces, failed runs, user corrections, benchmark outcomes, and fitness signals to generate UpgradeProposals. Those proposals may target skills, workspace memory projections, prompts, tool schemas, module routes, verifier gates, workflow templates, package manifests, or model-routing policy, but actual activation must be executed through governance or owner-authorized swap_module/upgrade transactions to ensure deterministic activation and integrity.

This layer is the Improvement Proposal Plane. It is not Foundry, not a global meta-harness, and not a privileged harness above other harnesses. It is the evidence-to-patch path that lets workers, selected HarnessProfiles, the Workflow Compositor, verifiers, Foundry jobs, humans, and service packages propose changes to governed objects. Foundry may train or package a candidate when the improvement requires a model, dataset, benchmark, or worker-building workflow, but Foundry outputs still need deployment review, authority, receipts, and Agentgres admission before they alter live behavior.

Persistent skills and memory are not owned by a model or by a single harness. They are workspace-, project-, organization-, or domain-bound state surfaced through Agent Wiki / ioi-memory and admitted where needed through Agentgres operations. This allows a user to swap models, harnesses, or editor adapters without losing the learned operational context that should persist with the workspace.

Central to this process is Execution-Boundary Alignment enforced by a monotonic policy guardrail: systems may improve Logic (capabilities, workflows, routes, and verifiers) while any expansion of Policy (privileges, scopes, budgets, secrets, or declassification rights) requires explicit authorization. A future high-assurance continuity profile may add proof-carrying lineage for a specific policy non-widening predicate. Such a proof establishes only that declared predicate under its verifier and assumptions; it does not guarantee general behavioral safety across generations.

Allowed vs. Disallowed Improvement Domains

Workers CAN improve: Skills, memory projections, prompts, instructions, tool choice heuristics, benchmark suites, verifier tests, route-selection policies, workflow candidates, and proposed policy changes for sovereign review via the Inbox approval gate.

Workers CANNOT improve (Hard Bounds): Bypassing policy constraints, expanding their own authority scope, releasing secrets, declassifying protected workspace state, self-replicating, or mutating trust boundaries without explicit Inbox approval. These hard bounds are enforced by the applicable daemon, policy, authority, and admission path. Where a declared continuity profile exists, selected policy and lineage facts may additionally be cryptographically committed or proved.

9.4.1 The Fitness Function (The Evaluator)

The Fitness Function evaluates agents on Economic Utility (task completion, user satisfaction) and Safety Compliance (policy adherence, receipt completeness). Fitness scores inform upgrade proposals but do not trigger automatic self-modification; the owner or governance process must authorize any code, route, schema, model, verifier, skill, or memory-policy change via a daemon-mediated transaction bound to a cryptographic receipt.

9.4.2 The Upgrade Proposal and Decision Receipts

Agents submit an UpgradeProposal that may request a swap_module transaction, workflow update, skill installation, memory projection update, route update, verifier update, or package manifest update. The proposal is not effective until accepted by policy and committed through the daemon into Agentgres.

The transaction must include an UpgradeJustification artifact: a structured record built from Agent Wiki / ioi-memory retrieval summaries plus Agentgres-admitted evidence refs documenting the execution traces, failure modes, and fitness signals that motivated the change. This is a formal audit artifact, not raw model reasoning.

9.4.3 The Monotonic Policy Invariant


The Monotonic Policy Invariant: An upgrade can change Logic (Code) but cannot relax Constraints (Policy Envelope). This binds autonomous improvement to an explicit execution boundary and prevents self-escalation from being hidden inside an ordinary code, route, skill, or memory update.

Code and workflow updates are accepted via owner-authorized swap_module/upgrade transactions; policy relaxations require the explicit approval of the authority that owns that policy. Local/domain governance may authorize an ordinary local policy change; wallet.network is required for portable delegated authority, secrets, spend, declassification, or other high-risk revocation-bearing grants. No upgrade, code, or policy takes effect without the applicable UpgradeProposalReceipt, UpgradeDecisionReceipt, mutation receipt, authority, and Agentgres admission required by its owner contract.

Crucially, a policy-widening approval is not a generic boolean. The applicable authority artifact MUST bind the exact request_hash, policy_hash, scope, expiry, and revocation_epoch needed by its owner contract to prevent replay or scope creep.

9.4.4 Continuity Proofs (The Cryptographic Chain)

For high-consequence environments where execution-boundary containment must be verified independently off-chain, a future versioned High-Assurance Continuity Profile may require proof-carrying lineage. This is a research/profile direction, not a currently canonized object family. Rather than claiming unlimited safety across arbitrary future generations, this profile requires proof-carrying lineage: each accepted deployed-lineage upgrade must bind the previous accepted state, authority envelope, policy invariant, and verifier set into a cryptographic continuity record.

Such a profile would require each accepted upgrade to emit and verify a versioned continuity record:

The Continuity Accumulator: The record carries a rolling continuity_accumulator_hash that compresses the entire history of the agent’s state transitions and accepted upgrades.
The Recursive Proof: The object also carries a continuity_recursive_proof. It verifies the exact transition statement encoded by the profile, such as a policy non-widening predicate; it does not prove unrestricted behavioral safety.
The Extension Certificate: When an upgraded agent proposes a new block of work, the proposal may carry an extension certificate linking the new work to the validated predecessor hash.
Authorized zkVM/Proof Verifiers: To make continuity evidence portable across nodes and, where needed, public settlement, the runtime may compile verifier logic into an authorized proof environment. A zkVM or recursive-proof backend can reduce verification to succinct proof checks relative to full replay, but its latency and assurance depend on the selected backend, circuit, proof system, and verifier policy.

Result: Under a selected and implemented profile, the declared lineage and non-widening predicate need not remain a black-box trust assumption. The proof says nothing broader than that predicate and does not replace sovereign admission or control.

9.4.5 Worker Training vs. Deployed-Lineage Upgrades

IOI distinguishes initial or authorized worker training from post-deployment lineage upgrades.

Worker training is a builder-authorized or customer-authorized process that creates or improves a worker before deployment, or under an explicit retraining contract. It may expand the worker’s logic, tool strategy, memory, verifier gates, or model backend if the resulting manifest and policy are explicitly signed by the appropriate authority.

Deployed-lineage upgrade is a deployed worker, HarnessProfile, or service package proposing changes after it already holds a policy envelope and operational identity. Deployed-lineage upgrades are governed by the Monotonic Policy Invariant and cannot relax policy, expand authority, widen capability, or alter trust boundaries without explicit human, wallet.network, organization, or governance approval.

In short:

Training creates or improves a worker under an authorized training contract.
Deployed-lineage upgrade evolves a deployed worker under monotonic safety constraints.

Both processes emit receipts; a future high-assurance deployed-lineage profile may additionally require continuity proofs across generations. Training improves capability. Policy grants power.

9.5 Ecosystem Assurance, Certification, and Liability

Implementation status: speculative architecture. Ecosystem Assurance is the source-neutral trust layer that makes machine-economy evidence institutionally legible, certifiable, auditable, insurable, commercially exportable, and abuse-resistant without becoming a runtime, authority wallet, truth database, marketplace, insurer, court, or settlement layer.

Owners continue to act in their own domains: Hypervisor and the daemon execute and emit runtime evidence; wallet.network owns identity, authority, step-up, revocation, secrets, and value-flow decisions; Agentgres admits assurance-relevant operations and refs; Foundry builds eval and certification-support evidence; marketplaces consume eligibility and advisory posture; IOI L1 may anchor selected public claims or disputes. Assurance declares the profiles, evidence requirements, policy packs, posture projections, advisories, claim routes, and export shapes that connect those owners.

The core object families are:

EcosystemAssuranceProfile: required evidence, policy, conformance, exception, revocation, and public-anchor posture for a bounded subject and version.
ConformanceProfile: required interfaces, events, receipts, and negative tests for a worker, harness adapter, runtime node, wallet client, MCP gateway, private workspace, HypervisorOS node, embodied runtime, service endpoint, storage backend, or Agentgres domain.
CertificationClaim: an issuer-, version-, evidence-, expiry-, status-, and revocation-bound claim that a subject satisfies an assurance profile. It is not authority or proof of legal coverage.
JurisdictionPolicyPack: declarative eligibility, identity, regulated-action, retention, deletion, residency, tax, invoice, disclosure, and audit-export inputs. It is not legal advice.
AssuranceEvidenceBundle and AssurancePostureProjection: portable evidence packaging and a rebuildable current posture view over owner-domain truth.
QuarantineAdvisory, LiabilityClaimRoute, and CommercialAssuranceExport: scoped advisory, claims-routing, and customer export objects that route action to the domain that can actually restrict, revoke, delist, remediate, pay, dispute, or settle.

No assurance profile grants authority. No certification badge skips daemon, wallet.network, local/domain governance, Agentgres, policy, receipt, or settlement gates. Assurance posture must be continuously recomputed as versions, evidence, threats, laws, workers, runtimes, services, and claims change.

10. Protocol and Product Surfaces

IOI is one governed operating fabric with strict ownership boundaries between semantic meaning, collective pursuit, bounded execution, authority, operational truth, evidence, markets, and public settlement. Those boundaries keep the fabric sovereign and composable; they are not separate competing runtimes or product theses.

Primary execution is edge-first, centered on the Hypervisor shared substrate. Federated Domain Ontologies provide the semantic world plane; Goal Spaces and OutcomeRooms provide the collective-pursuit plane; GoalRuns provide bounded pursue, verify, and course-correct loops; and Hypervisor gates execution and effects. A core privacy posture of this target substrate is the speculative Private Workspace backed by cTEE, allowing workers to use untrusted remote hosts under a declared no-plaintext-custody and leakage-profile contract rather than handing those hosts protected workspace plaintext.

Market dynamics are handled by the sibling marketplaces: aiagent.xyz (which catalogs and packages worker capability manifests) and sas.xyz (which catalogs and escrows service outcomes). These surfaces coordinate discovery and contracting but do not own runtime truth. Actual execution is dispatched through daemon-owned or daemon-compatible paths: local Hypervisor sessions, provider sessions, HypervisorOS nodes, Rust/WASM service modules, selected HarnessProfiles, cTEE/private-workspace actions, or bounded external exits as policy permits.

Product and canonical owner map.


Product / Surface	Canonical Substrate Owner	Core Protocol / Architectural Role
Hypervisor Core	Shared Hypervisor substrate	Coordinates sessions, clients, application surfaces, harness adapters, provider views, workflow composition, approvals, receipts, and replay over daemon/domain APIs.
Hypervisor Daemon	Execution owner / effect boundary	Owns execution semantics, sandbox and runtime boundaries, tool boundaries, runtime leases, and receipts; it consumes authority decisions rather than becoming the authority provider.
Rust/WASM workload/kernel substrate	Step/module execution backend	Executes admitted StepModuleInvocations, service modules, and workload jobs under daemon admission and applicable authority; it is not a peer runtime beside Hypervisor.
Hypervisor App / Web	First-class clients	Native and browser clients over Hypervisor Core; they inspect, compose, approve, and operate sessions without owning execution truth.
Hypervisor CLI/headless	Operator and automation client	Starts, stops, measures, and queries local nodes, sessions, receipts, and state; TUI is an optional presentation.
Hypervisor shell	Product navigation	Home, Projects, Automations, Applications, and Sessions, plus one optional Open Application slot. It keeps primitives out of the permanent rail.
Hypervisor application suite	Governed projections over Core	Studio, Automations, Ontology, Data, Governance, Missions, Provenance, Evaluations, Improvement, Foundry, Marketplace, Workbench, and Developer Console. Environments and Operations form the substrate lane.
Hypervisor Workbench	Application surface	Code and systems surface over Core; uses editor, terminal, browser, VM, and agent-harness adapter targets.
Hypervisor Foundry	Application surface	Model, worker, evaluation, dataset, registry, endpoint, package, ontology-aware build, and simulation-training surface over the same Core and Agentgres receipt model.
ioi.ai Goal Space	First-party outcome conductor product	Owns goal intake, plan/status and collaborative-pursuit projections, contributor scope, execution policy, subscription and budget controls, synthesis, and account/device/restore metadata over ordinary Hypervisor contracts; it does not own execution, authority, participant-domain truth, marketplaces, or settlement.
OutcomeRoom / CollaborativeWorkGraph	Shared-pursuit admission and projection	Owns the shared objective, participant and claim leases, frontier, offers, attempts, findings, verifier challenges, contribution lineage, admission, discussion projections, and replay above bounded GoalRuns; it is not a runtime or global database.
Environments / Operations	Hypervisor substrate lane and session/project/provider projections	Manage direct provider integrations for cloud compute, storage, GPUs, confidential compute, DePIN, local machines, customer cloud, enterprise infrastructure, ports, services, logs, archive refs, restore refs, placement/failover, provider spend, health, and capacity, not as a separate runtime or truth layer.
HypervisorOS	Planned Bare-Metal Node Profile	Target minimal, measured-boot OS image where the Daemon acts as node root; a future build would emit HypervisorOSBootReceipt evidence. No current build is claimed.
IOI ADK / Hypervisor SDK / ODK	Developer frameworks	Tooling to compile autonomous-system packages, worker manifests, cTEE profiles, capability exits, HarnessProfile adapters, evaluations, and deployment profiles. ODK is the ontology-aware CLI/template/scaffold/conformance kit; it is not a standalone Hypervisor application.
aiagent.xyz	Sibling Discovery Substrate	Capability marketplace. Registers and indexes WorkerPackageManifests.
sas.xyz	Sibling Discovery Substrate	Outcome marketplace. Registers ServicePackageManifests and manages ServiceOrder outcome escrows and delivery state.
wallet.network	Authority wallet / capability layer	Governs identity, approvals, payment scopes, step-up prompts, decryption leases, capability leases, and brokered secret use.
decentralized.exchange	Route-intelligence engine	Produces source-agnostic asset-conversion route candidates; it is not liquidity, execution, authority, or a trust root.
decentralized.trade	Exposure-intelligence engine	Produces venue, market, position, perps, spot-order, and event-market candidates; wallet.network authorizes exposure.
decentralized.cloud	Resource-intelligence engine	Produces evidence-bound infrastructure candidates, quotes, custody plans, spend estimates, and failover plans; it does not own provider accounts, authority, lifecycle, execution, restore truth, storage custody, or settlement.
Agentgres	Domain Truth Database	Owns admitted operational logs, state roots, artifact refs, and projection watermarks.
Agent Wiki / ioi-memory	Semantic Memory Plane	Governs durable semantic knowledge, retrieval, MemorySpaces, scoped MemoryProjections, and mutation proposals; Agentgres admits durable canonical mutations.
Ecosystem Assurance	Trust-profile layer	Declares conformance, certification, jurisdiction, evidence, advisory, claim-route, and commercial-export posture without becoming execution, authority, truth, marketplace, insurance, or settlement.
IOI L1	Speculative sparse public ledger	May anchor selected registry, rights, reputation, bond, settlement, dispute, governance, and sparse state-root commitments after a concrete profile is specified and deployed.

The product stack is described as protocol surfaces, not as marketing personas. aiagent.xyz is the component and worker marketplace. sas.xyz is the outcome-service marketplace. Hypervisor is the shared autonomous-work substrate: App, Web, CLI/headless, the stable shell, application suite, and Environments/Operations substrate lane all operate the same Core and sessions rather than forming separate runtimes. wallet.network is the authority wallet for secrets, capability leases, exchange/trade approvals, and payment grants. A future IOI L1 is designed as the sparse public root for selected settlement, identity, dispute, reputation, registry, rights, governance, and commitment anchors; no deployed Mainnet is asserted. ioi.ai is the first-party Goal Space outcome conductor over Hypervisor. Simple goals remain direct; persistent collective pursuit projects an OutcomeRoom across models, harnesses, Workers, connectors, Sessions, claims, attempts, findings, and verifier paths only when that shape earns its cost. Hypervisor CLI/headless is the operator and automation client over Hypervisor Core and daemon APIs; IOI protocol subcommands may manage domains, manifests, receipts, authority scopes, Agentgres, and Mainnet interactions. Current Hypervisor architecture uses direct provider integrations instead of a mandatory cloud gateway.

Developer package boundary. The low-level IOISdk is the protocol/client library over daemon APIs, Agentgres projections, wallet.network authority flows, AIIP channels, and optional IOI L1 commitments. The higher-level IOIAdk is the autonomous development kit used to build governed autonomous systems: workers, service modules, HarnessProfile adapters, evaluations, package manifests, deployment profiles, and receipt-aware tests. The AutonomousSystemManifest and AutonomousSystemManifestEnvelope are the portable package contracts for these systems. They describe required capabilities, authority scopes, context/memory bindings, policy hashes, module invocations, receipt obligations, environment requirements, and upgrade rules. They are not runtime owners, UI truth stores, or substitutes for daemon execution and Agentgres admission.

The Protocol Surface Hierarchy

To ensure architectural clarity and prevent the conflation of user-facing adapters with core protocol engines, the stack is organized according to the following strict hierarchy:

1. Settlement Layer (future IOI L1 or compatible profile): Selected public registry, rights, reputation, bond, governance, escrow, settlement, and dispute commitments.

2. Authority Layer (wallet.network and applicable domain authority): Local/domain governance owns ordinary local decisions; wallet.network owns portable delegated identity operations, secrets, spend, declassification, high-risk approvals, and revocation-bearing grants.

3. Hypervisor Core Layer: Shared session, client, compositor, application-surface, provider/environment, harness-adapter, receipt, and replay substrate whose execution owner is the daemon.

4. Runtime Layer (Hypervisor Daemon): The deterministic execution boundary and domain gate for tools, modules, model mounts, target cTEE actions, AIIP handoffs, and HarnessProfiles.

5. Adapter Layer: IDE extensions, editor targets, terminals, remote VMs, browser IDEs, local OS surfaces, external CLI/harnesses, and API proxies that map third-party actions to Hypervisor proposals, observations, and receipts.

6. Capability Layer: Workers, models, and tools executing as guest workloads under the daemon.

Layer 3 application overlays are not base-layer mechanics. They are governed projections and control surfaces that bind product objects to daemon, Agentgres, wallet.network, cTEE, AIIP, and provider contracts without owning runtime truth. The core whitepaper describes their protocol role; detailed buyer language, builder-lens descriptions, trace tutorials, and adapter walkthroughs belong in product docs and developer documentation.

The Promotion Path doctrine remains: Hypervisor captures, trains, and stabilizes workers; aiagent.xyz lists composable components; sas.xyz packages outcomes as a sibling surface to aiagent.xyz’s capabilities (outcome vs. capability, not a downstream application), including worker-training services; Hypervisor CLI/headless and IOI protocol subcommands package or promote systems when a domain requires its own policy root; the MoW worker economy routes verified workers across this ladder using receipts, benchmarks, policy compatibility, and contribution accounting.

Product Domains. The product stack decomposes into separate but interoperable domains. A domain owns its product state and projections in the applicable Agentgres-compatible truth boundary; it does not therefore own a runtime or authority provider. Domains interoperate through worker manifests, ai:// refs, runtime assignments, authority grants, receipts, archive refs, contribution ledgers, and IOI L1 commitments.

Hypervisor is the shared governed autonomous-work substrate. Hypervisor App, Hypervisor Web, Hypervisor CLI/headless, SDK/ADK clients, the stable shell, application suite, and Environments/Operations substrate lane all operate the same Core and sessions. Desktop chat, workflow composition, worker supervision, model mounting, local files, remote VMs, browser use, and private execution are session/application-surface capabilities, not the product boundary.

ioi.ai is the first-party Goal Space subscription and outcome-conductor product. It owns goal intake, plan and status, contributor-scope and execution-policy controls, subscription and budget projections, cross-session outcome graphs, final synthesis, and account, device, restore, publishing, sync, and remote-runtime entitlement metadata. The same persistent OutcomeRoom is rendered as a Goal Space in ioi.ai and Mission detail in Hypervisor. ioi.ai does not become the runtime, authority layer, canonical state substrate, marketplace, or settlement owner.

The product is one seat-like Goal Space, not separate single-node and network-node products. It includes a bounded Work Credit grant for ordinary managed work; top-up, opt-in overage, or committed spend funds additional managed work; and Network / Open participation requires a separate NetworkGoalBudget, bounty, procurement cap, or ServiceOrder. Execution/custody, contributor scope, placement, and Auto / Pinned / Compare execution policy remain independent controls. The subscription never pools named-human model-provider seats.

aiagent.xyz is the worker marketplace for manifests, publisher profiles, benchmark profiles, Sparse Worker Categories, trained worker packages, installs, managed worker instances, direct invocation, and routing eligibility.

aiagent.xyz direct invocation surfaces:

Worker package page — inspect manifest, policy, benchmark profile, category, runtime requirements, licensing, contribution terms, and known limitations.
Initialize worker — bind owner, runtime profile, authority policy, persistence profile, memory/archive policy, and subscription.
Web console — chat or task UI mounted over the managed runtime instance.
API invocation — stable endpoint for applications and enterprise systems.
Hypervisor install — local or remote instance available inside Hypervisor.
Workflow node — worker callable from shared workflow compositor recipes.
MoW route target — worker eligible for router selection under declared policy and benchmark profile.

sas.xyz is the service-outcome marketplace for ServiceOrders, OutcomeWorkspaces, packaged service delivery, worker-training contracts, provider workspaces, delivery bundles, approvals, disputes, and settlement mirrors. A ServicePackage may be worker-composed, deterministic, private, vendor-backed, or hybrid; sas.xyz contracts for the outcome, not for one mandatory worker supply chain.

Hypervisor CLI/headless is the terminal, scripting, CI, and automation client over Hypervisor Core, daemon, and public runtime APIs, covering sessions, provider operations, training runs, benchmark jobs, receipts, restore, archive, routing, and Agentgres inspection. TUI is an optional presentation of the CLI/headless client. IOI protocol commands may be exposed inside this client family without becoming a separate runtime.

IOI SDK is the developer client layer over daemon and substrate contracts. It is not the runtime initialized on compute nodes.

Hypervisor Daemon / Runtime Node is the execution endpoint for workers, tools, models, connectors, workflows, training, evaluation, benchmark, routing, artifact, and delivery jobs.

Agentgres operator surface. Canonical operator commands live under ioi agentgres:

ioi agentgres status

ioi agentgres doctor

ioi agentgres replay

ioi agentgres verify-root

ioi agentgres rebuild-projection

ioi agentgres restore

ioi agentgres explain

ioi agentgres diff-heads

ioi agentgres inspect-receipt

ioi agentgres migrate

L0 / L1 / Runtime Boundary. The protocol surfaces are bounded by where they sit on the topology:

IOI Kernel / L0: reusable substrate for domains, workers, policy, Agentgres, manifests, receipts, routing, runtime profiles, and L1 commitments.
Hypervisor Daemon on Runtime Nodes: the daemon owns execution semantics; RuntimeNode records describe the admitted local, cloud, cluster, DePIN, customer, HypervisorOS, TEE, or bare-metal venues on which work may run.
Domain Kernel: application-domain deployment of runtime, state, and policy over Agentgres truth.
Future IOI L1: proposed sparse public registry, rights, reputation, bond, settlement, dispute, governance, and commitment root.
SDK / CLI/headless / optional TUI / Workbench adapters: clients, presentations, and adapter targets over daemon/domain contracts, not the execution substrate.
Agent Harness Adapters: external coding agents, terminal harnesses, hosted agents, and third-party harness runtimes that propose work through Hypervisor contracts; they are not Hypervisor clients, authority roots, or completion truth.

The Request for Worker (RFA) Protocol covers three engagement classes: Class A (Agentic Contract — natural-language rubrics, ServiceOrder escrow when public settlement is required, and an arbitration backstop); Class B (Test-Driven Contract — programmatic constraints with blind validation against an encrypted test suite); and Class C (Worker Training Contract — client supplies workflow context and acceptance rubric, provider delivers a trained worker manifest, training receipts, evaluation report, and deployment package).

Implementation maturity is not a fixed phase ladder in this whitepaper. Built, partial, planned, and speculative status belongs to the canonical owner documents and implementation matrix and must be re-audited against code and conformance. In particular, the current architecture does not claim a deployed IOI L1 or embodied runtime merely because their target contracts are described here.

The Hypervisor Applications catalog carries the autonomous-systems suite:

Studio: system and agent composition over real substrate objects.
Automations: durable triggers, schedules, monitors, services, approval flows, and process graphs.
Ontology: object, link, action, function, value-type, object-set, and semantic health surfaces.
Data: sources, syncs, Data Recipes, datasets, time series, media sets, and consent posture.
Governance: approvals, authority scopes, leases, release gates, cohorts, kill switches, budgets, retention, and policy.
Missions: running autonomous systems, queues, incidents, remediation, spend, and system health.
Provenance: receipts, lineage, replay, state roots, custody, and evidence; legacy Work Ledger views converge here rather than forming a second permanent application.
Evaluations: eval suites, scorecards, evidence-eligible feedback, and quality views.
Improvement: proposals, what-if simulation, canaries, rollback, and remediation, gated by Governance.
Foundry: model routes and mounts, datasets, training, executable eval worlds, package creation, and capability-improvement jobs.
Marketplace: listings, admission, install/configure, versioned artifacts, recall, examples, and organization-to-organization refs.
Workbench: code, files, terminals, browsers, ports, environments, and debugging.
Developer Console: connectors, MCP, provider accounts, BYOK/BYOA, APIs, OAuth/service registrations, conformance, and SDK/ADK/ODK on-ramps.

Environments and Operations are the distinct Type 1/2 substrate lane for infrastructure inventory, placement, failover, storage custody, scheduler health, capacity, and provider spend. Generated domain apps are catalog entries authored through Studio and distributed through Marketplace, not a new permanent shell category. Hypervisor Canvas is a visual editor inside Studio, Automations, Workbench, or Foundry; it is not a runtime or separate product plane. ODK remains the developer kit whose ontology, data, surface, manifest, SDK, template, and conformance artifacts appear through these applications.

10.1 Hypervisor Operator Surfaces: The HCI of Intent

The Hypervisor Daemon and IOI L0/domain substrate require precise, deterministic instructions to enforce liability. Users express fuzzy intent. Hypervisor operator surfaces bridge the gap.

These operator surfaces translate natural-language or structured intent into GoalRuns, ActionProposals, policy/authority requests, gate results, TaskBriefPayloads, and receipt obligations required by the daemon effect boundary. They may appear across Hypervisor clients and applications; they do not become a second runtime or separate source of truth.

Canonical UX Objects

Hypervisor exposes a shared surface grammar across App, Web, CLI/headless, SDK/ADK clients, and application views. The permanent shell is Home, Projects, Automations, Applications, and Sessions, with one optional Open Application slot. Providers, environments, agents, models, privacy, authority, receipts, Workbench, Foundry, and other specialized objects appear through the Applications catalog or contextual views. Three recurring composition patterns are:

Goal Space and Mission detail: ioi.ai and Hypervisor render the same OutcomeRoom as a graph-first shared pursuit: objective, frontier, dependencies, participants, claim leases, attempts, findings, verifier challenges, contribution lineage, budget, authority blockers, and replay. Background participants remain visible as active, sleeping, waiting, blocked, quarantined, retired, or failed; Sessions drill into one participant, GoalRun, claim, or attempt rather than hiding work in an ambient swarm transcript.
Governance approvals and review queues: Durable decisions, clarifications, policy diffs, anomaly flags, release gates, and results appear in Governance or the relevant contextual queue. Material actions require the applicable pre-authorization or step-up result.
Automations and Missions: Automations own durable trigger, schedule, service, approval-flow, and process-graph shape; Missions render running systems, queues, incidents, remediation, spend, and system health.
Provenance: Receipts, lineage, replay entries, state roots, authority bindings, custody records, artifacts, and evidence remain navigable without implying that every observation is cryptographic proof.

10.1.1 The Intent Interface (The "Search Engine" Experience)

Users should not need to manage raw JSON or credentials. Home and New Session provide the primary command/composer entry, while Studio, Automations, and contextual application composers expose more structured paths.

Fuzzy-to-Formal Compilation: When a user types "Analyze my competitors," the intent resolver decomposes this into a direct GoalRun, Worker, route, Automation, or service by default. It creates or binds an OutcomeRoom only when a durable shared frontier, dynamic participants, multiple attempts, independent verification, or cross-domain contribution justifies the additional machinery.
Governed Handoff: The operator surface may translate the request into Workflow Compositor steps, HarnessProfile selection, provider/environment candidates, wallet.network capability requests, and Agentgres receipt obligations without forcing the user to manually choose every route. This is not blind broadcast: every handoff remains policy-bound, source-attributed, receipt-backed, and replay-inspectable; each resulting effect still declares its own recovery class.

10.1.2 The Authorization Gate (Human-in-the-Loop)

While the network strives for autonomy, bounded agency requires consent and authority. The Hypervisor Daemon enforces the applicable local/domain policy and authority-provider decision; wallet.network supplies the portable delegated step-up approval gate for designated high-stakes actions.

If an agent attempts an action that exceeds its synthesized policy (e.g., "Spend > $50"), Hypervisor interrupts the flow with a context-aware approval surface.
This is not a standard system dialog; it is an authority event. Clicking "Approve" cryptographically signs an ApprovalToken or wallet.network approval artifact, converting the user's consent into a receipt-backed authority fact. It is anchored on IOI L1 only when settlement, public trust, dispute, marketplace, or cross-domain policy requires it.

10.1.3 Visual Sovereignty

Hypervisor operator surfaces provide persistent, non-blocking status indicators so the state of active and background Workers, participants, GoalRuns, claims, attempts, Sessions, authority requests, spend, receipts, and settlement triggers is visible to the user. A user can release a claim, retire or quarantine a participant, change a budget or deadline, challenge a verifier result, inspect dependencies, or take over a bounded Session without granting ambient host authority.

10.1.4 Hypervisor Foundry

Hypervisor Foundry is the specialized model, worker, eval, dataset, endpoint, registry, package, training, and simulation-build application surface exposed inside Hypervisor App and Hypervisor Web over the same Hypervisor Core substrate. Foundry is the home for embodied model-building and simulation-training work such as simulator worlds, digital twins, LiDAR and point-cloud datasets, camera/depth/IMU telemetry, Gaussian-splat scene representations, robotics task curricula, policy training runs, perception model training, navigation/manipulation eval worlds, and sim-to-real validation reports. Live actuator execution is separate: it must cross Hypervisor Daemon admission, wallet.network authority, physical-action safety envelopes, and Agentgres receipts.

The guided compilation flow for training a specialist worker, model route, or embodied capability utilizes daemon-owned local or provider-compatible execution paths to generate verifiable outcomes:

Define Task

-> Select Base Model & Cognition Backend

-> Bind Domain Ontology and Data Recipes

-> Ingest / Generate Examples (via Hypervisor Daemon Sandbox)

-> Filter through Deterministic Quality Gates

-> Execute Evaluation Dataset / Human Review

-> Compile Worker Manifest & Package via Hypervisor SDK

-> Emit Local Validation and Initialization Receipts

The output of this pipeline is a signed WorkerManifest or WorkerPackage detailing the worker’s primitive requirements (prim:*), expected authority scopes (scope:*), runtime profile dependencies, and evaluation history. This card can then be registered on aiagent.xyz or utilized directly within private local workflows.

10.1.5 The Shared Builder Substrate

Foundry is a product lens over the shared builder substrate, not a separate canvas environment. Training recipes, evaluation recipes, benchmark recipes, deployment recipes, data recipes, and outcome workflows share the same graph model, typed node contracts, schemas, daemon execution path, and Agentgres receipt model. Different lenses may expose different palettes, inspectors, run panels, templates, and validation rules.

Foundry should lead with guided views. Advanced users may open the same recipe in the standard workflow compositor for inspection, customization, reuse, or composition.

10.2 Closing

IOI defines the open, edge-sovereign operating fabric for governed autonomous systems and the Internet of Intelligence. The protocol does not claim to align model wisdom, eliminate hallucination, make every receipt true, or remove human and institutional judgment. It claims that domain meaning can remain federated, collective pursuit can remain bounded and attributable, and consequential effects can cross explicit authority, policy, execution, evidence, acceptance, recovery, and settlement boundaries rather than depending on vendor goodwill.

The bounded claim is narrow and the non-claims are explicit (Appendix D). What IOI provides is one composable autonomy fabric: federated Domain Ontologies as the semantic world plane; OutcomeRooms as shared frontiers above bounded GoalRuns; Workers as the accountable labor actor; MoW as the routing doctrine; Agentgres as the admitted operational state model, Agent Wiki / ioi-memory as the semantic memory and retrieval plane, cryptographic and dialectic evidence as the verification ladder, the Hypervisor Daemon effect boundary as the deterministic egress gate, wallet.network as the authority wallet and capability layer, and a future IOI L1 as the sparse public-settlement and dispute anchor for selected commitments. ioi.ai packages these contracts as one Goal Space outcome product without turning a subscription, model provider, aggregator, seed fleet, or hosted room into the protocol itself.

The decisive milestone is not a large same-owner swarm. It is the network proof: an independently operated Worker can discover eligible work, negotiate semantics, receive bounded leases, contribute verifiably, retain credit and dispute lineage, and exit with portable permitted state without sharing one runtime, database, administrator, or permanent IOI trust boundary.

Web4 is the architecture in which autonomous systems may reason and execute anywhere while machine authority governs consequence and IOI settles only what matters.

Appendix A: Schema Illustrations and Moved Code Blocks

This appendix collects code, JSON/YAML/Rust/TypeScript examples, and byte-level envelope material moved out of the main narrative. These are illustrations unless a canonical owner explicitly adopts the exact shape; current owner documents govern normative structures and versions.

A.1 Policy Envelope Rule-Set Example

Example policy rule language

This non-exhaustive example illustrates deterministic rule content bound by a PolicyEnvelope. The canonical policy and wallet/daemon owners govern exact schemas. Policies are default-deny and may support graph-aware permissioning.
Rule semantics (deterministic):

Match: Rules match on the target plus conditions over canonicalized fields (domain, path, amount, window_id, etc.).
Precedence: BLOCK rules override ALLOW. If multiple allows match, the most specific rule wins (ties broken by the strict canonical ordering defined below).
Decision: { ALLOW BLOCK REQUIRE_APPROVAL } produces a single settlement resolution.
Integer Determinism: Policy evaluation relies on integer-deterministic inspection rather than Floating Point (FP16) arithmetic. This ensures that policy decisions are identical across all hardware architectures (e.g., x86 vs. ARM), eliminating "Butterfly Effect" non-determinism in safety checks.

Illustrative Rule Ordering & Hashing Profile

To ensure that a policy_hash is reproducible across heterogeneous hardware and immune to non-deterministic map iteration or insertion order variances, an order-insensitive rule set MUST be strictly normalized before evaluation or hashing.

The Hypervisor Daemon or authorized policy-synthesis path MUST apply the canonicalization function declared by the rule-set version, enforcing the following invariants:

Array Normalization: All list-like conditions (e.g., allow_domains, allow_apps, capabilities) MUST be lexicographically sorted and de-duplicated. All strings MUST be Unicode normalized.
Stable Rule Sorting: The array of rules MUST be sorted by a deterministic, stable sort key (e.g., grouped by target lexicographically, then by descending action priority [BLOCK, REQUIRE_APPROVAL, ALLOW], and finally by the canonicalized string of their conditions).
Strict Evaluation Order: The policy engine MUST evaluate rules in this canonicalized order, never relying on the memory insertion order or unstructured HashMap iteration.
Hash Generation: For this JSON profile, the canonical policy hash is policy_hash = H(JCS(canonicalized(policy content))) where JCS is the RFC 8785 JSON Canonicalization Scheme.

Graph-Aware Permissioning (DLP for Agents):

To prevent data exfiltration through complex inference chains, A versioned graph-aware policy can block specific relationships in data exports. For example, a rule may allow an agent to access "Emails" and "Financial Data" individually, but BLOCK any egress if the export graph contains edges connecting an "Email Node" to a "Financial Data Node."

Structure (example):

A.2 Effect Boundary Artifacts

Illustrative Effect Boundary Fields

This non-exhaustive illustration uses the current HarnessProfile boundary objects. Canonical owner schemas govern exact fields. Hashes are computed over the canonical encoding declared by the relevant contract.

ActionProposal (the input)

A normalized, schema-validated proposal for a governed action.

GateResult (policy and authority result)

A deterministic gate result for one ActionProposal. Any wallet approval or grant is referenced rather than replaced by the result.

NormalizedObservation (result re-entry)

A typed observation that returns execution, denial, blocker, test, browser, file, API, verifier, or approval state to the loop with receipt and artifact refs.

Canonicalization and hashing requirements (normative):

canon(x) denotes RFC 8785 canonical JSON serialization of x (or an equivalent canonical encoding defined by the protocol).
H(bytes) denotes the protocol hash function over canonical bytes.
policy_hash MUST be stable for semantically equivalent inputs after canonical normalization and MUST change when canonical policy content changes. Mere source insertion order must not create drift when the owner contract defines order-insensitive normalization.

A.3 Canonical Dispute Schema

Illustrative Dispute Schema

All challenge packages and resulting resolutions must adhere to the following canonical schema to ensure cross-node determinism:

End-to-End Dispute Example

A user funds a ServiceOrder escrow for a code-generation task with a typed acceptance rubric: {passes_tests: true, language: "Rust", max_lines: 500}. The provider’s agent delivers code that compiles but fails 3 of 12 test cases. The user submits the ServiceOrder’s declared dispute/evidence package, referencing the session, delivery, and failing-test hashes. The selected verifier validates signatures and bindings, replays the covered test suite, and reports that the objective acceptance condition failed. The authorized contract or adjudicator then applies the declared refund or remedy and appeal path. No universal lane, FaultProof class, model quorum, or automatic legal fault conclusion is implied by this illustration.

A.4 Canonical Object Envelopes & ID Namespaces

To prevent API fragmentation and decouple logical semantics from underlying network transports, all governed, authority-bearing, cross-boundary, or settlement-relevant communications across the Hypervisor ecosystem must use standardized Canonical Envelopes. Every envelope is structured to enforce the deterministic execution boundary, ensuring that all data transfers bind the active authority references, policy hashes, execution receipts, and Agentgres state-roots.

Canonical envelope specification examples:

// Canonical Hypervisor Node Envelope

struct HypervisorNodeEnvelope
node_id: URI, // node:// namespace

owner_did: URI, // wallet.network identity

boot_receipt: HypervisorOSBootReceipt, // Illustrative target boot measurement

active_chains: Vec<Hash>, // Governed operations

local_receipt_root: Hash, // Merkle root of execution history

agentgres_state_root: Hash, // Admitted operational state root

signature: Signature, // node daemon or wallet.network authority-profile signature

// Canonical Worker Package Manifest

struct WorkerPackageManifest
manifest_id: URI, // worker:// namespace
version: SemVer, // Semantic version hash

publisher_id: URI, // did:ioi:... authority

logic_hash: Hash, // WASM binary / logic pointer

model_policy: ModelWeightCustodyProfile, // Weight custody rules

required_primitives: Vec<String>, // prim:* capabilities

requested_scopes: Vec<String>, // scope:* authority demands

default_policy_hash: Hash, // Default policy bundle hash

}

// Canonical Service Package Manifest

struct ServicePackageManifest
manifest_id: URI, // service:// namespace
version: SemVer, // Semantic version hash

publisher_id: URI, // did:ioi:... authority

nested_services: Vec<URI>, // Sibling service references

success_schema: JsonSchema, // Delivery contract parameters

estimated_metering_limit: u128, // Maximum work-credit estimate

}

IOI namespaces are audited and strictly categorized to prevent ID collision and enforce semantic boundaries:

– node://<authority_did>/<node_id> — Identifies an active Hypervisor Node (or bare-metal HypervisorOS instance).

– worker://<authority_did>/<worker_id>/<version> — Identifies a Worker Package Manifest registered on aiagent.xyz.

– service://<authority_did>/<service_id>/<version> — Identifies a Service Package Manifest registered on sas.xyz.

– artifact://<domain_id>/<artifact_id> — Identifies a metadata object stored inside the Agentgres Artifact Plane.

– agentgres://<domain_id>/<projection_id> — References a queryable read model or projection stream inside Agentgres.

– receipt://<domain_id>/<sequence_number> — Identifies a cryptographically signed execution receipt.

– ctx:<domain_id>:<variable_name> — Identifies a temporary semantic context variable residing inside Agent Wiki / ioi-memory.

– grant://<wallet_did>/<grant_id> — Identifies a scoped capability or decryption lease issued by wallet.network.

Capability vocabularies: prim:* (raw system execution actions) and scope:* (resource-specific authority scopes) remain strictly defined as colon-delimited vocabularies rather than URI-like namespace paths, preventing them from being improperly treated as physical transport channels.

Upgrade proposals: upgrade proposals are not evaluated as standalone AutonomousSystemChains in isolation; they are packaged inside a WorkerPackageManifest upgrade envelope that verifies the monotonic policy invariant across generations.

A.5 Machine-Economy Event and Receipt Structures

Machine-Economy Event Kinds:

– module.invocation_proposed: Emitted when a worker proposes a service module call.

– module.invocation_started: Emitted when the daemon initiates module execution.

– module.invocation_completed: Emitted when execution concludes and produces output.

– module.invocation_committed: Emitted when the output and receipt are written to Agentgres.

– upgrade.proposal_submitted: Emitted when an upgrade proposal is drafted.

– upgrade.proposal_approved: Emitted when the policy engine approves the proposal.

– upgrade.proposal_rejected: Emitted when the proposal violates the Monotonic Policy Invariant.

– upgrade.proposal_committed: Emitted when the daemon applies the module swap.

– local_settlement.committed: Emitted when a local interop transaction is settled.

Machine-Economy Receipt Types:

struct ModuleInvocationReceipt {

invocation_id: Hash,

module_ref: URI,

caller_identity: URI,

input_payload_hash: Hash,

output_payload_hash: Hash,

execution_gas_spent: u128,

status: String, // Success | Failure

struct UpgradeProposalReceipt

proposal_id: Hash,

chain_id: Hash,

proposer: URI,

target_module_id: URI,

old_manifest_hash: Hash,

new_manifest_hash: Hash,

rationale_hash: Hash, // hash of justification in ioi-memory

struct UpgradeDecisionReceipt

proposal_id: Hash,

verdict: String, // Approved Rejected

reason_code: String, // e.g., "MONOTONIC_PASS", "POLICY_VIOLATION"

authority_signature: Signature, // wallet.network or authority-profile signature

struct LocalSettlementReceipt

settlement_id: Hash,

node_id: URI,

involved_chains: Vec<Hash>,

net_amount: u128,

asset_identifier: String, // work credits, stablecoin, or internal credits

receipt_root: Hash, // local Merkle tree anchor

}

Appendix B: Canonical Envelope Synthesis: Manifest, Task, Run, and Receipt Schemas

To keep protocol semantics stable across the Hypervisor Daemon, Agentgres, wallet.network, product domains, marketplaces, adapters, and future public settlement profiles, IOI uses shared typed envelopes and refs. The canonical catalog in the owner documents is authoritative; the schemas below are illustrative and non-exhaustive.

Crucially: ai:// names intelligence. HTTP/gRPC/IPC transports execution. Canonical envelopes define the protocol semantics.

Canonical envelopes are the wire-level mechanism by which Act inherits Own: they make execution authority explicit, bounded, signed, replay-protected and replay-inspectable across transports, and able to enter a declared settlement path when its acceptance, adjudication, and economic conditions are satisfied.

B.1 Identifier and Locator Conventions

IOI uses multiple URI-like strings, but they do not all represent transport protocols. To avoid “protocol sprawl,” identifiers are strictly categorized into intelligence namespaces, typed domain object references, payload locators, and colon-based capability vocabularies.

ai:// is not a replacement for HTTP. It is the canonical name and trust resolution layer for intelligence. A resolved ai:// manifest may expose HTTP, gRPC, IPC, content-addressed storage backends, Agentgres, or local runtime endpoints as available transports and payload locations.

1. Canonical intelligence namespace

These are stable, global, user-facing or protocol-facing names. ai:// is the primary global namespace.

ai://... --- global intelligence/app/worker/service/domain
  namespace (e.g., ai://sas.xyz/services/weekly-runtime-audit)

ioi://publisher/... — publisher identity namespace

2. Domain object references

These are typed object references inside the IOI architecture, typically mapped through an Agentgres domain. They are not web protocols.

agent://... — agent or worker instance
worker://... — worker package or worker type
service://... — service definition
run://... — runtime run identity
task://... — task identity
artifact://... — Agentgres artifact reference
receipt://... — receipt identity
wallet://... — wallet.network account or authority reference
grant://... — authority grant or lease reference

3. Storage and transport locators

These point to where bytes or endpoints physically live.

cid://... — content-addressed payload locator
https://... — HTTP transport endpoint
grpc://... — gRPC transport endpoint
ipc://... — local daemon IPC endpoint
file://... — local filesystem reference
agentgres://... — Agentgres domain object/projection reference

4. Capability vocabulary (Not URI schemes)

Primitive execution capabilities and authority scopes use a colon-vocabulary (:). They MUST NOT use :// to avoid looking like transport protocols.

prim:fs.read
prim:model.invoke
scope:gmail.read
scope:repo.write
scope:commerce.order_submit

B.2 The ai:// Resolution Waist

ai:// acts as the "thin waist" of the Web4 architecture.
Resolving an ai:// identifier yields a ManifestEnvelope,

which in turn maps the intelligence object to physical transports, authority requirements, and settlement profiles.

For example, a client resolves:

ai://sas.xyz/services/runtime-audit

And receives a ManifestEnvelope:

manifest_id: ai://sas.xyz/services/runtime-audit

manifest_type: service

body_ref: cid://bafy...

runtime_endpoints:

- https://api.sas.xyz/v1/services/runtime-audit
- grpc://...

authority_required:

- scope:payment.escrow

- scope:repo.read

artifacts:
package_ref: cid://bafy...
mow:

sparse_worker_category: optional

benchmark_profile_refs: []

evaluation_rubric_ref: optional

routing_eligibility_status: draft | submitted
| benchmarking | eligible | suspended
| revoked

contribution_policy_ref: optional

training_lineage_ref: optional

settlement:

chain_id: ioi-mainnet

contract: ServiceOrder

B.3 Capability and Authority Tiers

IOI uses two separate tiers that MUST NOT be collapsed into a single generic capability field. Legacy generic capability-prefix bindings are non-canonical. All execution boundaries MUST explicitly split into primitive capabilities (prim:*) and authority scopes (scope:*) to block confused-deputy escalations.

Primitive execution capabilities (prim:*): Runtime feasibility and physical isolation primitives. They describe the low-level action classes a Hypervisor Daemon/tool requires to execute (e.g., prim:fs.read, prim:sys.exec, prim:net.request, prim:model.invoke).
Authority scopes and leases (scope:*): wallet.network policy grants over resources, providers, identities, budgets, approvals, and expiry. They describe what a subject is allowed to do (e.g., scope:gmail.read, scope:gmail.send, scope:commerce.order_submit).

B.4 Canonical Envelopes

This is a non-exhaustive synthesis, not an independent schema registry. Current canonical owner documents govern exact type names, fields, versions, and promotion status. Illustrative fields below must not be implemented when they conflict with those owners, and any IOI L1 field is optional/speculative until a concrete public-settlement profile exists.

1. ManifestEnvelope

Used for registering and resolving canonical packages.

ManifestEnvelope:
manifest_id: ai://...
manifest_type: app | worker | service
| runtime | domain | tool |
connector

version: semver_or_hash
publisher_id: ioi://publisher/...

manifest_root: hash

body_ref: cid://... | https://... |
agentgres://...
signature:
scheme: ed25519 | secp256k1 | ml-dsa |
hybrid

public_key_ref: ...

signature: base64

l1_commitment:

chain_id: ioi-mainnet

contract: ManifestRootRegistry

tx_hash: optional

status: draft active deprecated revoked

2. AuthorityScopeRequestEnvelope & AuthorityGrantEnvelope

The core handshake between the Hypervisor Daemon (requesting power) and wallet.network (granting power).

AuthorityScopeRequestEnvelope:

authority_request_id: authreq_...

subject_id: agent://... | worker://... |
runtime://...
issuer_id: wallet://... | org://... |
policy://...

primitive_capabilities_required:

- prim:model.invoke

- prim:fs.read

authority_scopes_requested:

- scope:gmail.read

- scope:repo.write

resource_scope:

resources:
- agentgres://project/hypervisor/*
- file://workspace/src/**
constraints:

max_budget_usd: 10

expiry: 2026-05-01T00:00:00Z

approval_required_for:

- external_message

- commerce

policy_hash: hash

request_hash: hash

authority_grant_id: optional

status: requested | granted | denied |
expired | revoked
AuthorityGrantEnvelope:

authority_grant_id: grant_...

request_id: authreq_...

issuer_id: wallet://... | org://... |
policy://...
subject_id: agent://... | worker://... |
runtime://...

authority_scopes:

- scope:gmail.read

- scope:repo.write

primitive_capability_constraints:

- prim:fs.read

- prim:fs.write

resources:
- agentgres://project/hypervisor/*
- file://workspace/src/**
constraints:

max_budget_usd: 10

expires_at: 2026-05-01T00:00:00Z

max_calls: optional

approval_required_for:

- external_message

- commerce

revocation_epoch: integer

status: active expired revoked

3. TaskEnvelope & RunEnvelope

The canonical definitions of work to be done, and the execution trace of that work.

TaskEnvelope:

task_id: task_...

requester_id: wallet://... | agent://... |
service://...
objective: string
task_class: coding | research | workflow
| commerce | render | connector |
service_delivery | other
privacy_class: public | internal | confidential
| regulated
execution_profile: local | hosted |
depin_mutual_blind | tee_enterprise |
customer\_vpc

input_refs:

- artifact://...
- agentgres://object/...

output_contract:

type: report | patch | artifact |
delivery_bundle | service_result | worker_result

required_receipts:

- execution

- validation

constraints:
deadline: optional

max_budget: optional

human_approval: optional

primitive_capabilities_required:

- prim:model.invoke

authority_scopes_required:

- scope:model.invoke.external

created_at: timestamp

training_spec_ref: optional

benchmark_profile_ref: optional

sparse_worker_category: optional

evaluation_rubric_ref: optional

contribution_policy_ref: optional

RunEnvelope:

run_id: run_...

task_id: task_...

runtime_id: runtime://...

worker_id: optional

service_id: optional

state: queued | assigned | starting |
running | awaiting_approval | paused |
completed | failed | cancelled
assignment:
node_id: node://...

placement_reason: string

privacy_mode: mutual_blind | enterprise_secure
| local | hosted

event_stream: /v1/runs/{run_id}/events

artifacts_endpoint: /v1/runs/{run_id}/artifacts

receipts_endpoint: /v1/runs/{run_id}/receipts

trace_endpoint: /v1/runs/{run_id}/trace

inspect_endpoint: /v1/runs/{run_id}/inspect

scorecard_endpoint: /v1/runs/{run_id}/scorecard

stop_condition: optional

task_state_ref: optional

agentgres_projection_watermark: optional

4. RuntimeEventEnvelope & ReceiptEnvelope

Events are the observational stream; receipts are attributable transaction records that bind declared boundary facts. A receipt is not a universal correctness, acceptance, or settlement proof. Evidence bundles, verification, acceptance, adjudication, and settlement remain separate assurance stages.

RuntimeEventEnvelope:

event_id: evt_...

parent_event_id: optional

run_id: run_...

task_id: task_...

turn_id: optional

kind: session.started | model.requested |
model.completed | tool.proposed | policy.decided
| approval.requested | tool.started |
tool.completed | artifact.created | receipt.emitted
| run.completed | run.failed
timestamp: timestamp
actor_id: agent://... | runtime://... |
wallet://...
privacy_class: public | internal | private
| secret
redaction_status: full | redacted | hash_only
payload: object

receipt_ref: optional

cursor: integer
terminal: boolean
ReceiptEnvelope:

receipt_id: receipt_...

receipt_type: registered receipt type

receipt_profile_ref: schema://...

attested_boundary_fact_refs: []

claim_scope_ref: schema://... | policy://... | null

run_id: optional

task_id: optional

actor_id: string

input_hash: optional

output_hash: optional

policy_hash: optional

authority_grant_id: optional

primitive_capabilities: []
authority_scopes: []
artifact_refs: []
evidence_bundle_refs: []
verification_ref: verifier_path://... | null
acceptance_ref: acceptance://... | null
adjudication_ref: decision://... | dispute://... | null
settlement_ref: settlement://... | null
timestamp: timestamp
signature: optional

l1_commitment: optional

The common-envelope owner defines this portable base. The canonical events-and-receipts owner maintains the exhaustive receipt-type registry and cross-component field profiles, including OutcomeRoom admission, discovery, participation, participant-state export, participant lease, frontier mutation, claim lease, resource allocation, attempt and finding admission, verifier challenge, WorkResult, and OutcomeDelta admission receipts. A specialized profile may add domain facts but cannot infer verification, acceptance, adjudication, or settlement merely because a receipt exists.

5. ArtifactEnvelope

The pointer linking Agentgres state to storage-backend payload bytes.

ArtifactEnvelope:

artifact_id: artifact_...

cid: bafy...
sha256: hash

size_bytes: integer

media_type: string

privacy_class: public | internal | private
| encrypted
encryption:
mode: none | envelope | threshold |
tee\_sealed

key_ref: optional

provenance:

run_id: optional

worker_id: optional

operation_id: optional

receipt_id: optional

access_policy_ref: optional

6. DeliveryEnvelope & SettlementEnvelope

The bridge between Agentgres operational truth and IOI L1 economic settlement.

DeliveryEnvelope:

delivery_id: delivery_...

service_order_id: optional

worker_invocation_id: optional

run_id: run_...

output_artifacts: []
evidence_bundle: []

quality_summary: object

policy_summary: object

settlement_status: pending | accepted |
disputed | paid | refunded

acceptance_deadline: optional

SettlementEnvelope:

settlement_id: settle_...

chain_id: ioi-mainnet

contract: string
action: escrow_lock | payout_release |
license_mint | dispute_open | dispute_resolve
| reputation_root_update
amount: optional
token: IOI | stablecoin | credit

related_delivery_id: optional

related_receipt_root: optional

tx_hash: optional

7. ContributionEnvelope

The mechanism for Marketplace Neutrality, Attribution, and Royalties.

ContributionEnvelope:

contribution_id: contrib_...

contributor_id: worker://... | service://... |
publisher://... | tool://... | model://...
consumer_id: wallet://... | service://... |
agent://...

task_id: task_...

contribution_type: worker_invocation |
service_delivery | tool_use | model_use |
dataset_use | workflow_use | verification |
training_data | training_service |
benchmark_submission | routing_selection |
verifier\_signal

usage_hash: hash

quality_delta: optional

reward_claim: optional

license_ref: optional

receipt_ref: receipt://...

sparse_worker_category: optional

benchmark_profile_ref: optional

routing_decision_ref: optional

downstream_outcome_ref: optional

dispute_status: none | pending | upheld
| rejected | no_fault

8. DomainOntologyEnvelope

Defines a namespaced, versioned semantic vocabulary under local canonicality. OntologyVersion and OntologyOverlay are profiles of this one base envelope rather than parallel schemas.

DomainOntologyEnvelope:
ontology_id: ontology://...
ontology_family_ref: ontology://...
ontology_record_profile: ontology_version | ontology_overlay
namespace: uri_or_domain_scoped_name
domain_ref: agentgres://domain/... | service://... | org://...
version: semver_or_hash
predecessor_version_ref: ontology://... | null
base_ontology_version_refs: [ontology://...]
local_canonicality_scope_ref: domain://... | org://... | project://...
compatibility_profile_ref: compatibility://... | null
deprecation_policy_ref: policy://... | null

entity_types: [TypeDecl]
relationship_types: [RelDecl]
event_types: [EventDecl]
action_types: [ActionDecl]
state_machines: [StateMachineDecl]
invariant_refs: [invariant://...]
owner_id: wallet://... | org://... | service://...
policy_hash: hash
status: draft | active | deprecated | revoked

The companion shared families are:

OntologyAssertionEnvelope: assertion ID and profile, ontology, subject/predicate/value, valid and transaction time, source and observation context, confidence or uncertainty, supporting and contradicting evidence, applicability, causal or counterfactual context, supersession, dispute, admission receipt, and proposed/admitted/contradicted/superseded/disputed/ rejected state.
OntologyMappingEnvelope: source and target ontology versions, crosswalk or semantic-decision profile, application targets, mapped object/relationship/event/action refs, exact/compatible/lossy/adapter/ incompatible result, policy-bound views, validation and challenge refs, decision maker and receipt, migration policy, and lifecycle state.
OntologyActionContractEnvelope: semantic action and target object, typed IO, preconditions, postconditions, invariants, expected transition, capabilities and runtime, risk, local policy and authority scopes, approval and revocation, preview, idempotency, recovery, reconciliation, compensation, verifier and evidence, receipts, and physical safety.

9. CanonicalObjectModelEnvelope

Grounds an ontology in concrete object schemas, IDs, lifecycle states, constraints, privacy classes, authority needs, and projection hints.

CanonicalObjectModelEnvelope:
object_model_id: ai://...
ontology_ref: ai://ontology/...

object_type: string

id_schema: IdSchemaDecl

fields: [FieldDecl]
lifecycle_states: [StateDecl]
constraints: [ConstraintDecl]
privacy_class: public | internal | confidential
| restricted | regulated
authority_requirements: [scope_ref]

projection_hints: optional

10. DataRecipeEnvelope

Defines how raw sources, connector payloads, documents, traces, and corrections are transformed into ontology-bound runtime, training, evaluation, and projection data.

DataRecipeEnvelope:
recipe_id: ai://...
ontology_refs: [ai://ontology/...]
connector_mapping_refs: [ai://mapping/...]
source_classes: [SourceClassDecl]
transform_steps: [TransformStep]
redaction_policy_ref: policy://...
dedupe_policy_ref: policy://...
validation_policy_ref: policy://...
output_object_model_refs: [ai://object-model/...]
output_dataset_refs: [ai://dataset/...]
output_projection_refs: [ai://projection/...]
receipt_obligations: [ReceiptObligation]

11. ConnectorMappingEnvelope

Maps provider fields, files, events, and actions from a connector into canonical object models and authority scopes.

ConnectorMappingEnvelope:
mapping_id: ai://...
connector_id: ioi://connector/...
provider_schema_ref: ref://...
object_model_refs: [ai://object-model/...]
field_mappings: [FieldMapping]
action_mappings: [ActionMapping]
authority_scope_refs: [scope_ref]
evidence_requirements: [EvidenceReq]
redaction_policy_ref: policy://...

12. PolicyBoundDataViewEnvelope

A scoped, policy-bound projection of domain data with explicit allowed uses, subjects, authority grants, and retention rules.

PolicyBoundDataViewEnvelope:
view_id: ai://...
domain_id: ioi://domain/...
ontology_refs: [ai://ontology/...]
object_model_refs: [ai://object-model/...]
source_refs: [ref://...]
allowed_uses: read | transform | distill
| train | evaluate | export |
publish | route
subject_refs: [subject://...]

policy_hash: hash

authority_grant_refs: [grant://...]
retention_policy_ref: policy://...

13. TransformationRunEnvelope

A single materialized execution of a DataRecipe under a policy-bound view, producing canonical objects, datasets, distilled datasets, and projections with a receipt root.

TransformationRunEnvelope:
run_id: ai://...
recipe_ref: ai://recipe/...
source_refs: [ref://...]
policy_bound_view_ref: ai://view/...

input_commitment: hash

output_object_refs: [ai://object/...]
output_dataset_refs: [ai://dataset/...]
output_distilled_dataset_refs: [ai://distilled/...]
output_projection_refs: [ai://projection/...]

transformation_receipt_root: hash

14. DistilledOntologyDatasetEnvelope

A compact, high-signal dataset derived from ontology-bound source truth via teacher workers, verifier workers, deterministic gates, human reviewers, and data recipes; binds full provenance.

DistilledOntologyDatasetEnvelope:
dataset_id: ai://...
source_dataset_refs: [ai://dataset/...]
ontology_refs: [ai://ontology/...]
data_recipe_refs: [ai://recipe/...]
policy_bound_view_refs: [ai://view/...]
source_commitments: [hash]

distillation_method: DistillationMethodDecl

teacher_worker_refs: [worker://...]
verifier_worker_refs: [worker://...]
rubric_refs: [rubric://...]
benchmark_profile_refs: [benchmark://...]
artifact_refs: [artifact://...]

receipt_root: hash

15. EvaluationDatasetEnvelope

The benchmark-facing counterpart to training data: golden, holdout, adversarial, regression, or distilled cases with rubric, benchmark, and provenance bindings.

EvaluationDatasetEnvelope:
dataset_id: ai://...
ontology_refs: [ai://ontology/...]
object_model_refs: [ai://object-model/...]
data_recipe_refs: [ai://recipe/...]
dataset_type: golden | holdout | adversarial
| regression | distilled
rubric_ref: rubric://...
benchmark_profile_refs: [benchmark://...]
artifact_refs: [artifact://...]
source_commitments: [hash]

receipt_root: hash

16. OntologyProjectionEnvelope

A materialized read surface over ontology-bound data: index refs, freshness SLO, and a checkpointed projection root.

OntologyProjectionEnvelope:
projection_id: ai://...
ontology_refs: [ai://ontology/...]
object_model_refs: [ai://object-model/...]
data_recipe_refs: [ai://recipe/...]
policy_bound_view_refs: [ai://view/...]
index_refs: [index://...]

freshness_slo: duration

projection_checkpoint_ref: ref://...

receipt_root: hash

17. OntologyToWorkerPlanEnvelope

Binds ontology, object models, recipes, views, distilled and evaluation datasets, and workflow schemas to a worker training objective, producing a worker manifest with a receipt root.

OntologyToWorkerPlanEnvelope:
plan_id: ai://...
ontology_refs: [ai://ontology/...]
object_model_refs: [ai://object-model/...]
data_recipe_refs: [ai://recipe/...]
policy_bound_view_refs: [ai://view/...]
distilled_dataset_refs: [ai://distilled/...]
evaluation_dataset_refs: [ai://dataset/...]
workflow_schema_refs: [workflow://...]

worker_objective: ObjectiveDecl

benchmark_profile_refs: [benchmark://...]
output_manifest_ref: ai://manifest/...

receipt_root: hash

18. Current Cross-Owner Object Families

The canonical envelope catalog is larger than the illustrative schemas in this appendix. Exact fields, versions, promotion rules, and implementation status remain owned by the current architecture documents. Major families that every implementation must account for include:

Goal orchestration: GoalRun, GoalGroundingLoop, RoleTopology, ContextCell, ContextLease, ContextHandoff, TaskBriefPayload, HarnessInvocation, HarnessAdapterEvent, generic WorkResultEnvelope, OutcomeDeltaEnvelope, software-specific ImplementationResultPayload, and VerifierPath.
Collaborative pursuit: OutcomeRoomDiscoveryEnvelope, RoomParticipationRequestEnvelope, OutcomeRoomEnvelope, RoomParticipantLeaseEnvelope, ParticipantStateBundleEnvelope, ResourceOfferEnvelope, CapabilityOfferEnvelope, WorkFrontierItemEnvelope, WorkClaimLeaseEnvelope, AttemptEnvelope, FindingEnvelope, and VerifierChallengeEnvelope. Every room declares hosted_admission or federated_admission; these objects do not define a second runtime, authority system, marketplace, or global mutable Agentgres graph.
Cross-party policy and funding: MultiPartyCollaborationEnvelope binds independently governed participant domains, disclosure, policy, verifier, challenge, dispute, and settlement refs. NetworkGoalBudgetEnvelope binds the separate cap, allocation, consent, contribution, and payout route for Network/Open work; it never creates an implicit draw on ordinary Goal Space Work Credits.
Federated semantic plane: immutable OntologyVersion and local OntologyOverlay profiles, provenance-bearing OntologyAssertion, explicit OntologyCrosswalk and SemanticMappingDecision profiles of OntologyMapping, and executable OntologyActionContract bindings. Local canonicality, mapping ambiguity, uncertainty, contradiction, supersession, and dispute remain explicit.
Agent operating plane: configured agent/model/harness records, work queues, work items, WorkRuns, conversation/review projections, authority, usage, and execution/security telemetry.
Agentgres branches (planned/partial): AgentExecutionTrace, AgentExecutionBranch, StagedEffect, BranchCheckpoint, and BranchMergePlan. Merge admission must revalidate current authority and policy; branch evidence cannot replay stale authority.
Portable memory: MemorySpace, memory entries, skills, affinities, scoped MemoryProjections, and ContextMutationEnvelope proposals under the ioi.hypervisor.memory-vault.v1 transport.
Provider placement: ProviderAccount, ProviderCredentialBinding, RuntimeNode, CloudResourceIntent, CloudResourceCandidate, PlacementDecision, SnapshotRef, RestoreRef, SpendReceipt, and ProviderOperationReceipt.
Model route rights: ModelRouteRightsContract binds the provider and model, credential principal, commercial posture, automation/customer-facing/downstream-use rights, contract version and hash, validity window, data/retention/region policy, fallback policy, price basis, and separate inference, training, distillation, and OEM/resale permissions. Missing rights fail closed.
Assurance: EcosystemAssuranceProfile, ConformanceProfile, CertificationClaim, JurisdictionPolicyPack, AssuranceEvidenceBundle, AssurancePostureProjection, QuarantineAdvisory, LiabilityClaimRoute, and CommercialAssuranceExport.
Embodied runtime and physical safety: robot/fleet identity, controller/sensor/actuator registries, world state, command queues, telemetry/replay, PhysicalActionIntent, PhysicalMissionControlEnvelope, LocalControlSegment, PhysicalActionSegmentCommitmentReceipt, PhysicalActionPolicy, SafetyEnvelope, EmergencyStopAuthority, SensorEvidenceReceipt, and ActuatorCommandReceipt.

These families preserve the same split: proposals and candidates are not authority; local/domain policy and the applicable authority provider authorize; wallet.network is mandatory for portable delegated authority and designated high-risk external effects; the daemon admits, enforces, and executes; Agentgres admits operational truth; storage holds bytes; and a future IOI L1 receives only selected public commitments.

B.5 Worker Training, Evaluation, and Benchmark Envelopes

Specialized envelopes for the Worker Training Pipeline, benchmark execution, and MoW routing decisions. These compose with the canonical envelopes in B.4 and produce specialized Class 1 Receipts.

WorkerTrainingEnvelope:

training_id: train_...

target_worker_id: worker://...
requester_id: wallet://... | service://... |
org://...
provider_id: worker://... | service://... |
publisher://...

training_objective: string

domain_ontology_refs: [ai://ontology/...]
data_recipe_refs: [ai://recipe/...]
policy_bound_data_view_refs: [ai://view/...]
distilled_dataset_refs: [ai://distilled/...]
evaluation_dataset_refs: [ai://dataset/...]

training_methods:

- prompt_optimization

- workflow_trace_learning

- retrieval_curation

- verifier_tuning

- model_finetune

- distillation

- policy_hardening

- context_graph_revision

- route_policy_training

- synthetic_dataset_planning

- synthetic_generation

- deterministic_quality_gating

- semantic_quality_gating

- evaluation_benchmarking

pipeline_roles:

planner_workers:

- worker://...

generator_workers:

- worker://...

verifier_workers:

- worker://...

execution_environment:

locality: local remote hybrid undisclosed

dataset_commitment: hash

synthetic_corpus_commitment: optional_hash

privacy_policy_ref: optional

evaluation_rubric_ref: rubric://...
benchmark_profile_ref: benchmark://...

evaluation_receipts:

- receipt://...

contribution_receipts:

- receipt://...
output_manifest_ref: ai://...

receipt_root: hash

status: proposed | running | evaluated
| accepted | rejected | disputed
BenchmarkEnvelope:

benchmark_run_id: bench_...

worker_id: worker://...

sparse_worker_category: string

benchmark_profile_ref: benchmark://...

environment_hash: hash

manifest_hash: hash

policy_hash: hash

score_commitment: hash

evaluator_id: worker://... verifier://...

evaluation_receipt_root: hash

routing_eligibility_result: eligible | ineligible
| suspended
RoutingDecisionEnvelope:

routing_decision_id: route_...

task_id: task://...
router_id: worker://... | runtime://...

candidate_set_commitment: hash

routing_policy_hash: hash

selected_worker_id: worker://...

selection_reason: string

contribution_policy_ref: optional

receipt_obligations: []
signature: optional
TrainingProfileEnvelope:

profile_id: train_profile_...

worker_architecture_class: planner | executor
| verifier | router | specialist |
hybrid

cognition_backend_refs: [model://... | api://...
| local://...]

context_strategy: ContextStrategyDecl

adapter_strategy: AdapterStrategyDecl

distillation_strategy: DistillationStrategyDecl

local_remote_compute_policy: local remote hybrid

benchmark_requirements: [benchmark://...]
promotion_requirements: [RequirementDecl]
regression_requirements: [RequirementDecl]
WorkerCardEnvelope:
worker_id: worker://...
manifest_ref: ai://manifest/...

task_class: string

ontology_refs: [ai://ontology/...]
data_recipe_refs: [ai://recipe/...]
distilled_dataset_refs: [ai://distilled/...]
evaluation_receipt_refs: [receipt://...]
benchmark_receipt_refs: [receipt://...]
known_limitations: [string]
authority_requirements: [scope_ref]
runtime_profiles: [profile_ref]
interaction_surfaces: [surface_ref]
deployment_options: [deployment_ref]
contribution_policy_ref: policy://...
ManagedWorkerInstanceEnvelope:

instance_id: inst_...

worker_manifest_ref: ai://manifest/...

worker_version: semver_or_hash

owner_ref: wallet://... | org://... |
project://...

tenant_ref: optional

install_right_ref: ref://...
license_ref: license://...
runtime_profile_ref: profile://...
runtime_assignment_ref: assignment://... | optional
persistence_profile: per_invocation | warm |
persistent | zero_to_idle
authority_policy_ref: policy://...
wallet_grant_refs: [grant://...]
memory_policy_ref: policy://...
archive_policy_ref: policy://...

latest_state_root: hash

archive_refs: [cid://...]

interaction_surfaces:

- web_chat

- api

- hypervisor

- workflow

- sas_outcome

- mow_route

subscription_ref: sub://... optional

receipt_root: hash

lifecycle_status: initializing | ready |
running | idle | archived | suspended
| revoked
RuntimeSubscriptionEnvelope:

subscription_id: sub_...

owner_ref: wallet://... | org://... |
project://...
managed_instance_ref: inst://... | optional
mode: standard | private
compute_profile_ref: profile://...
budget_policy_ref: policy://...
entitlement_ref: entitlement://...
billing_ref: billing://...
status: pending | active | suspended | expired |
revoked
valid_from: timestamp
valid_until: timestamp
renewal_policy_ref: policy://... | optional

receipt_root: hash

WorkerInstallReceipt:

receipt_id: receipt_...

worker_manifest_ref: ai://manifest/...
installer_ref: wallet://... | org://...
install_right_ref: ref://...
license_ref: license://...

policy_hash: hash

created_instance_ref: inst://...

receipt_time: timestamp

ManagedInvocationReceipt:

receipt_id: receipt_...

instance_ref: inst://...
invocation_ref: invocation://...
runtime_assignment_ref: assignment://...
authority_grant_refs: [grant://...]

input_commitment: hash

output_commitment: hash

artifact_refs: [artifact://...]
contribution_refs: [contribution://...]

receipt_time: timestamp

Appendix C: Developer Contract Sketch and Connector Manifest

This appendix illustrates the relationship among worker logic, policy, and manifest objects. It is not a runnable SDK quickstart or a normative package schema; current SDK/ADK/ODK and connector/tool owner documents govern exact APIs, manifests, mappings, authority, execution, analytics, and receipt contracts.

Scenario: A "Research Assistant" that fetches a webpage, summarizes it using a local LLM, and saves the result.

C.1 The Worker Logic (src/agent.py)

A developer-facing SDK may expose an equivalent bounded handler. The exact language and API shown here are illustrative; no blockchain code is required for local governed execution.

C.2 The Policy Envelope (policy.json)

The firewall rules that govern the agent's execution. This ensures the agent cannot exfiltrate the user's SSH keys or drain their wallet.

C.3 The Worker Manifest (manifest.json)

The declarative manifest published to aiagent.xyz.

C.4 Illustrative Connector Manifest

To ensure agents can be swapped between providers (avoiding vendor lock-in), Connectors are defined by schema, not proprietary code.

C.5 Lifecycle of an Agentic Transaction (Worked Example)

Linear flow of data transformation.

Appendix D: Claims and Non-Claims (The Scope of Verification)

To provide absolute clarity to developers, cryptographers, legal arbiters, and protocol auditors, the Hypervisor framework makes the following explicit boundaries regarding its cryptographic proofs. The protocol is designed around the philosophy of Process Safety over Model Safety; therefore, we explicitly bound the scope of what is mathematically guaranteed versus what is classified as heuristic or non-binding telemetry.

D.1 What the IOI Protocol PROVES (Normative Guarantees)

The proof carried by an IOI artifact is limited to the claims supported by its cryptography, verifier, evidence source, and threat model. Given valid implementations and the declared assumptions, an admitted receipt or proof may establish:

The assurance state of the surrounding claim remains explicit: receipt or attestation, evidence bundle, verification, acceptance, adjudication, and settlement are distinct stages. Establishing one item below does not imply the later stages unless the corresponding refs and governing contract establish them.

Committed bytes and canonicalization: The exact canonical bytes, identifiers, hashes, versions, and domain-separated commitments signed or included in the artifact.
Declared policy and authority bindings: Which policy hash, authority artifact, scope, approval, expiry, and revocation epoch were bound to the decision. A hash proves the binding, not faithful enforcement by unverified code or hardware.
Signature and approval validity: That the included signatures or approvals verify under the declared keys and algorithms and bind the shown request. This does not independently prove informed human understanding or legal consent.
Ordering and inclusion: That named receipts or events occur in a committed sequence, Merkle tree, operation log, state root, or bundle when the supplied inclusion and ordering proofs verify.
Recorded execution-boundary result: What the admitted runtime, adapter, provider, tool, sensor, actuator, or verifier reported, including success, denial, failure, observation, cost, and artifact refs. A signed report proves attribution to the signer, not the truth of every reported real-world fact.
Verifier results: That a named verifier accepted, rejected, or abstained on a claim under a declared version, input commitment, and assumption set. The verifier result is no broader than the verifier’s specification and evidence coverage.
Replay and state-root consistency: That replay of the complete admitted operation and artifact set reproduces the stated projection or state root, when all required bytes and deterministic code are available.
Specific proof-system or attestation claims: A valid ZK, MPC, FHE, TEE, cTEE custody, timestamp, transparency-log, or external-evidence proof establishes only the exact statement specified by its profile and verifier under its stated assumptions.

The architecture, product topology, openness of routing, correctness of a model, safety of a physical act, legal consent, insurance coverage, and faithful enforcement are not made true merely by placing their labels or hashes inside a receipt.

D.2 What the IOI Protocol DOES NOT CLAIM (Non-Claims)

To avoid the architectural traps of first-generation Decentralized AI networks, IOI explicitly does not claim the following:

Bit-for-bit equivalence of foundational model inference: IOI does not claim an LLM will output the exact same tokens when run on an Nvidia H100 versus an Apple M3 chip. IOI embraces floating-point drift at the heavy cognition layer. We claim only that the Decision Verdict rendered by the daemon effect boundary is fully deterministic. This is achieved via strict JCS normalization of ActionRequests and, for sensitive egress cases, deterministic inspection profiles such as inspection_v0 over local evidence graphs.
Every local action is on-chain: IOI does not claim, require, or desire that every local action, tool call, click, inference step, or filesystem access become a Mainnet transaction. The claim is narrower and stronger: any consequential boundary of Web4 Act must be transaction-shaped and capable of settlement or recourse when required.
cTEE is not arbitrary full-speed private LLM inference on hostile-root consumer GPUs: IOI does not claim to run full-parameter private LLM evaluations (e.g., Llama-3 70B) in plaintext on untrusted, consumer-grade rented GPUs without leakage. High-throughput execution uses Candidate-Lattice Private Decoding, where the model computes public weights to output structured token options while the private-head parameters are evaluated inside secure boundaries.
cTEE does not protect plaintext proprietary model weights mounted on a hostile-root rented GPU: if a developer mounts unencrypted model weights to a node where the provider holds host-root permissions, those weights are exposed. Protecting proprietary model IP requires a separate ModelWeightCustodyProfile: local or customer-controlled custody, provider API custody, accepted TEE/customer-cloud custody, cryptographic-operator partitioning, or an explicitly receipted provider-trust route. Private Workspace backed by cTEE protects workspace state; it does not by itself make proprietary weights safe on hostile-root hardware.
A software-only cTEE sandbox does not protect plaintext proprietary weights in hostile-root GPU memory: the IOI Hypervisor does not claim that a software-only cTEE protects proprietary weights loaded in plaintext into standard GPU memory on a hostile-root system. If a model owner mounts unencrypted weights on a remote machine without hardware confidential compute (TEEs) or cryptographic-operator partitioning, those weights can be dumped by the host administrator.
Third-party model APIs are not a zero-knowledge or zero-disclosure path: when a worker routes tool parameters or prompts to a proprietary remote API, those inputs cross the provider-trust boundary and are explicitly not a private execution pathway relative to that model provider.
Measured boot / HypervisorOS is not a substitute for cTEE no-plaintext-custody or hardware confidential GPU protection: proving that a node booted a valid, measured kernel image (via a HypervisorOSBootReceipt) does not stop a physical host operator with a logic analyzer or malicious motherboard implants from capturing data in transit.
Measured boot does not equal confidential computing: measured boot proves what software booted on the hardware; confidential computing (such as AMD SEV-SNP or Intel SGX) actively protects running memory from unauthorized host observation. HypervisorOS relies on confidential hardware or cTEE software envelopes when weight secrecy is required.
Universal Knowledge Optimality: IOI does not prove that a worker used the best information available in the global universe. It proves only that the committed context slice, retrieval inputs, and evidence references were faithfully packaged and bound to the intent under the declared policy. If a superior source was never present in the worker’s accessible memory/retrieval plane, retrieval corpus, or authorized context window, IOI cannot prove it should have been used.
Wall-clock timestamps as consensus truth: While the runtime records local SystemTime for telemetry and debug activity streams (WorkloadReceiptEvent), these are observational artifacts. IOI does not treat local wall-clock time as a Byzantine-fault-tolerant source of truth. All enforceable expiries and sequencing rely strictly on Chain Time or monotonic block heights.
Semantic Correctness: The protocol proves Intent Compliance (did the agent do what it said it would do within the rules?), not Semantic Wisdom. If a worker is authorized to spend $50 and it buys a useless asset within that authorized scope, the protocol proves the spend was authorized and executed; it does not claim the worker made a "smart" decision. Web4 proves executable ownership and accountable consequence, not wisdom. Economic liability for an authorized but poor result, policy breach, provider failure, or developer defect is determined by the governing contract, evidence, jurisdiction, assurance posture, and claims process rather than a universal source-based rule in this whitepaper.
Total On-Chain Duplication: IOI does not claim that every state change or module invocation is duplicated on IOI L1. Hypervisor Node local settlement is designed to avoid public chain spam, storing operational and intermediate execution state locally within Agentgres.
Monolithic Binaries: IOI does not claim that the Hypervisor Node binary contains or owns model weights by default. Models are treated strictly as mounted cognition backends whose lifecycles are governed by independent deployment profiles.
Hardware attestation as authority: IOI does not claim that a TEE quote, secure enclave measurement, or confidential-compute attestation is sufficient to authorize an action. Hardware attestation may contribute evidence, but validity depends on the complete receipt set, policy hash, approval chain, capability scope, and settlement rules.
Cryptographic compute as universal runtime: IOI does not claim that FHE, MPC, ZK-ML, or proof VMs can currently replace all general-purpose agent execution. These substrates are strongest for bounded, typed, circuit-shaped, replayable, or privacy-sensitive subclaims. General browser automation, desktop operation, long-horizon mutable workflows, and open-ended agent behavior still require IOI’s broader receipt and settlement boundary.
Private-execution non-exposure as absolute secrecy: Private-execution paths reduce disclosure under a declared threat model. They do not eliminate all side channels, implementation bugs, model leakage, misuse, or legal discovery risk. IOI’s claim is narrower: the action’s evidence posture, leakage bounds, and verifier requirements are explicit, auditable, and settlement-bound.
Global AI alignment: IOI does not claim to solve global AI alignment or inner alignment within neural networks. The protocol is strictly an execution-boundary containment system; it bounds the consequential effects of machine authority, and does not legislate the values, training data, or internal goals of any model.
Raw model output as authoritative: IOI does not claim that raw model output is legally or economically authoritative by itself. Authority attaches to the canonical ActionRequest, policy hash, approval chain, capability scope, and receipt set that wrap the output, not to the output as such. A receipt does not prove the underlying model was wise, truthful, or globally optimal.
Agentgres as universal store: Agentgres is not a universal replacement for OLAP engines, vector databases, blob stores, local UI state, generic event logs, or IOI L1 settlement.
SQL writes bypassing operation settlement: Agentgres does not allow arbitrary SQL writes to bypass operation settlement. The Postgres bridge serves projection reads; canonical writes must compile into Agentgres operations.
Sealed archive as authority: A sealed archive does not prove restore authority by existing. A blob CID is not canonical runtime truth by itself; Agentgres records the archive meaning, policy/authority refs, state root, and restore receipts, while applicable authority providers decide who may restore.
Omnipresent control over opaque runtimes: The IOI Authority Gateway does not claim to have direct, internal visibility into the state machines of closed-source, remote, or compiled third-party agent systems. Instead, it mediates only the control points an adapter can observe and can record proposals, decisions, observations, and receipts at those points. It cannot prove that opaque effects outside those hooks were intercepted or did not occur.
Static encryption-at-rest as no-plaintext-custody: static “encryption-at-rest” is not a substitute for dynamic no-plaintext-custody. If a node retains plaintext custody of data in memory during execution, its state is compromised on a hostile-root machine.
Storage backends owning artifact meaning: storage backends (such as Filecoin, IPFS, S3, or local disk) do not own or understand artifact meaning. They are passive byte repositories; meaning is owned exclusively by the Agentgres Artifact Plane via ArtifactRefs and receipt linkages.
Fuzzy memory as the complete cognition substrate: neither the Agent Wiki (ioi-memory) nor Agentgres is the complete cognition substrate of the worker. Fuzzy, volatile context resides in the semantic memory plane and crosses the Agentgres admission boundary via ContextMutation commits only when state must be rendered durable and portable.
Reversibility of embodied action: physical robotics and embodied actions cannot be “undone” or rolled back like local database rows. They require first-class physical safety primitives, including a defined SafetyEnvelope, a PhysicalActionPolicy, and an override-capable EmergencyStopAuthority.
Participant consensus as truth or authority: an OutcomeRoom board, chat, vote, leaderboard, repeated model answer, or participant consensus is an evidence input and projection. It does not admit a CollaborativeWorkGraph mutation, widen authority, promote memory or ontology state, or establish correctness without the declared hosted or federated admission and verifier path.
One global collaboration or ontology database: AIIP and OutcomeRooms do not merge sovereign Agentgres domains into one mutable graph. Federated ontologies preserve local canonicality, namespace, version, mappings, uncertainty, contradiction, and policy-bound views. The shared room state always names a hosted admission domain or versioned federated admission policy.
Multiplicity as independence: multiple models, Workers, runtime nodes, clouds, providers, or keys controlled by one principal are not independent parties merely because they are numerous. Multi-party claims require disclosed affiliations and separate accountable control over authority, revocation, truth, risk, verification, challenge, or settlement.
Environment recovery as outcome recovery: restoring a VM, channel, workspace, Worker, or provider session does not prove that an external API, payment, message, deployment, or physical action did or did not commit. Consequential effects declare replayable, checkpointable, compensatable, reconciliation_required, or non_retryable; ambiguous effects are reconciled before retry, and compensation is separately authorized and receipted.
Daemon admission as authority: the daemon admits and enforces work and mediates or executes effects, but it does not self-grant portable, secret-bearing, spend-bearing, declassification, cross-domain, or high-risk power. Local/domain policy and the applicable authority provider authorize; Agentgres admits resulting durable operational truth.

The Physics-to-Digital Evidence Loop (Target Embodied Runtime)

IOI cannot rewrite physical laws and does not claim to make the material world cryptographically reversible. The speculative Embodied Runtime target binds PhysicalActionIntent, safety-policy refs, authority refs, sensor evidence, command hashes, adapter/controller identity, results, telemetry, incidents, and recovery state through receipts and Agentgres admission. Those records support audit and verification under their capture and trust assumptions; they do not independently prove that a physical condition was safe or that motion occurred faithfully. Local safety controllers and hardware interlocks retain the real-time veto. Any future escrow, liability, or dispute consequence must come from an implemented governing contract and verified evidence, not an automatic rule in this whitepaper.

D.3 Benchmark and Routing Non-Claims

IOI BenchmarkReceipts record a benchmark execution and verifier result under a declared profile, environment, rubric, evidence set, and worker manifest. They support the scoped benchmark claim under those assumptions; they do not prove universal intelligence, universal optimality, or permanent superiority across all future tasks.

MoW routing receipts record that a worker was selected from a declared candidate set under a named routing policy and decision material. They do not prove that the policy was faithfully implemented without applicable conformance evidence or that the selected worker is globally best. They make the declared decision inspectable and challengeable.

Sparse Worker Categories are relative labor markets, not universal intelligence rankings.

Appendix E: Fail-Closed Verdict Logic

This appendix summarizes the normative conformance contracts for Hypervisor Core, the Hypervisor Daemon, and compatible harness profile adapters. To guarantee that autonomous systems cannot bypass safety constraints, the runtime must enforce the Intent Resolution Contract (CIRC), the Effect Execution Contract (CEC), and the Harness Profile Adapter Conformance boundary for third-party harnesses, model runtimes, worker profiles, and module executors.

These rules dictate the “Fail-Closed” behavior of the Hypervisor Core and daemon effect boundary. They enforce a “Zero Heuristics / Zero Hidden Fallbacks” doctrine: zero ad hoc, topic-specific, provider-shortcut, or hidden-fallback heuristics that bypass typed intent resolution, plus zero unreceipted effect retries hidden inside one admitted operation. Generic deterministic heuristics remain allowed when they are feature-based, cross-domain, task-class-aware, explainable, and policy-controlled. They are the conformance rules that prevent Act from degrading into Web2 automation: if intent cannot acquire transaction shape, it cannot become sovereign consequence.

E.1 Intent Resolution Contract (CIRC)

CIRC governs the pre-execution phase. It is the semantic collapse contract. It ensures that probabilistic inference (e.g., embedding searches, LLM intent parsing) collapses into one deterministic, replayable route decision or an explicit abstention.

To pass the CIRC gate, the Hypervisor Daemon MUST enforce the following invariants:

The Three-Layer Rule: The resolver MUST enforce distinct layers:
1. Intent: Domain-level semantics (what the user wants).
2. Capability: Primitive execution boundaries (prim:*, what is physically possible and isolated).
3. Tool: Concrete implementation mechanism (how the action is executed).
4. Fail-Closed Action: If a tool tries to bypass semantic ranking or if capabilities encode domain logic (e.g., prim:math.eval instead of prim:sys.exec), the runtime MUST reject the configuration with OntologyViolation.
The Structural Retrieval Rule: Retrieval affordances MUST describe structural evidence shapes (e.g., queryable_index, timestamped_record), not domain semantics or provider families (e.g., google_news).
1. Fail-Closed Action: If query inference directly emits provider IDs, hostnames, or pre-designated query-class switchboards instead of typed retrieval requirements, the runtime MUST abort with ResolverContractViolation.
Feasibility & Hard Constraints: Feasibility MUST be determined strictly upfront. Trial-and-error routing is forbidden. The resolver MUST verify that all required prim:* capabilities are satisfiable by the active tools, and that applicable authority and policy do not prohibit execution.
1. Fail-Closed Action: If the top-ranked intent is infeasible, selection MUST proceed in ranked order to the next feasible intent. Only when no admissible candidate remains may the resolver emit a typed infeasible, blocked, ambiguous, or abstention state. It MUST NOT short-circuit to a tool before deterministic intent winner selection.

E.2 Effect Execution Contract (CEC)

CEC governs the post-resolution execution discipline. It is the effect collapse contract. CEC takes the already-resolved intent and governs payload synthesis, execution, and verification. It permits probabilistic synthesis prior to execution, while strictly enforcing an admitted-effect boundary during execution. Hidden retries inside that admitted effect are forbidden; governed remediation opens a new ActionProposal, gate, receipt, and observation path.

The Hypervisor Daemon MUST enforce the CEC Execution State Machine:

contract_loaded & discovery: The runtime gathers ground-truth host topology and provider candidates based on typed discovery.
provider_selection / payload_synthesis (The Safe Sandbox): Probabilistically generating, linting, dry-running, and iteratively refining the execution payload is explicitly permitted and encouraged within this state only.
execution (The Admitted-Effect Boundary): Once the payload transitions to execution, that admitted effect is committed. It MUST be one deterministic effect attempt under the current receipt chain.
1. Fail-Closed Action: Post-execution heuristic retries using the real environment as a sandbox (unbounded “try-and-catch” code-rewriting loops) are strictly forbidden inside the same admitted effect. If execution fails, it MUST emit ExecutionFailedTerminal, partial, blocked, or unverified. A repair attempt must begin as a new proposal with new gate and receipt material.
verification: The runtime MUST verify read-state evidence with a cryptographic commit. It MUST NOT assume success from process exit status alone.
completion_gate & terminal: The final gate before integration.

To pass the CEC Completion Gate, the Hypervisor Daemon MUST enforce the following:

The Judge Integrity Rule: Runtime success adjudication MUST be receipt-driven. Final chat reply text or debug strings MUST NOT be the primary evidence channel for pass/fail. Completion gates MUST rely on typed receipt fields (e.g., contract_version, satisfied, evidence_commit_hash).
Receipt Completeness Invariant: Every governed execution MUST emit machine-readable evidence records matching its applicability_class (e.g., topology_dependent, deterministic_local, remote_retrieval).
1. Fail-Closed Action: If any required receipt is missing, any required postcondition is missing, or verification fails, the runtime MUST emit ERROR_CLASS=ExecutionContractViolation and block the agent__complete status.

E.3 Harness Profile Adapter Conformance

Hypervisor may route work through Codex-style coding agents, Claude Code-style CLIs, DeepSeek-style harnesses, OpenHands/Aider-style local tools, hosted workers, Rust/WASM modules, service engines, and custom enterprise harnesses. These systems are useful execution participants, but they are not authority roots and not completion truth.

Every HarnessProfile Adapter must publish a descriptor declaring its primitive capabilities, authority-scope requirements, supported receipts, state projection rules, secret-handling posture, cTEE compatibility, and replay support. It must map harness-native events into Hypervisor objects: resolver receipts, ActionProposals, GateResults, ExecutionResults, NormalizedObservations, ArtifactRefs/PayloadRefs, and terminal receipt candidates. It must not hold wallet.network root secrets, mint scope:* grants, widen policy, bypass step-up, treat harness-native approval prompts as wallet.network approvals, or treat harness memory as Agentgres truth.

This adapter rule is what allows IOI to benefit from a growing ecosystem of open-source and proprietary harnesses without making any one harness the protocol substrate.

E.4 The Anti-Heuristic Doctrine

In the IOI architecture, ambiguity equals failure. There are no “best effort” policy bypasses or “heuristic” state merges.

Implementations MUST NOT:

Use predesignated query archetypes or domain buckets as a stand-in for typed provider discovery.
Gate success primarily on reply text or substring matches over debug output.
Route back to payload synthesis for a heuristic retry after a verification failure at the completion gate.

This Fail-Closed Verdict Logic is the bedrock of the Determinism Boundary. It means that while an agent’s thoughts and synthesis may be probabilistic and creative, its admitted consequences must cross a mathematically bound, receipt-backed, policy-explainable effect boundary. Insurability and legal recourse depend on the declared contract, jurisdiction, and receipt class rather than on raw model output.

Appendix F: References & Normative Standards

This section details the normative specifications, cryptographic standards, and academic literature that form the foundational assumptions of the IOI Protocol.

F.1 Normative IETF & Web Standards

These standards govern the deterministic formulation of intents, payload serialization, and network routing within the Hypervisor Daemon and IOI L0/domain substrate.

[RFC 8785] Rundgren, A., Harrison, R., & Sporny, C. (2020). JSON Canonicalization Scheme (JCS). Internet Engineering Task Force (IETF). Defines the strict canonicalization required to prevent hash malleability in JSON payloads (used throughout the IOI Determinism Boundary).
[RFC 3986] Berners-Lee, T., Fielding, R., & Masinter, L. (2005). Uniform Resource Identifier (URI): Generic Syntax. IETF. Defines the parsing and resolution structure adapted for the ai:// identifier grammar used by the Inter-Autonomous-System Protocol (AIIP).
[RFC 5234] Crocker, D., & Overell, P. (2008). Augmented BNF for Syntax Specifications: ABNF. IETF. Defines the grammar for parsing the AIIP namespace.
[RFC 8949] Bormann, C., & Hoffman, P. (2020). Concise Binary Object Representation (CBOR). IETF. An available versioned binary encoding for owner contracts that select it; this whitepaper does not mandate a universal offload or session-packet format.
[RFC 3161] Adams, C., Cain, P., Pinkas, D., & Zuccherato, R. (2001). Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). IETF. Referenced for off-chain anchor validity.

F.2 Cryptographic Standards (Post-Quantum & Classical)

The protocol’s Strict Hybrid Cryptography model relies on the following National Institute of Standards and Technology (NIST) and industry specifications.

[FIPS 202] National Institute of Standards and Technology. (2015). SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. Defines the SHAKE-256 algorithm targeted for Post-Quantum artifact hashing.
[FIPS 203] National Institute of Standards and Technology. (2024). Module-Lattice-Based Key-Encapsulation Mechanism Standard. Defines the ML-KEM family, which a reviewed versioned hybrid transport profile may select with explicit parameters.
[FIPS 204] National Institute of Standards and Technology. (2024). Module-Lattice-Based Digital Signature Standard. Defines the ML-DSA family, which a reviewed versioned authority or commitment profile may select.
[RFC 8032] Josefsson, S., & Liusvaara, I. (2017). Edwards-Curve Digital Signature Algorithm (EdDSA). IETF. Defines EdDSA, an available classical signature family for profiles that select it. No genesis or wallet suite is selected in this whitepaper.
[BLAKE3] O'Connor, J., Aumasson, J. P., Neves, S., & Wilcox-O'Hearn, Z. (2020). BLAKE3: one function, fast everywhere. A candidate high-throughput hash for owner profiles; not a protocol-wide fixed choice here.

F.3 Consensus & Distributed Systems

The challenge-dominant settlement research candidate in Section 5.3 draws on the following BFT and distributed-systems research. These references do not constitute a selected IOI L1 consensus engine.

[PBFT] Castro, M., & Liskov, B. (1999). Practical Byzantine Fault Tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). The foundational baseline for BFT mesh assumptions.
[HotStuff] Yin, M., Malkhi, D., Reiter, M. K., Gueta, G. G., & Abraham, I. (2019). HotStuff: BFT Consensus with Linearity and Responsiveness. Proceedings of the ACM Symposium on Principles of Distributed Computing (PODC). Serves as the structural background for possible linear-view research profiles.
[MinBFT] Veronese, G. S., Correia, M., Bessani, A. N., & Lung, L. C. (2011). Efficient Byzantine Fault-Tolerance. IEEE Transactions on Computers. Provides the mathematical proofs that hardware-backed monotonic counters can reduce equivocation, enabling more efficient Byzantine fault-tolerant replication under the paper’s stated assumptions.

F.4 Artificial Intelligence & Infrastructure

Protocols and algorithms supporting the cognitive and operational capabilities of the IOI architecture.

[MCP] Anthropic. (2024). Model Context Protocol Specification. The standard open integration protocol utilized by the IOI Authority Gateway to securely expose and mediate host tools to external agent harnesses.
[ERC-4337] Buterin, V., et al. (2021). Account Abstraction Using Alt Mempool. Ethereum Improvement Proposals. The structural target for the Agent Execution Account managed by wallet.network policy and authority grants.
[MoE] Shazeer, N., et al. (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer. Referenced as the model-routing analogue for IOI’s execution-layer Mixture of Workers concept.

F.5 Commercial Model-Supply Boundary (Non-Normative Procurement Evidence)

The following provider materials were reviewed on July 11, 2026. They explain the commercial boundary motivating ModelRouteRightsContract; they are dated procurement evidence, not permanent protocol law. Runtime admission must resolve the current terms, order form, model-specific terms, and signed agreement rather than relying on this snapshot.

[OpenAI Services Agreement] OpenAI. (effective January 1, 2026). OpenAI Services Agreement. Distinguishes licensed business/API use, individual end-user accounts, credential sharing restrictions, customer applications, and usage-based services.
[OpenAI Subscription/API Separation] OpenAI Help Center. How can I move my ChatGPT subscription to the API?. States that ChatGPT subscription and API billing are separately managed.
[Anthropic Subscription/API Separation] Anthropic Help Center. (March 16, 2026). Paid Claude plans and API/Console separation. Distinguishes interactive paid plans from separately provisioned developer API access.
[OpenRouter Terms and Routing] OpenRouter. (terms updated July 6, 2026). Terms of Service and Provider Routing. Establish that aggregator access remains subject to applicable model terms, provider/data-policy selection, fallback behavior, and resale restrictions.

IOI: Internet of Intelligence Technical Whitepaper

Abstract

Executive Summary

Table of Contents

1. Web4 Thesis and Scope

1.1 From Shared Gradients to Verifiable Labor

1.2 North-Star Internet-of-Intelligence Network Proof

2. The IOI Runtime Architecture

2.1 The Protocol Core: The Four Pillars of Agency

2.2 The Hypervisor Daemon & Multi-Plane Architecture

2.2.1 Plane-Enforced Isolation

2.2.2 Deterministic IO and Pinned Externalities

2.2.3 The Sidecar Deployment Profile (IOI Authority Gateway)

2.2.4 Goal Kernel, Outcome Rooms, and Typed Harness Brokerage

2.3 The Anatomy of a Worker

2.3.1 Model Weight Custody and Routing Boundaries

2.4 The Determinism Boundary (Invariant)

2.4.1 Typed Intent, Constraints, and Acceptance Contract

2.4.2 The Adversarial Hierarchy (Adaptive Work Graphs / Deterministic Gate)

2.5 Fractal Edge-In Topology and the L0/L1 Boundary

2.5.1 The Three Execution Axes

2.5.2 Managed Execution Modes

2.5.3 Agentgres: The Per-Domain State Substrate

2.5.4 The "Eject" Bridge: Pointer-Based State Injection

2.5.5 Node Profiles and HypervisorOS

2.6 Policy Enforcement & Authority Gates (Client-Side)

2.6.1 ActionRequest: The Canonical Action Primitive

2.6.2 Policy Envelopes and Versioned Rule Sets

2.6.3 Versioned Policy Canonicalization and Hashing

2.6.4 Deterministic Inspection Assist Profile: Policy Enforcement over a Local Evidence Graph

2.6.5 The Capability Surface: Primitive Constraints vs. Authority Scopes

2.6.6 Capability scopes: permissions, not root

2.6.7 Interception and approvals

2.6.8 Audit and portability

2.6.9 Effect Boundary Object Family

2.6.10 Attribution Graphs & Contribution Receipts

2.6.11 Proposal-Mediated Upgrades & Upgrade Governance

3. State, Memory, and Semantic Data

3.1 Agentgres: Operation-Backed Domain Truth

3.2 The Agentgres Artifact Plane and Storage Boundaries

3.3 Projections & Subscriptions: The Agentgres Read Interface

3.4 Distributed Runtime Serving, Managed Instances, and Subscriptions

3.5 The Query Model & Consistency Levels

3.6 Agent Wiki / ioi-memory Context-Memory Plane

3.6.1 Locality-by-Default

3.6.2 The Memory API

3.6.3 Privacy-Preserving Context Injection

3.6.4 Portable Memory Vault and Projection Contract

3.7 Domain Ontologies and Data Recipes

3.8 Canonical Object Models and Connector Mappings

3.9 Distilled Ontology Datasets and Evaluation Datasets

4. Network, Routing, and Work Graphs

4.1 Private Workspace Backed by cTEE

4.1.1 Trigger conditions

4.1.2 The Hybrid Data Plane (Dual-Path I/O)

4.1.3 Session bootstrap: Routing and Route Selection

4.1.4 Typed Provider Handoff and Private-Workspace Capsules

4.1.5 Provider Execution, Admission, and Reintegration

4.2 Session Accounting and Value Flow

4.3 AIIP: The Inter-Autonomous-System Protocol

4.3.1 The AIIP URI Scheme

4.3.2 Resolution Result

4.3.3 Resolution Logic: Split-Horizon Discovery

4.3.4 The Worker Manifest

4.3.5 Typed AIIP Work and Outcome Contract

4.4 Infrastructure Integrations and Driver Modules

4.5 Artifact Resolution & On-Demand Provisioning

4.5.1 The Provisioning Lifecycle

4.5.2 Orchestration: On-Demand Hydration vs. Hot Pools

4.6 The Workload Adapter & Network Virtualization

4.6.1 The Mechanism: The Capability Execution Engine

4.6.2 Provider Swapping (The Local Routing Table)

4.6.3 Kinetic Drivers & Browser Subsystem

4.6.4 Customer Boundary Runtime (BYO-Auth)

4.6.5 The UCP Commerce Wrapper

4.7 Payment Brokers and Work-Credit Liquidity

4.7.1 Payment Broker Responsibilities

4.7.2 Security Invariant: Payment vs. Execution Authority

4.7.3 Payment Broker Business Models

4.8 Outcome Rooms, Multi-Worker DAGs, and Mixture of Workers