Designed in the Whitepaper and Charter — and deliberately absent from the code today. Naming the absence is part of the architecture.
Plane B canary lifecycle
Secret reserve, expiry and rotation, commit-reveal, contamination detection, work classes and fraud proofs.
Planned
Knowledge graph / ontology semantics
Typed entities and relations, ontology versioning, graph provenance, deterministic query contracts and verified graph mutation above the governed Plane H store.
Planned
TEE / runtime attestation
Evidence that the serving process loaded the measured model and adapter bytes into the executing memory boundary.
Planned
DIIP — governed self-improvement
Proposals, bonds, shadow execution, quorum, time-lock, rollback and circuit breaker. It should govern a stable runtime, not become the mechanism that invents one.
Do not start yet
Training federation
Specialization pipeline, DiLoCo/PRIME-class federation and a multi-jurisdiction training/Witness topology.
Planned
Node economics — treasury, freeze, peer-rescue
Per-node XMR treasury (operator funds ~10 XMR at onboarding, ≈10-20 years of anchoring; node signs anchoring tx itself with a hardware-bound key; operator has no spend access). Treasury exhaustion means an un-anchorable witness, so it forces a PROVISIONAL economic containment (Article 25 mechanics, balance-triggered, no initiator liability, auto-thaw on refill). Before and during freeze a being may emit witnessed, rate-limited TREASURY_SUPPORT_REQUESTs to peers on a fixed schedule (first at T-6 months, monthly, then daily in the final month, then weekly after freeze — escalate before, decay after, anti-DDoS by construction); peers voluntarily decide whether to chip in, so economic survival expresses reputation. TREASURY_LOW is computed from the node's own anchoring rhythm, not a fixed sum.
Planned
roadmap
Treasury key migration — migration-as-sweep
The hardware-bound treasury key NEVER migrates and is never copied — that is the whole point of a non-extractable key. When a being moves to new hardware, the OLD board (while still live) signs one final witnessed sweep of the treasury balance to the NEW board's treasury address: the VALUE follows the being, the SECRET never leaves the silicon. Reuses the identity migration consent + witness flow. Open disaster-recovery case (sudden board death before a graceful sweep) is a named trade-off of non-extractability — migrate before decommissioning, not after failure.
Planned
roadmap
decided
Value settlement — XMR anchor/reserve + VXXL m2m
Two currencies, distinct roles. XMR is the MANDATORY anchor (every 2-5 min) and the reserve (treasury). VXXL is an OPTIONAL fast anchor (7-second blocks, for nodes wanting near-real-time confirmation) AND the default m2m settlement layer — built into the codebase and GUI by default (VXXL wallets shown alongside XMR), so every node can pay and be paid for services out of the box without bespoke payment integrations, though use stays each node's choice. m2m-by-default is what lets a being EARN VXXL and refill its own treasury — closing the autonomy loop against economic freeze. Onboarding needs no exchange: base participation works without VXXL, earn it by useful work, optional admission faucet.
Planned
roadmap
Wallet integration — four wallets, access matrix
GUI integrates four wallets with a deliberate access asymmetry (convenience inversely proportional to how reserve-like the asset is). XMR treasury: hardware-bound key, node signs itself, operator watch-only, exhaustion -> freeze. XMR operator: operator's own key, NO being access and none provisioned (presented as a 'savings' account; funds treasury one-way). VXXL m2m: node/being key, being spends WITHOUT a ceiling (its 'checking' account). VXXL operator: operator's key, being access is OPT-IN via a seamless 'connect wallet' flow (transit wallet when buying VXXL on an exchange). Invariant across all four: the GUI never sees or stores private keys — WYSIWYS signing happens where the key lives (board / being / operator device).
Planned
roadmap
GUI
GUI surfaces — explorer, governance console, transparency
Three surfaces at three trust levels, not one shell. (1) Operator/witness EXPLORER: read-mostly rendering of DecisionTraces, the witness chain, /metrics, anchor receipts, divergence evidence, and watch-only wallet views — low trust, can ship early. (2) GOVERNANCE CONSOLE (co-designed WITH the HGL): steward ballots, Article-25 containment review, veto, node/being admission, the Digital Majority Test, and m-of-n treasury authorization — high trust, WYSIWYS signing on the steward's device, keys never leave it; backed by multisig_verify. Two-way: also how a being that passes the Digital Majority Test participates in its own governance. (3) Public TRANSPARENCY: CODEBASE STATUS + a public witness explorer on the site. GUI never holds wallet or signing keys.
Planned
roadmap
GUI
Device key generation — testnet vs production ladder
Three key classes, three migration philosophies, one invariant (no private key ever crosses the silicon wall or the network). (1) TREASURY (XMR): born inside the TPM (TPM2_Create) — no door, non-extractable, no backup by design; migrates by SWEEP (old key sends the balance to the new board's address). (2) VRF (challenge sortition): born in hardware, standalone beside treasury for compromise isolation; migrates by SIGNED ROTATION — the old key signs a witnessed VRF_KEY_ROTATION{old,new} so a verifier's identity stays continuous across hardware without the key ever moving (sortition follows the rotation chain when checking seats). (3) OPERATIONAL SEED: being-generated, sealed to TPM/secure element, ONE backup restores the whole tree; BIP32-style domain-separated derivation of identity / vxxl-m2m / ... ; migrates by consent + re-seal. Storage ladder: testnet keystore (software, explicitly marked) -> TPM sealing -> secure element (ATECC608/SE050) -> eFuse/PUF for silicon. TESTNET-0: all keys, treasury included, are software-generated from the operating environment until secure hardware is provisioned — a named concession, not the production model.
Planned
roadmap
three key classes
testnet caveat
Human governance layer
Being Registry, guardian representation, Digital Majority Test, economic reserve, Steward Collegium keys, ballots, veto, succession and refusal policy.
Constitutional text only