Hyperon AI Algorithms+MOSES (Meta-Optimizing Semantic Evolutionary Search)+MOSES Full

Approved by Ursula Addison on 2026-05-05

Home / Hyperon AI Algorithms / MOSES / MOSES Full

Responsible: Nil Geisweiller, Yeabsira Derese (iCog Labs), Moshe Looks (original design)

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.

This card provides technical depth beyond the concise MOSES index card. MOSES (Meta-Optimizing Semantic Evolutionary Search) is Hyperon's evolutionary program learning methodology — a system that discovers small, human-readable programs by combining estimation-of-distribution algorithms with evolutionary programming. Programs live directly in AtomSpace as graph structures, making them transparent to reasoning (PLN), attention (ECAN), and pattern mining.

Related cards: PLN Full (reasoning-guided evolution), ECAN Full (attention-weighted fitness), MORK Full (content-addressed program storage), TransWeave Full (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 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)

Per Non-clustered HAA cluster pilot Source 5 close 2026-05-07: [MORK-MOSES-PARTIAL-SCAFFOLD-OPEN-RESEARCH-LINE]. The MORK-MOSES integration described here is aspirational architecture, not current implementation. Concrete current state at HEAD:

Implementation evidence: metta-moses setup.sh references mork_ffi as a setup-level hook only. No committed mork_ffi/ subtree exists in metta-moses; git ls-tree HEAD -- 'mork_ffi*' returns no matches.
Cross-cluster cross-grep at HEAD: grep -ri 'MOSES' against MORK (closed AtomSpace cluster pilot 2026-04-29) returns no substantive integration code. The integration is one-sided-aspirational (in the metta-moses setup hook), not bidirectional-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 HEAD.

Cluster-pilot extraction archive: scripts/archive/non_clustered_haa_pilot/source5_NACE_AIDSL_MOSES_MeTTaNARS/ (close 2026-05-07; V5-10 carry-forward locks the partial-scaffold reframing).

Implementation Eras and Design History

Three Eras of Implementation

1. Legacy C++ (OpenCog era). The original MOSES, written in C++ with Boost dependencies. Programs output in the combo language. Two variants:

moses/ — Standalone version (v3.7.0). Command-line tool with optional MPI for cluster parallelism.
asmoses/ — AtomSpace-integrated version. Outputs Atomese or Python. Used in commercial applications (medical/financial data analysis).

2. MeTTa Boolean Reduction (trueagi-io). hyperon-mosesfocuses on the boolean reduction pipeline — the ENF simplification engine. Design documents explore cognitive synergy and reasoning-as-evolution concepts.

3. Full MeTTa Reimplementation (iCog Labs). metta-mosesis the most complete MeTTa version: demes, metapopulation, knob-based representation, six optimization strategies, complete scoring pipeline, feature selection, and boolean reduction. Runs on PeTTa. Per Non-clustered HAA cluster pilot Source 5 close 2026-05-07: [ACTIVE-METTA-PRIMARY] — this is the canonical Hyperon-era MOSES line at HEAD 9f69e17 (2026-03-26). File-line evidence: deme/create-deme.metta:3-18 (deme construction), deme/expand-deme.metta:47 / :69 / :107-140 (expandDeme + runMoses), deme/merge-demes.metta:222-274 (metapopulation merge), scoring/fitness.metta:123 / :146 / :156-159 (row + aggregate + penalized fitness), scoring/precision-bscore.metta:316-340 (top-level pre-scorer for hill-climbing feature selection).

Co-Canonical Mirror

Per HAA Source 5 close: linas/as-mosesatdde4849c4 HEAD is byte-identical to opencog/asmosesatgitoutput0. the same SHA — verified bidirectional rev-list --left-right --count 0 Verdict [VEPSTAS-MIRROR-SAME-SHA]: Linas Vepstas's mirror is not a separate implementation tradition.

Stale Forks (HAA Source 5 audit 2026-05-07)

Three stale forks exist; none represent independent traditions. P12 verbatim numerical outputs (orchestrator-verified):

leungmanhin/asmoses—0against 107 opencog/asmoses; verdict [STRICT-FORK-STALE].
singnet/asmoses—7; 165 the 7 ahead-commits are merge-sync metadata (same pattern as HAA S3 singnet/miner and S4 singnet/relex); verdict [STRICT-FORK-STALE-MERGED-UPSTREAM].
singnet/moses—19against 23 opencog/moses; verdict [STRICT-FORK-DIVERGED-LEGACY-FIXES] pending spot-check on whether the 19-ahead commits are pure merge-sync or substantive legacy fixes.

