jj-dai.org · reference codebase · generated from architecture_status.json

Architecture Status / what exists, what does not yet

Every component of the JJ DAI trust, governance and agent kernel, classified into exactly one of five honest statuses. This page follows the code, not the ambition.

build v0.5.5 acceptance 86/86 green stdlib-only core · Python ≥ 3.10 status experimental organism — NOT a security-alpha
Implemented — live, tested Prototype — works end-to-end, known gaps Interface only — the seam exists Planned — designed, no code Constitutional text only
#00KIND: FIVE-LAYER COMPOSITIONprev: GENESIS

The neurosymbolic stack

Mutable knowledge lives outside frozen weights; everything that touches a decision is verified; the Witness observes and never acts (INV-9).

5LLM / agent — frozen substrate + adaptersPrototype
4Knowledge — governed Plane H store (graph semantics planned)Prototype
3Deterministic tools — Karma reference sandboxImplemented
2Verification — diversity panels, verdicts, cross-verifyImplemented
1Sākṣī — Witness: local implemented, distributed fabric prototypeImplemented
#01KIND: PRIMITIVESprev: #00

Cryptographic primitives — jjdai/

jjdai/canonical.py
Canonical serialization
RFC 8785 JCS: one deterministic byte-stream per object across identity, signatures, manifests and witness records.
Implemented
jjdai/crypto.py
Ed25519, ids, commitments, keystore
Strict small-order rejection, cofactored verification, canonical node/Being ids, hiding commitments, atomic 0600 encrypted keystore.
Implemented reference crypto
jjdai/crypto.py::vrf_prove · jjdai/crypto.py::multisig_verify
VRF and threshold governance
ECVRF-EDWARDS25519-SHA512-TAI (RFC 9381) pinned to all three official B.3 vectors, with validate_key fail-closed checks; naive m-of-n multisig verification (aggregate FROST signing deferred).
Implemented RFC 9381 vectors FROST deferred
jjdai/merkle.py
Merkle trees
Legacy padding tree plus RFC 6962 inclusion and consistency proofs, property-tested across tree shapes and forgery cases.
Implemented
jjdai/witness.py
Witness chain
Hash-chained, Ed25519-signed, persist-before-expose append under a chain-internal lock, offline replay and legacy-log verification.
Implemented
jjdai/schema.py · jjdai/durable.py
Typed boundary and durability
Fail-closed typed envelopes; fsynced journals, torn-tail repair and reload-time re-verification.
Implemented
core/anchoring.py
External anchoring
Durable receipt log with local, peer-quorum and OTS-calendar backends. OTS is proof custody; standard tooling verifies the stored calendar proof.
Prototype
core/anchoring_xmr.py
Monero root-as-spend-key anchor
The witness root deterministically becomes a Monero address; a dust payment timestamps the binding without storing the root in tx_extra.
Prototype v0.5.2
#02KIND: ORGAN KERNELprev: #01

The organ kernel — kernel/

kernel/smriti.py
Smriti — continuity and memory
Core/archival memory, verified recall, signed export/import, read-only thinking view and journal reconstruction.
Implemented
kernel/viveka.py
Viveka — discernment and deliberation
Deterministic graphs, conditional routing, checkpoints, visible rollback, bounded loops and containment-aware executive steps.
Implemented
kernel/karma.py
Karma — governed action
Witnessed intent/outcome, path confinement, rlimits, streaming flood-kill, deterministic child environment. Reference sandbox, not hardened isolation.
Implemented reference sandbox
#03KIND: BEING COMPOSITIONprev: #02

The organism — runtime/

runtime/being.py
BeingRuntime
One long-lived composition owning one identity, ONE witness chain, Smriti, Plane H, Viveka, Router, Karma and Containment. Closes the v0.5.2 audit composition gap.
Prototype v0.5.3
runtime/state_machine.py · runtime/decision_trace.py
Decision lifecycle
RECEIVED → GROUNDED → PLANNED → GENERATED → VERIFIED → AUTHORIZED → ACTED → RECORDED with REFUSED / FAILED / FATE_UNKNOWN / CONTAINED branches; every transition witnessed then journaled.
Prototype v0.5.3
runtime/recovery.py
Semantic recovery
After restart every trace is rebuilt from the durable journal; an orphaned Karma intent closes as FATE_UNKNOWN — the system that does not know says so.
Prototype v0.5.3
node/daemon.py::/v1/tasks
POST /v1/tasks
Returns a full DecisionTrace, not a raw completion: states, citations, plan hash, generator and panel provenance, containment decision, action receipt, witness span.
Prototype v0.5.3
#04KIND: TRUST & GOVERNANCE COREprev: #03

Trust core — core/

