MOSES Deep Dive
MOSES (Meta-Optimizing Semantic Evolutionary Search) is Hyperon's evolutionary program-learning method — it discovers small, human-readable programs by combining estimation-of-distribution algorithms with evolutionary programming. Programs live directly in AtomSpace as graph structures, which keeps them transparent to reasoning (PLN), attention (ECAN), and pattern mining. This card provides technical depth beyond the concise MOSES index card.
Authors:
Contributors:
Papers: Looks (2006), Competent Program Evolution (PhD dissertation); Goertzel, Geisweiller et al. (2014), Engineering General Intelligence Vol 2, Ch. 7–9; Goertzel (2025), Hyperon Whitepaper §6.2
Status: MOSES is current across multiple implementations. metta-moses (iCog Labs) provides the most complete MeTTa reimplementation. hyperon-moses (trueagi-io) implements the boolean reduction core. The legacy C++ MOSES remains available. The GEO-EVO geodesic extension is proposed.
Related cards: PLN (reasoning-guided evolution), ECAN (attention-weighted fitness), MORK (content-addressed program storage), TransWeave (GEO-EVO integration)
Core Mechanisms and Scoring
Two Nested Search Loops
MOSES organizes search at two levels:
- Outer loop (structural): Explores program topologies — the shapes of candidate programs. Each topology defines a representation: a parameterized template where specific positions (knobs) can be varied without changing the overall structure.
- Inner loop (numeric): Within a fixed topology, tunes knob settings using optimization algorithms to maximize fitness. Multiple strategies are available: hill climbing, simulated annealing, probabilistic grammar evolution (PGE), structured grammatical evolution (SGE), structured graph genetic programming (SGGP), and univariate optimization.
Knob-Based Representation
The key abstraction enabling MOSES's efficiency. Each program template has knobs — discrete or continuous parameters attached to program nodes that define the local variation space. Turning a knob produces a syntactically valid variant of the template. The representation builder analyzes a program's abstract syntax tree (AST) and identifies which positions admit variation. This converts the combinatorial search over program space into a structured optimization over knob settings within each deme.
Deme Structure
Search is partitioned into demes — subpopulations exploring neighborhoods of a particular program template. A metapopulation manager controls deme lifecycle: spawning new demes from promising templates, allocating compute budget, merging results, and retiring exhausted demes.
Fitness Evaluation Pipeline
- Behavioral score (bscore): A vector \(\mathbf{b}(p) \in \mathbb{R}^n\) measuring program \(p\)'s performance on each of \(n\) data points
- Composite score (cscore): Aggregates the behavioral vector into a scalar \(c(p) = f(\mathbf{b}(p))\), incorporating precision-based scoring, penalty terms, and domain-specific objectives
- Fitness: Final ranking that balances composite score against program complexity — implementing an Occam's razor preference for simpler programs
Imbalanced Category Handling
For classification with skewed class distributions, MOSES provides three mechanisms: --balance=1 (automatic rebalancing), --score-weight (inverse-frequency weighting, mathematically equivalent to scoring by informedness = 0.5×(sensitivity + specificity)), and multi-objective deme strategies where different demes balance two objective functions differently. (mailing-list-backed: MOSES-for-classification-with-imbalanced-categories, 2014)
Elegant Normal Form (ENF)
Boolean programs are reduced toward a canonical form using algebraic simplification rules: distributive law, complement law, idempotent law, absorption-idempotent law, and annulment-identity law. ENF reduction eliminates redundant structure, making programs more readable and enabling MOSES to recognize when syntactically different programs are semantically equivalent.
Feature Selection
Before evolutionary search, MOSES can reduce the input dimensionality. Available methods: hill climbing, incremental selection, simple filtering, and stochastic mutual dependency (SMD) with similarity scorers.
Mathematical Foundations and MORK
GEO-EVO: Geodesic Evolutionary Optimization (Proposed)
The 2025 whitepaper (§6.2.1) proposes deep integration of MOSES with TransWeave, viewing evolution as an optimal transport problem through program space:
\[\text{Selection rule: maximize } \frac{\Delta\log(f \times g)}{\text{cost}}\]- Variables: \(f\) = forward reachability factor, \(g\) = backward compatibility factor
- Meaning: Expand search where the product of reachability and goal-relevance increases most per unit of computational effort
- Source: Goertzel (2025), Hyperon Whitepaper §6.2.1
This \(f \cdot g\) product structure is the same geodesic-control principle used across PRIMUS — in PLN inference, TransWeave transfer, and Schrödinger-bridge interpolation.
MORK Integration (Status: Open Research Line / Partial Scaffold)
The MORK-MOSES integration described here is aspirational architecture, not current implementation — a partial scaffold and open research line. The concrete current state at HEAD:
-
Implementation evidence: metta-moses'ssetup.sh references
mork_ffias a setup-level hook only. No committedmork_ffi/subtree exists in metta-moses (a tree listing at HEAD returns nomork_ffimatches). - Cross-check at HEAD: searching the MORK source for MOSES references returns no substantive integration code. The integration is one-sided and aspirational (it lives only in the metta-moses setup hook), not bidirectionally implemented.
- Paper status: The Goertzel 2025-07-21 Mattermost paper "MORK-MOSES Implementation Ideas" is the current authoritative proposal; substantive implementation work has not begun in either repo.
Aspirational architecture (treat as roadmap, not current behavior):
On MORK, MOSES is proposed to embed naturally: program templates, factor-graph priors, and deme statistics as content-addressed Atoms. Near-identical candidates would deduplicate via PathMap's structural sharing. MORK would index parameter neighborhoods for fast sampling and stream only the delta of changed subgraphs to the fitness evaluator. This is the Goertzel 2025-07-21 design proposal, not running code.
TransWeave Interplay (Whitepaper §6.2.1 — Proposed)
TransWeave casts evolution as stochastic dynamic programming and supplies typed transfer operators between logic, evolution, and neural value learners. PLN subgoals can bias evolutionary variation; evolutionary regularities feed back as new PLN rules; neural critics provide amortized value estimates. Commutator gaps between these operations are bounded, so steps can be reordered without breaking progress. Whitepaper proposal; not implemented in metta-moses or asmoses at HEAD.
Provenance: the partial-scaffold assessment comes from a 2026-05-07 source-code review; the extraction archive is at scripts/archive/non_clustered_haa_pilot/source5_NACE_AIDSL_MOSES_MeTTaNARS/.
Status and Resources
Last verified: 2026-06-05
Current Status
- Active Hyperon-era primary: iCog-Labs-Dev/metta-moseson9f69e17 PeTTa, with the full MOSES stack (HEAD , 2026-03-26). The canonical Hyperon-era line.
- Active C++ AtomSpace baseline: opencog/asmoses(HEADdde4849c4 , 2025-12-10). Recent commits are cogutils extraction; algorithm work was earlier in 2025. Linas Vepstas's linas/as-mosesis a byte-identical mirror at the same commit.
- Boolean-reduction prototype: trueagi-io/hyperon-moses— superseded by metta-moses for general MOSES, but retained as a boolean-reduction / ENF-pipeline prototype. It is 27 commits ahead of the older ngeiswei/hyperon-mosessibling.
- Archival: Legacy moses(C++, last commit 2023-09-19) — an archival predecessor; its README explicitly notes it is "kept to guaranty backward compatibility" and points to AS-MOSES.
- Stale forks (no new traditions): leungmanhin/asmoses(stale), singnet/asmoses(stale, merged-from-upstream only), and singnet/moses(some divergent legacy fixes). iCog-Labs-Dev/moses-optimization-algorithmsis a standalone experiment with an independent commit history, not a fork. See the "Implementation Eras and Design History" section above for the ahead/behind commit detail.
-
Open research / partial scaffold: MORK-native MOSES — metta-moses's
setup.shreferencesmork_ffias a setup-level hook only; there is no committedmork_ffisubtree. The Goertzel 2025-07-21 Mattermost paper "MORK-MOSES Implementation Ideas" is a proposal, not running code. - Proposed: the GEO-EVO geodesic extension with TransWeave integration, bidirectional \(f \cdot g\) search control, and a Schrödinger-bridge curriculum for progressive program complexity (Whitepaper §6.2.1).
Open Problems / Research Directions
- MORK-MOSES integration — closing the gap between the metta-moses setup hook and a working
mork_ffi+ PathMap-indexed program-template substrate. The current state is a paper-level proposal; no committed integration code in either direction. - GEO-EVO implementation — realizing bidirectional geodesic search in practice.
- Multi-deme scaling on MORK — exploiting structural sharing for large-scale parallel evolution (contingent on the MORK-MOSES gap closing first).
- Integration with PLN for reasoning-guided variation and fitness evaluation.
- Continuous and mixed-type data support in metta-moses (currently strongest on boolean/categorical domains).
- Benchmarking metta-moses against legacy C++ MOSES on standard supervised-learning tasks.
Primary Sources
- Looks, M. (2006). Competent Program Evolution. PhD dissertation, Washington University.
- Goertzel, B., Geisweiller, N., Pennachin, C. (2014). Engineering General Intelligence Vol 2, Ch. 7–9. Atlantis Press.
- Goertzel, B. (2025). Hyperon for AGI⇒ASI Whitepaper, §6.2: Evolutionary Program Search.
- Goertzel, B. (2025-07-21). MORK-MOSES Implementation Ideas, Mattermost paper. A cross-cluster integration proposal between MOSES and MORK.
Provenance: the implementation status and fork verdicts on this card come from a 2026-05-07 source-code review; the extraction archive is at scripts/archive/non_clustered_haa_pilot/source5_NACE_AIDSL_MOSES_MeTTaNARS/.
History and design lineage → — legacy and parallel implementations history.
Tags
Discussion