The iCog-Labs-Dev/moses-optimization-algorithmsrepo is [STANDALONE-EXPERIMENT-NOT-FORK] — its commit history (Initial commit / hill climbing implementation / added simulated annealing / Merge PR #1 from Nahom32-implementation) is independent of asmoses/moses, not derived.

Historical Design Decisions (mailing-list-backed)

AtomSpace-MOSES: Demes as AtomSpaces. A 2018 planning discussion revealed the key architectural motivation: each deme would become its own AtomSpace, enabling PLN and pattern mining to analyze program populations. Nil Geisweiller proposed that candidate growth should be expressible as "proof of its fitness estimation." (Atomspace-MOSES-planning, 2018)

Ensemble Nature and the True Bottleneck. Linas Vepstas (2018) cautioned against focusing on individual top-N programs — MOSES's ensemble of 1000 simple programs is more accurate than 10 highly-evolved experts. He identified fitness evaluation — not Reduct — as the true performance bottleneck, and warned that the probabilistic measure over program populations is fractal, not smooth. (Atomspace-MOSES-planning, hypothetical MOSES refactoring, 2014–2018)

Legacy MOSES Isolation. Legacy C++ MOSES was "rather isolated from the rest of OpenCog" — it could not use Atomese operators or the pattern matcher. This isolation was the core motivation for the MeTTa reimplementations, where programs live natively in AtomSpace from the start. (Questions-on-MOSES, 2017)

Reduct Reorganization by Algebraic Property. Nil Geisweiller organized Reduct rules by algebraic property (commutation, involution, association) rather than by operator — the conceptual ancestor of the ENF pipeline. (Atomspace-MOSES-planning, hypothetical MOSES refactoring, 2014–2018)

Conciseness as Competitive Advantage. MOSES produces classification rules that are "both accurate and concise" — whereas neural nets and SVMs produce "bloated" models. This is a direct consequence of the Occam's razor complexity penalty. (Program-learning-vs-Machine-Learning, 2017)

System Interfaces

PLN: PLN evaluates logical consistency of evolved programs; MOSES evolves inference control strategies for PLN.
ECAN: ECAN-weighted regions of AtomSpace define the fitness landscape for evolutionary search.
Pattern Mining: Evolutionary regularities feed back as new patterns; mined patterns serve as building blocks for program templates.
MORK: Per HAA Source 5: [MORK-MOSES-PARTIAL-SCAFFOLD-OPEN-RESEARCH-LINE] — metta-moses setup.sh references mork_ffi as a setup-level hook only; no committed mork_ffi subtree exists. The Goertzel 2025-07-21 "MORK-MOSES Implementation Ideas" paper proposes deep integration but remains a proposal, not current behavior. See Mathematical Foundations and MORK.

Implementation Anchors

metta-moses (primary, MeTTa) — Full reimplementation on PeTTa. [ACTIVE-METTA-PRIMARY].
asmoses (legacy C++) — AtomSpace-integrated MOSES. [ACTIVE-CPP-ATOMSPACE-BASELINE]; HEAD dde4849c4 2025-12-10.
linas/as-moses (mirror) — [VEPSTAS-MIRROR-SAME-SHA]; not a separate implementation.
hyperon-moses (MeTTa) — Boolean reduction core with ENF pipeline; [SUPERSEDED-BY-METTA-MOSES] for general MOSES, retained as boolean-reduction prototype.
moses (legacy C++) — Original standalone MOSES v3.7.0. [ARCHIVAL-PARADIGM-PREDECESSOR] — last commit 2023-09-19.
moses-optimization-algorithms (C++) — [STANDALONE-EXPERIMENT-NOT-FORK]; independent commit history (hill climbing + simulated annealing + Nahom32 PR).
elegant-normal-forms-python — Python ENF satisfiability checker.

Cluster-pilot extraction archive: scripts/archive/non_clustered_haa_pilot/source5_NACE_AIDSL_MOSES_MeTTaNARS/ (close 2026-05-07).

Status and Resources

Current Status (Non-clustered HAA Source 5 close 2026-05-07)

Active Hyperon-era primary: iCog-Labs-Dev/metta-moses [ACTIVE-METTA-PRIMARY] on PeTTa with full MOSES stack (HEAD 9f69e17, 2026-03-26). Canonical Hyperon-era line.
Active C++ AtomSpace baseline: opencog/asmoses [ACTIVE-CPP-ATOMSPACE-BASELINE] (HEAD dde4849c4, 2025-12-10). Recent commits are cogutils extraction; algorithm work earlier in 2025. Linas Vepstas's linas/as-mosesmirror is byte-identical at the same SHA [VEPSTAS-MIRROR-SAME-SHA].
Boolean-reduction prototype (superseded for general MOSES): trueagi-io/hyperon-moses [SUPERSEDED-BY-METTA-MOSES] for general MOSES; retained as a boolean-reduction / ENF-pipeline prototype line. P12-verified 27 commits ahead of ngeiswei/hyperon-mosesolder sibling.
Archival: Legacy moses(C++, last commit 2023-09-19) [ARCHIVAL-PARADIGM-PREDECESSOR] — README explicitly notes "kept to guaranty backward compatibility" and points to AS-MOSES.
Stale lineage (V5-9 lump): leungmanhin/asmoses [STRICT-FORK-STALE], singnet/asmoses [STRICT-FORK-STALE-MERGED-UPSTREAM], singnet/moses [STRICT-FORK-DIVERGED-LEGACY-FIXES]. None contribute new traditions. iCog-Labs-Dev/moses-optimization-algorithmsis [STANDALONE-EXPERIMENT-NOT-FORK] — independent commit history.
Open research / partial scaffold: MORK-native MOSES per [MORK-MOSES-PARTIAL-SCAFFOLD-OPEN-RESEARCH-LINE] — metta-moses setup.sh references mork_ffi as a setup-level hook only; no committed mork_ffi subtree. The Goertzel 2025-07-21 Mattermost paper "MORK-MOSES Implementation Ideas" is a proposal, not running code.
Proposed: GEO-EVO geodesic extension with TransWeave integration, bidirectional \(f \cdot g\) search control, 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. Current state is 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 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. Cross-cluster integration proposal between MOSES and MORK.

Cluster-pilot extraction archive: scripts/archive/non_clustered_haa_pilot/source5_NACE_AIDSL_MOSES_MeTTaNARS/ (close 2026-05-07; V5-5..V5-10 + V5-15 carry-forwards locked).