core/identity.py
Node and Being identity
Persistent keystores, genesis binding, boot verification and migration consent. The daemon fails closed on signer/witness mismatch.
Implemented
core/registry.py · core/verdict.py
Reputation §9.9 and sealed verdicts
Decay, Bayesian shrinkage, slashing and signed context-bound verdict envelopes with replay refusal.
Implemented
core/plane_h.py
Governed Plane H
Signed proposals, namespace ACL, transactional witness-bound append, supersede/redact, root-preserving redaction. Retrieval remains a token-overlap baseline; not yet a semantic knowledge graph.
Governance implemented retrieval baseline
core/replication.py · core/segments.py
Witness replication and recovery
Signed RFC 6962 roots, quorum receipts, consistency proofs, segment coverage, divergence evidence and restore-and-resume against an anchored root.
Prototype fabric
core/entanglement.py
Cross-chain entanglement
Recipient-root cross-links, PEER_ROOT checkpoints and issuance inclusion proofs. Attribution is cryptographic only under the documented honest/anchored issuer assumption.
Prototype
core/peers.py
IFF — friend or foe
Durable peer registry, steward admission, key pinning and replay-protected signed requests, layered under TLS/mTLS transport.
Prototype
core/manifests.py · core/diversity.py
Provenance and diversity
Signed immutable manifests and correlation-constrained panel selection. Unknown provenance counts as correlated; short panels fail honest.
Implemented algorithm
core/attestation.py
Weight attestation
Streamed artifact measurement, signed DeploymentManifest, durable store and daemon boot gate. Proves operator measurement, not engine memory.
Prototype
core/router.py
Unified router
Registry-aware champion routing, signed ROUTE records and diversity-constrained verifier panels — now driven by the BeingRuntime lifecycle as well as usable as a library.
Prototype composed in v0.5.3
core/challenge.py
Adversarial challenge round
VRF sortition (transcript-bound, unbiasable seats), blind commit-reveal verdicts, deadline/abstention semantics and offline-verifiable fraud proofs that slash via the registry — now driven over mTLS via /challenge/* as well as in-process.
Prototype networked v0.5.5
core/crossverify.py
Peer cross-verification loop
Remote teacher-forcing score, offline peer-Witness re-audit and registry feedback. The challenge round now runs across the network (core/challenge.py + /challenge/* endpoints).
Prototype
core/containment.py
Containment — Article 25
Seven executive scopes, provisional containment, reversal, initiator liability, slashing, rehabilitation and Steward-review gate. Steward keys and ballots remain absent.
Reference prototype
#05KIND: NODE & CONFORMANCEprev: #04

Node layer — node/ · necs/

node/daemon.py
Tier-1 trust node daemon
Inference/scoring, Witness export, replication, entanglement, attestation, anchoring, peers, containment, the Being task lifecycle, per-identity rate limiting, role-based authorization, cert revocation, /healthz and /metrics, and the networked challenge round — all over TLS/mTLS.
Prototype
node/engine_sglang.py · node/engine_dwarfstar.py
Engine adapters
Generation plus teacher-forcing score with mock and live acceptance seams. Real GPU acceptance and operational profiles remain pending (operator-run gate).
Prototype adapters
necs/
NECS v0.1 + harness
Conformance specification and harness under Apache-2.0, preserving vendor-neutral adoption.
Implemented
tests/ · .github/workflows/ci.yml
Acceptance and CI
Acceptance functions across unit, integration, conformance, adversarial and legacy groups; CI matrix targets Python 3.10-3.12; docs drift is CI-checked.
86/86 green
m1m5/
Retired M1-M5 lineage
Frozen legacy code retained for auditability and migration coverage.
Frozen
#06KIND: NOT-IN-CODEBASEprev: #05

Not yet in the codebase

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
#07 KIND: COMPOSITION STATUSprev: #06

The honest sentence

what changed · what must not be overclaimed

v0.4.1 closed the identity gap. v0.5-dev5 closed the cryptographic boundary. v0.5-dev6 made replication sound. v0.5.1 closed P1 mechanisms. v0.5.2 added the Monero anchor. v0.5.3 closed the COMPOSITION GAP: one BeingRuntime drives every organ through one witnessed lifecycle over one identity, and POST /v1/tasks returns the full DecisionTrace — including the honest endings REFUSED, FAILED, FATE_UNKNOWN and CONTAINED. v0.5.4 made verification ADVERSARIAL: RFC 9381 ECVRF (vector-pinned) drives transcript-bound panel sortition nobody can grind; verdicts are sealed before any are shown; silence and fraud become witnessed, offline-verifiable evidence; and the daemon holds its first operational boundary — per-identity rate limiting whose systematic abuse is itself witnessed. v0.5.5 is the SECURITY-ALPHA: role-based authorization (default-deny, longest-prefix), certificate revocation that beats identity, /healthz + /metrics, the challenge round carried over mTLS, a production PKI with an offline root, optional TPM-sealed keystores, a hardened systemd unit and an operator runbook — the kit to stand up testnet-0 on Ubuntu.

Said plainly: authorization is transport-role based (peer/admin/anonymous from the mTLS CN), not yet capability- or steward-ballot based; certificate revocation is serial-list based; Karma is still a reference sandbox, not hardened isolation; the knowledge store is retrieval-baseline, not a knowledge graph; and DIIP remains deliberately absent. This is an alpha to operate among known operators, not to expose to untrusted load. Planned next beyond the security-alpha: the node economic model (per-node XMR treasury, balance-triggered economic freeze as provisional Article-25 containment, witnessed rate-limited peer-rescue, treasury key migration as a final witnessed sweep that moves value without ever copying the secret), VXXL as the default-but-optional m2m settlement layer beside XMR's mandatory anchor, four GUI wallets with a strict access matrix, and three GUI surfaces co-designed with the Human Governance Layer — with the honest note that on testnet-0 all keys, treasury included, are software-generated until secure hardware is provisioned.