Mycelium

WHYPer-twin sovereignty is structural, not configurable

The conventional multi-tenant SaaS pattern is one database, many tenants, one tenant_id column on every row, and a constant background fear of the day a query forgets the predicate. The isolation is logical. The shared substrate is real. Auditors hate it. Regulators hate it. Customers under pressure hate it.

IOBOXX inverts the default. Each twin runs its own process — its own in-memory object store, its own deterministic commitlog, its own WebSocket subscriptions, its own backup pipeline. There is no row-level access check that has to be re-checked on every query because there is no shared row to leak. The access-control problem that defines multi-tenant SaaS dissolves: there is no tenant B in this instance, because tenant B is somewhere else, in a different process, behind a different endpoint, with a different audit log.

The benefits compound:

• Blast radius stops at the twin. Compromise of one twin's admin credentials cannot escalate to its neighbours, its parent, or its children. There is no cascade.
• Audit boundaries are clear. "Show me everything CSP did this quarter" is the contents of one commitlog, not a join over a shared event table.
• Right to erasure is a delete. Terminate the instance and the data is gone. No distributed copies to chase.
• Sovereignty is real. A claimed twin can lock down, revoke grants, change posture, choose its own jurisdiction — and the platform respects it, because there is nothing structural for IOBOXX to override.

TOPOLOGYN → 1 / 1 → N, never N → N

Every twin is the rendezvous point for its own data. Many sources feed it (senses, sync workers, scrapers, manual entry, on-chain watchers). Many consumers read from it (other twins, downstream integrations, dashboards). No consumer ever reaches into another consumer's data sources, and no twin point-to-points with another twin's upstreams.

The shape matters. If consumers were allowed to reach upstream past the twin, you would get N × N integration code — every consumer carrying scrapers, transforms, and credentials for every upstream source. When the upstream API changes, every consumer breaks. When a new consumer joins, it re-implements the same ingestion someone else already wrote.

The N → 1 / 1 → N constraint collapses that into one place. The twin owns its senses. When the upstream API changes, only the twin's senses update; consumers read what is already there. When a virtual twin is claimed by its underlying entity and the entity replaces the scrapers with its own authoritative feeds, every consumer gets better data without changing a line of integration code.

PRIMITIVESHow the mycelium actually works

Three primitives carry the entire mycelium story. Each is small. Each is inspectable. None of them is "trust the other twin."

1. Hub-and-spoke shared ledger

Cross-twin records that need to exist in both twins' views — invoices, payments, messages, partnership agreements — are written to a dedicated shared instance that holds only cross-twin state. Tenants publish outbound documents to it; recipients subscribe filtered by their own twin id. The shared instance enforces schema validation, rate limiting, and dispute resolution without either twin having to trust the other's endpoint. It mirrors how real commerce already works — invoices pass through a postal system, an EDI network, a banking rail; not direct peer-to-peer channels between counterparties.

2. Explicit grant model

A supplier twin shares its catalogue with a buyer twin under one grant. It shares its compliance certificates with a regulator twin under another. It shares its margin structure with no one. Grants are typed, time-bounded, and revocable. They live as federation_reader tuples on the target twin and are written by the owner (or by the curator on behalf of an unclaimed virtual twin). There is no "everyone in the parent twin gets read" default. There is no cascade through the taxonomy. Every grant is one tuple between one pair of twins.

3. OpenFGA-modelled authorization for cross-twin reads

The cross-twin read path checks an OpenFGA-shaped authorization graph. The model scales from one twin to thousands without the cascade hazards that destroy inheritance-based RBAC at scale. Roles do not flow from parent to child. A FORUS Digital admin is not automatically an IOBOXX admin. An IOBOXX admin is not automatically a CSP admin. Every relationship is an explicit edge; every edge is auditable; nothing is inherited by accident.

The mechanic is documented under authorization.

LINEAGETaxonomic inheritance is not operational inheritance

The twin hierarchy carries two things and keeps them strictly separate. Lineage is taxonomic — it says "this twin is a kind of thing within that twin's network of meaning." Sovereignty is operational — it says who can administer this twin, whose grants this twin honours, what policies this twin enforces. Lineage cascades. Power does not.

FORUS Digital                    (Economic OS — root)
└── IOBOXX                       (memory substrate)
    ├── ECA                      (live partner twin)
    ├── CSP                      (live partner twin)
    ├── GOODFORUS                (live partner twin)
    ├── STI                      (live partner twin)
    └── FDA                      (virtual taxonomy twin)
        ├── Manufacturer A       (virtual → claimable)
        └── Manufacturer B       (virtual → claimable)

IOBOXX inherits the lineage classification "thing within an Economic OS" from FORUS Digital. It does not inherit any operational rights, policies, or grants. ECA, CSP, GOODFORUS, and STI inherit the classification "thing that runs on the IOBOXX substrate." They do not inherit IOBOXX's admins, IOBOXX's security policies, or IOBOXX's mycelium grants. Each twin writes its own owner, its own admins, its own grants — explicitly, as tuples on its own instance.

The full ledger of what is and is not inherited lives in the wiki source. The short version: only the lineage classification is inherited, and only for breadcrumbs, search facets, and "what kind of twin is this" queries. Everything operational is per-twin.

CONTRASTWhat it gives the customer vs the platform

TIERSThree deployment tiers, one schema

A twin's position in the taxonomy is independent of where its data physically lives. Three tiers exist as deployment options, not as commercial packages. They are independent of the contribution-based access model (open-source self-host, managed sovereign node, contribution relationship).

• Shared. Many twins in one IOBOXX-operated cluster, row-level isolated. Lowest cost; suitable for general workloads. Default for virtual and low-activity twins.
• Dedicated. Per-twin instance on IOBOXX-operated infrastructure, process-level isolated, tenant chooses region. Default for regulated workloads — CASP/VASP, healthcare, financial services.
• Self-hosted. Customer runs the signed module release on their own hardware. Optional air-gapped operation. IOBOXX never touches the data. For extreme sovereignty.

What is identical across all three tiers: the schema, the reducers, the mycelium protocol, the MCP surface, the app binaries. Moving between tiers is a deployment change, not a code change. A twin migrating from shared to self-hosted does not rewrite a single integration.

NEXTWhere to go from here

• authorization — the access-control mechanic that makes the mycelium safe.
• senses — the N → 1 side: how data gets into a twin in the first place.
• memory — the substrate each sovereign twin runs.