Knowledge Representations+MORK (MeTTa Optimized Reduction Kernel)+MORK Primer

MORK · Primer

What is MORK?

MORK is a high-performance engine for working with Hyperon Spaces — the large collections of structured symbolic expressions (atoms and hypergraphs) that Hyperon reasons over. Its job is to store, search, match, and rewrite those expressions fast enough to be practical, even when a Space grows very large. In short: MORK indexes structured expressions so that finding and transforming them can scale.

Why it matters

Cognitive algorithms in Hyperon constantly need to query huge symbolic structures, pattern-match against them, and write new facts back. Doing this naively becomes slow as data grows. MORK aims to rearchitect the parts of Hyperon that bottleneck on this, so that matching and rewriting stay fast across a wide range of Space sizes and shapes. The goal is speed at scale for real cognitive workloads and large data — not a new way to write everyday programs, but a specialized substrate that ordinary Hyperon code can run on top of.

Three ideas to hold onto

• Trie / PathMap indexing. Expressions are stored so that their structure — the prefix of an expression — acts like an address. Shared prefixes let MORK narrow a large set of expressions quickly instead of scanning everything. This prefix-oriented indexing (built on PathMap) is the main reason a Space can be searched efficiently.
• Zipper execution machinery. A zipper-based virtual machine moves through and rewrites structured Spaces in place. It is designed with parallel execution in mind, though actual speedups depend on the shape of the query and the runtime path it takes.
• MM2, a small rule language. Users drive MORK with MM2, a small MeTTa-like rule language used by MORK (its .mm2 files are, technically, a readable subset of .metta). Computation happens through rules of the form (exec SYSTEM PATTERNS TEMPLATES): match a conjunction of patterns, then write new templates into the Space. Sources and sinks connect these rules to the outside — reading and writing files and external stores, counting and hashing results, and calling a library of built-in functions.

What MORK is not (caveats)

• It is not a drop-in replacement for all Hyperon storage. Questions about persistence, mutability, and distributed/backing stores are active and are tracked in the MORK Deep Dive, not settled here.
• It is not free parallelism. MORK requires full unification, not just database-style joins, and narrowing that search space remains a genuinely hard, actively-developed problem.
• Some adjacent capabilities have fast-moving status — including set-algebra stream work, the IO/resource interface for external memory and accelerators, and linear-algebra/tensor support. The MORK Deep Dive tracks which parts are operational, under development, recently shipped, or proposed.

How to start reading (and trying it)

• MORK index — the card family and its subtopics.
• MORK Deep Dive — mechanisms, formal foundations, ecosystem, and current status.
• MORK on GitHub and its user-facing wiki (build with a Rust nightly toolchain; PathMap is a companion repo).
• Gentle entry points in the MORK wiki: Data-in-MORK (how expressions are represented) and Minimal MeTTa 2 (MM2) (the rule language). The wiki also carries worked tutorials with execution traces.
• For the underlying theory and literature, see MORK Research Family and Mork theory.

MORK's public README expands the acronym as “MeTTa Optimal Reduction Kernel”; this card family uses “MeTTa Optimized Reduction Kernel.” Both names refer to the same project. Detailed and fast-moving implementation status lives in the MORK Deep Dive and the publication maps above.