HAAEEP and Collaboration
HAAEEP and Collaboration
Companion summary — target architecture. This page condenses
../docs/08-ecosystem/haaeep-and-collaboration.md, the canonical description of the High Assurance Agent Edge Environment Platform (HAAEEP): a target architecture that Open-IOV exists to enable, and the collaboration models around it. HAAEEP is a proposal and a roadmap, not a shipped product. When this page and the docs tree disagree, the docs tree wins. Front door:../docs/README.md.
Status: 2026-10-12, tree master @ 2f066727. Tags: [proposal] architecture and roadmap; [target] milestone to reach; [goal] end state; [design] integration point designed, not built.
1. What HAAEEP is
An AI agent harness (Claude Code, OpenCode, or any future equivalent) is an untrusted, capability-constrained workload: it runs generated code, holds credentials, and talks to a model. In a cloud deployment its requests leave the device; in a secure edge deployment — a workstation, a kiosk, a vehicle, a medical or industrial system — they must not.
HAAEEP is the platform shape for that edge deployment:
- inference runs locally, in its own VM, with the GPU;
- agents run in their own VMs, without the GPU and without the weights;
- other functions (desktop, networking, storage) run in other VMs, each isolated;
- the whole stack is attestable, so remote parties can verify it;
- and nothing in the design requires the model server, the agent, or the GPU driver to be modified.
Open-IOV is HAAEEP's GPU component. The broader motivation is in ../docs/01-orientation/02-the-ai-edge-and-ecosystem.md.
2. Architecture
┌──────────────────────────────────────────────────────────────────────────┐ │ EDGE DEVICE — one GPU, local inference only │ │ │ │ ┌─────────────────┐ ┌──────────────────┐ ┌───────────────────┐ │ │ │ Agent VM │ │ Inference VM │ │ Infrastructure │ │ │ │ capability- │────▶│ vLLM / SGLang │ │ desktop, net, │ │ │ │ constrained │ API │ owns GPU via │ │ storage VMs │ │ │ │ no GPU │ │ Open-IOV mdev or │ │ optional GPU accel│ │ │ │ │ │ xen-pci + relay │ │ via Open-IOV │ │ │ └─────────────────┘ └────────┬─────────┘ └───────────────────┘ │ │ │ │ │ ┌────────────────────────────────┴───────────────────────────────────┐ │ │ │ Hypervisor: KVM / Xen + Argo/OpenXT / Qubes OS Air │ │ │ │ • Flask-XSM / HMX mandatory access control between VMs │ │ │ │ • TrenchBoot measured boot: firmware → hypervisor → OS │ │ │ │ • Open-IOV: per-VM virtual GPUs, IOMMU-enforced isolation │ │ │ └────────────────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────────────┘
3. Roles and trust
| Component | Trust | Why |
|---|---|---|
| Agent VM | untrusted | runs generated code; may be compromised |
| Inference VM | high (holds weights) | isolated from agents by MAC and by device virtualization |
| GPU-owning VM (optional) | high | owns the physical device; can serve others through Open-IOV |
| Infrastructure VMs | medium | GPU acceleration optional; no access to weights |
| Hypervisor | TCB | enforced by the platform (Argo/OpenXT/Qubes) |
| Open-IOV device | TCB-adjacent | must fail closed; audited (see the security doc) |
4. Data flow
- An agent VM issues an API call to the inference VM over an internal, MAC-controlled channel.
- The inference VM's vLLM/SGLang (unchanged) serves the request with the GPU, using its KV-cache plugins (also unchanged).
- No request ever leaves the device: the platform's network policy forbids external inference endpoints by construction.
Optional topology — GPU relay domain. Where the platform prefers it (Xen with xen-pci), one domain owns the physical GPU and relays acceleration to other domains through Open-IOV: the process running the model is isolated from the domain that owns the silicon, and agents are isolated from both.
5. Why Open-IOV fits
| Alternative | Why it is not enough |
|---|---|
| Discrete passthrough | gives the GPU to exactly one VM; HAAEEP needs the GPU in the inference VM and optional acceleration elsewhere |
| Process-level sharing (host CUDA with containers) | no VM-level isolation, which is the whole point of the platform |
| Proprietary vGPU | cannot build a sovereign, auditable, redistributable edge platform on a licensed host stack you cannot inspect or modify |
| Software GPU emulation | cannot run models usefully |
Open-IOV is the component in this design that must be open, permissively licensed and version-durable — so it is the component we are building. Its isolation model is described in GMMU-Multi-Tenant-Protection.md.
6. Roadmap (proposal)
| Milestone | Depends on |
|---|---|
| CUDA execution in a guest (rung 3) | rung 2 (runtime start) is green; CE-class work is forwarded with release and fault relay in place (default off); for GR the guest launch reaches the front-end but no grid has dispatched yet — the frontier is tracked in Execution-Frontier.md
|
| Two-VM coexistence (inference + agent) with isolation | Open-IOV multi-tenancy + platform MAC |
| Xen/OpenXT or Qubes Air variant | Open-IOV transport backends |
| Attested boot-to-inference chain | TrenchBoot integration |
| Published reference platform (scripts, docs) | all of the above |
Each milestone is documented as it lands, with the same evidence discipline as the rest of the project. Nothing in this table is claimed today: it is the proposal.
7. Collaboration models
Open source projects. Adopt the code under BSD-3-Clause (kernel modules are GPL-2.0 — see ../docs/09-reference/legal-and-licensing.md). We treat interface requirements as design inputs (transports, IRQ models, memory interfaces), provide the transport abstraction rather than asking for forks, and test against partner platforms in the matrix.
Commercial partners. Welcome, with no license fee: ship Open-IOV in products and differentiate above it; sponsor support for specific hardware/driver versions; co-develop under the same permissive terms.
Hardware vendors. Nothing is required. The goal is that new hardware works through configuration and measurement; if you want to accelerate support, share hardware and traces, and we publish what we learn.
Security researchers. The emulation's attack surface is small and documented. Break it. Findings and fixes are published, with credit.
8. Cross-project notes
| Project | Relationship |
|---|---|
| Qubes OS Air | compartmentalization on modern hardware; Open-IOV makes GPU acceleration usable per compartment (especially AI workloads) |
| TrenchBoot | measured/attested boot; combined, the platform can attest the inference path |
| Argo / OpenXT | hypervisor-mediated exchange (HMX) and Flask-XSM MAC; Open-IOV respects and complements that policy |
| KVM/VFIO gaming | established the fast-passthrough pattern; Open-IOV serves users who need multiple VMs or cannot dedicate the GPU |
| vLLM / SGLang | remain the inference answer; Open-IOV isolates them without changing them; KV-cache plugins keep working |
9. How to help
- Platform builders: bring your hypervisor; tell us the transport you need.
- Security engineers: review the isolation model and the debug surface.
- AI-infrastructure engineers: define the reference HAAEEP deployment with us (model server, KV cache, agent harness).
- Everyone: run the evaluation ladder on your hardware and send the evidence.
Contact and participation channels are in ../docs/README.md §6 "How to get involved". We would rather have a hundred partners than a hundred forks.
10. Related documentation
../docs/08-ecosystem/haaeep-and-collaboration.md— canonical HAAEEP architecture, roadmap and collaboration models.../docs/01-orientation/02-the-ai-edge-and-ecosystem.md— the AI-edge motivation and ecosystem stance.../docs/05-operations/01-performance-correctness-security.md— the evaluation ladder behind every milestone.Project-Status.mdandSystem-Overview.md— current status and component map.Execution-Frontier.mdandPhysical-GPU-Backend.md— the GR frontier and how work reaches real hardware.Hardware-Software-Matrix.md— what runs where, and how support is added.