Status and Resources

help edit space_dashboard

Current Status

  • Operational: Triemap storage, ZAM execution, bidirectional pattern matching, MM2 language, PeTTa/MORK integration, mork_ffi for Prolog bridging
  • Under development: MORK-native PLN (backward chaining + factor graphs — paper/proposal/benchmark-only, no code-real FactorGraph PLN at this snapshot per AtomSpace cluster pilot Source 3), WILLIAM trie instrumentation, ByteFlow GPU acceleration, ShardZipper distributed state, streaming fusion optimization
  • Proposed: Multi-machine distributed processing, QuantiMORK (neural tensor encoding), WASM edge deployment, native MeTTa-to-machine-code compiler

Implementation Findings (transcript-backed, MORKification Weekly Aug 2025–Apr 2026)

  • MM2 scale: ~350 grounded functions as of Jan 2026. One MM2 step triggers billions of parallel rewrites due to massive parallelization.
  • Sources/sinks architecture: Three-layer resource abstraction — resources, sources (readers), sinks (writers). This is the integration surface for ECAN weights, hypervectors, and external systems. Note: CountSink in the kernel (MORK/kernel/src/sinks.rs:512-591) is an MM2 query/reduction primitive (per-execution accumulator), not a persistent revision log — do not target it as a Decko card-history counter.
  • Compression benchmarks: PathMap uses seven levels of nested shared patterns to represent all 64-bit integers in 8 nodes. JSON import: 20× reduction (780 GB JSON → 40 GB ACT).
  • RAM scaling benchmark: PeTTa/MORK has been demonstrated up to 400M atoms in RAM (mork_ffi/example_space.metta:13-17: successful 100M/200M/300M/400M; 500M ran out of memory at the same site). Earlier "500M+ atoms in RAM" wiki text treated the OOM ceiling as demonstrated capacity — corrected.
  • Streaming fusion investigation: Six implementations tested — all ~10× slower than binary operations due to branch traversal overhead. Active investigation with database-inspired query optimization.
  • Concurrency advantage: MORK surpasses ATRIUM (20,000 threads) on its own benchmarks due to sequential thread coordination rather than threads fighting over shared memory.
  • Applications: 4×4 Sudoku (~2 ms), CTL model checking, decision tree learning, Blocks World / PDDL planning.

Known Limitations (discussion-backed, MORK Mattermost)

  • Concurrency ceiling: MORK crashes at ~200 concurrent users (Rejuve.Bio load test, Mar 2026) rather than degrading gracefully.
  • No automatic persistence: Data lost on restart. Manual save/restore via paths_export() / paths_import().
  • Negative querying unsound: Removed from MM2. Use != or nested if/not/find instead.
  • Memory multiplier: ~64 bytes/atom. String-heavy datasets need interning (7 GB → 1.9 GB vs 31 GB default).
  • WASM deprecated: ~15× overhead. Pure Rust grounded functions now default.
  • Server-branch versioning: The mork-server deployment line is maintained on a separate server branch. As of 2026-04-29, three references are not reconciled: das-toolbox CLI defaults to image tags trueagi/das:mork-server-1.0.5 + mork-loader-1.0.5; das/src/docker/mork/Dockerfile.server pins MORK commit 578a759 (2025-07-21); local origin/server HEAD is 5b04a1d (2026-04-18) — 49 commits ahead of the DAS pin with deadlock and UTF-8 fixes. Production deployment must reconcile all three references. Notable post-pin fixes in the gap: server shutdown deadlock (5b04a1d), user-status-map cleanup (08116b0), lock-held-too-long deadlock (205dd91), UTF-8 validation for symbol pathway (f284ff6), edge-case + malformed-symbol test coverage (7872975).
  • Link/S-expression delete unsupported in DAS-MorkDB backend: das/src/atomdb/morkdb/MorkDB.cc:268-270 hard-fails. Node delete works (inherited from RedisMongoDB); link delete does not. flush_pattern + re_index_patterns provide batch-rebuild workarounds, NOT live mutable-store CRUD. See DAS Full.

Open Problems / Research Directions

  • Multi-machine distribution — scaling across clusters while preserving PathMap locality
  • QuantiMORK — wavelet/multiresolution DAG encoding for neural structures
  • GPU/TPU acceleration via ByteFlow for dense numerical kernels
  • Community and third-party package ecosystem
  • Formal verification of ZAM correctness properties
  • Decko-compatible mutable-backend semantics — link delete, transactional history, RichText/file/permission mappings; MORK alone does not provide them, an adapter layer is required (AtomSpace cluster pilot Source 3 R3.G2)

Primary Sources

  • Goertzel, B. (2025). Hyperon for AGI⇒ASI Whitepaper, §2.3, §3.6.
  • Goertzel, B. (2025). Articulating Conditions Where ZAM/MORK Yield Benefit. RawData.
  • Goertzel, B. (2025). From Path Algebra in MORK to Tensor Logic on GPUs. RawData.
  • Goertzel, B. (2025). Slot-Centric Indexing vs. Permutation Explosion. RawData.
  • Peyton Jones, S. et al. Triemaps that Match.
  • See also: MORK Theory Publication Map.
  • AtomSpace Backend Integration Cluster Pilot (2026-04-29) — cluster archive at scripts/archive/atomspace_pilot/; Source 3 reconciliation is the canonical record for the corrections on this card.