Home / About Hyperon / OpenCog Legacy / OpenCog Legacy Full
Responsible: Ben Goertzel (architect across all three eras), Cassio Pennachin (CogPrime co-architect), Nil Geisweiller (MOSES/PLN developer), Linas Vepstas (AtomSpace/NLP infrastructure)
Papers: Goertzel, Pennachin, Geisweiller (2012), Building Better Minds; Goertzel, Pennachin, Geisweiller (2014), Engineering General Intelligence Vol 1–2; Goertzel (2006), The Hidden Pattern; Goertzel (2025), Hyperon Whitepaper
Status: OpenCog Classic is legacy — archived since ~2021 but with several components still maintained (cogutil, cogserver, link-grammar). Hyperon is the active successor. This card documents the architectural evolution, not a living system.
This card provides technical depth beyond the concise OpenCog Legacy index card. OpenCog was the open-source AGI framework (2008–2021) that preceded Hyperon. Its specific AGI design, CogPrime, was the direct ancestor of Hyperon's PRIMUS architecture.
Related cards: AtomSpace Full (substrate evolution), PLN Full (reasoning evolution), MOSES Full (program learning evolution), Semantic Parsing Full (NLP evolution), PRIMUS Full (CogPrime successor)
Every major OpenCog Classic component has a Hyperon successor.
| OpenCog Classic | Tech | Hyperon Successor | Tech | What Changed |
|---|---|---|---|---|
| AtomSpace | C++, Guile, Python | Space API | Rust, Python, multiple backends | Generalized behind a universal Space API. |
| Atomese | Scheme S-expressions | MeTTa | Purpose-built language | Homoiconic language with formal types. |
| URE | C++, Scheme | MeTTa chaining | Pure MeTTa | C++ term-rewriting to MeTTa graph rewrites. |
| PLN | C++, Scheme, URE | PLN (MeTTa) | Pure MeTTa, PeTTa | Adds quantale factor graphs, geodesic control. |
| MOSES | C++, Boost, combo | metta-moses | Pure MeTTa | Full reimplementation with GEO-EVO. |
| ECAN | C++, CogServer agents | metta-attention | MeTTa, PeTTa | Adds optimal transport theory. |
| OpenPsi | Scheme, rule-based | MetaMo | MeTTa + Python | Category-theoretic pseudo-bimonad. |
| Link Grammar + RelEx | C + Java | Semantic Parsing | Various | LG maintained. RelEx deprecated. |
| GHOST | Scheme, ChatScript | PRIMUS robotics layer | MeTTa + game/robot | Minecraft, social robotics, game AI. |
| CogServer | C++, telnet/HTTP | DAS + MeTTaCycle | C++, Rust, blockchain | Distributed queries + ASI Chain. |
| cogutil | C++, v2.2.1 | (no direct equivalent) | N/A | Hyperon Rust codebase provides own infra. |
The transition was motivated by five architectural limitations identified over a decade of experience with OpenCog Classic:
1. Integration depth was insufficient. Building Better Minds (2012) identified cognitive synergy as the "secret sauce" but acknowledged that OpenCog implemented "perhaps one third to one half of the key ideas." Component boundaries created brittle semantic bottlenecks. The AtomSpace was designed as a blackboard for inter-subsystem communication, but this "doesn't work in practice" because subsystems (MOSES, RelEx, etc.) maintained their own internal representations with no shared ontology. MOSES in particular was "rather isolated from the rest of OpenCog" (Nil Geisweiller, 2017).
2. Language limitations. Atomese required manual encoding in Scheme and lacked self-modification. The rule engine suffered from fragmentation: URE, Pattern Matcher, Scheme/Python scripting, and GroundedSchemaNodes each handled different aspects of inference with no unified execution model. MeTTa provides homoiconicity, a formal type system, and native nondeterminism.
3. Performance architecture. The C++ AtomSpace used flat hypergraph storage with \(O(N)\) scan costs. MORK's prefix-tree provides near-constant-time lookups, lock-free concurrent access, and memory layouts supporting both symbolic and dense numeric operations.
4. Mathematical foundations were missing. OpenCog's components were "loosely integrated" without shared formal controls. The 2025 whitepaper introduces quantale-based weakness theory, geodesic inference control, and TransWeave as unifying mathematical principles.
5. No decentralization. OpenCog ran on single machines or small clusters. Hyperon targets decentralized execution via ASI Chain with cryptographic provenance and capability-secured processes.
As of 2014, MOSES and Link Grammar were the only OpenCog components with proven commercial deployments:
Ben Goertzel acknowledged (2014): "OpenCog on its own can do lots of nontrivial things, but not lots of useful things." The barrier to contribution required being "the AI equivalent of a kernel hacker." This dual problem — no practical applications and extreme expertise requirements — explains why MOSES and Link Grammar survived the Hyperon transition (they had independent adoption), while most other components were reimplemented from scratch. (Making-OpenCog-useful, OpenCog Code Maturity Guide, 2014)
The 2015 roadmap showed most 2013 goals unmet: collective cognition, scalable knowledge store, formal release, university adoption — all "nope." The URE port and Hanson Robotics integration were the main achievements. (OpenCog-Development-roadmap, 2015)
CogServer: Not Needed, Deep Problems. CogServer was not required — Guile and Python both provided network interfaces independently. Mind-agent scheduling had fundamental problems: OS-level scheduling is "a really hard problem," agents doing I/O block scheduling, and "for robustness and reliability, it's usually better to split up large things into multiple network servers." These criticisms directly motivated the transition to DAS + MeTTaCycle. (CogServer-replacement, 2016)
Anti-CYC Design Philosophy. OpenCog's use of probabilistic truth values was specifically motivated by avoiding CYC's limitations: (1) impossible for humans to assemble large self-consistent statement sets, and (2) "essentially all common-sense logic cannot be converted into crisp-logic." This position directly aligns with Hyperon's vision of AGI systems developing their own representations. (What-CYC-has-done-wrong, Knowledge-Representation-Standard-for-AGI, 2014–2016)
Deliberate Rejection of Object-Orientation. "The hypergraph structure of OpenCog allows you to represent pretty much any knowledge you want and is a lot more general than OO." The tension between domain-specific convenience and foundational generality was resolved in favor of generality every time. (Why-OpenCog-paradigm-detached-from-Object-Orientation, 2014)
Pattern Mining Evolution. The C++ pattern miner was replaced by a URE-based miner in May 2018 (cog-mine API), unifying pattern expansion as rule application with surprisingness as fitness: \(\max\{P(ABC) - \max_{\text{factorizations}} P, \; P(ABC) - \min_{\text{factorizations}} P\}\). The miner discovered transitivity and symmetry meta-rules from ConceptNet, automatically exported as BindLink PLN rules via a Pattern-to-Rule converter — closing the learning-to-reasoning loop. (Pattern-mining-and-NLP-parsing-and-MOSES-with-the-URE, Results-of-Frequent-pattern-mining-from-subsets-of-ConceptNet-corpus, 2014–2018)
OpenPsi: Conceptual Confusion. The OpenPsi motivational framework (2007–2014, inspired by Joscha Bach's MicroPsi) suffered from a fundamental architectural problem: it was "a frankensteinian mashup of two unrelated ideas: a generic rule-processing system, and a simplistic model of human emotions." The inappropriate conflation of emotional state labels ("happiness," "sadness") with tactical action selection required conceptual separation. OpenPsi's cognitive schematic pattern (context & action → goal) carried forward to MetaMo, but the emotional modulator overlay was abandoned. (Provenance: official-site, wiki.opencog — OpenPsi)
Language Binding Failures. Attempts to create OCaml and Haskell bindings for the AtomSpace were started and abandoned because their static type systems collided with the AtomSpace's dynamic typing — "a few grad students and professors tried it, worked at it for a while, and then gave up." Only Scheme (via GNU Guile, which is dynamically typed and has first-class continuations) and Python survived as practical scripting interfaces. C++ direct access remained 4× faster than Scheme and 10× faster than Python. (Provenance: official-site, wiki.opencog — AtomSpace design notes)
Visualization: A Dead End at Scale. Multiple AtomSpace visualization tools were built and tested on hundreds of atoms, but "failed catastrophically at 20 million atoms." The fundamental problem: visualizers need semantic understanding of atom clusters, not atom-level rendering. No visualization approach was found to be useful at production scale. (Provenance: official-site, wiki.opencog — AtomSpace design notes)
Pattern Miner: The "What's Next?" Problem. The Pattern Miner was ultimately abandoned as an "OpenCog Fossil" due to three compounding issues: dependency on the deprecated URE, scalability challenges ("not hard" for hundreds of patterns from ten thousand atoms, but "a scalability and performance challenge" for hundreds of thousands from tens of millions), and crucially unclear downstream utility — "there's no clear answer to 'what's next?' So you found a bunch of patterns… now what?" The Language Learning project (opencog/learn) eventually provided similar functionality through a different representational approach: jigsaw-puzzle connectors rather than lambda-expression hierarchies, bridging "symbolic representations (graphlets) and vector representations (as typical of deep learning neural nets)." (Provenance: official-site, wiki.opencog — Pattern Miner)
The core thesis — that AGI requires multiple co-adapted cognitive processes sharing a common knowledge substrate — is continuous from the Webmind era through Hyperon. The algorithms evolved; the architecture principles deepened; the substrate was replaced. The pattern matcher proved robust throughout the OpenCog era. ECAN's attention allocation model also carried forward, though the discovery that "the dependence of behavior on parameters is too chaotic" for gradient-based tuning motivated the move toward formal information-geometric controls in the 2025 design.
Several opencog/* repositories continue to receive updates from original OpenCog contributors — most notably Linas Vepstas, historically the project's top contributor. This ongoing work independently maintains the classical OpenCog stack, but is not coordinated with the Hyperon project.