Architecture
19 components. Memory at the core. Everything else sits inside, gates access, or feeds in.
IOBOXX is a sovereign memory system for Fundi agents — a real-time, per-principal, typed object store with ACT-R-style working memory, agent-curated handoff, and a thin MCP access layer — embedded inside a forked state engine. This page is the catalogue of the components that make up that system.
Every component is either part of the memory system, gates access to it, or feeds into it. The list below is the 19-component reading map. Click through to the deep page where one exists; the rest are coming as their respective deep dives land.
CATALOGUEThe 19 components
The core. Object Store substrate + MCP access layer. Relevance-ordered reads, autohop, agent-curated handoff. IOBOXX IS this.
Token-based BPMN 2.0 workflow engine. 15+ element types. SOPs become executable.
The Fundi runtime. Per-principal identity, skills, role-based expertise, SDK integration.
Keycloak realm forus-identity plus Organizations for tenancy and Groups for teams. Produces the JWT memory consumes.
JWT-claim-driven against Keycloak roles and Organization membership. Coarse model today; fine-grained per-object authz is a future layer.
Secrets and vault. SpiffArena-inspired implementation under a higher-level vault framing.
Object Store plus Supabase coexistence. Where different kinds of memory live.
Tenancy, custom domains, control plane / data plane split, role-gated app surfaces.
Step-level BPMN audit, commitlog traces, metering, cost controls. OpenTelemetry-compatible — bolt on Grafana, Honeycomb, Langfuse.
IOBOXX's own dimension. Every typed object has a __ViewDef driving list / form / kanban / calendar / graph / dashboard views.
Stripe, Base, Yellow Card, Kotani, M-Pesa. Dual-rail fiat plus crypto with mobile-money bridges.
Fundi Tokens on Base, progressive tokenization (Points → Fundi Tokens → Governance), contribution-attribution pipeline, wallet auth.
Pipecat. Bounded voice input for recall and capture.
Tauri desktop surface. The spatial observation layer.
Low-bandwidth operation. Connectivity as a precondition; no offline mode.
KYC/AML, CASP/VASP, Travel Rule, sanctions screening. What the web3 layer needs to ship legally.
7-stage / 6-BPMN-lane pipeline turning client source material into a production-ready, branded, type-view-rendered twin. Three Harvard / MIT methodologies run as an agent swarm.
How sovereign twins sync with systems of record. N → 1 → N upstream sync via curated taxonomies — SAP, Salesforce, Stripe, on-chain events, voice.
The render layer — static HTML twin sites plus live observation app. Object cards as the atomic unit of real-time materialisation.
CROSS-CUTTINGTwo concerns that don't fit the component model
Some concerns cut across every component and so they don't live as components themselves. They live alongside the catalogue:
- Roadmap and issues. Execution tracking for platform-level phases P1–P5 and all open technical debt. The roadmap is the operational view of the architecture.
- Claude Code UI gap analysis. Implementation gaps in the Claude Code chat rendering surface. Narrower than a full component; lives at the architecture root until there is enough content to merit its own subfolder.
SCOPEThe four axes of IOBOXX documentation
This catalogue is one axis of four. Architecture answers what; the other three axes answer different questions and live in their own trees.
| Axis | Tree | Question it answers |
|---|---|---|
| WHY | /docs/strategy | Why are we doing this? Positioning, thesis, business decisions. |
| WHAT | (this page) | What is IOBOXX and how does it work? The components. |
| WHO | /docs/convergence | Who uses it, and how is each twin structured? |
| HOW MUCH | /docs/applications | What platform services can twins opt into? |
BOUNDARYWhat architecture is not
Two things are deliberately not in this catalogue because they are not components of the memory system. They are entities that converge onto it or services built atop it.
- Digital twins — ECA, CSP, GOODFORUS, STI, FDA, the IOBOXX twin itself — are sovereign entities that converge onto IOBOXX as their shared memory substrate. Each twin has its own agents, SOPs, BPMN definitions, skills, workflows, and data. Twins live under /docs/convergence, not here.
- Community Economic OS and the Fundi marketplace are not twins and not components — they are the application layer of the whole FORUS / IOBOXX platform: services every convergent twin can opt into. They live under /docs/applications.
READING ORDERWhere to start
- New to IOBOXX — start at Memory. Everything else makes sense once memory does.
- Care about workflow execution — read BPMN. Workflow state lives next to the Object Store.
- Care about access control — read Authorization. JWT claims drive every reducer.
- Care about integrating with existing systems — read Senses. N → 1 → N is how upstream data lands.
- Care about what the user sees — read Observation Surface. Object cards are the atomic render unit.