About Hyperon+AtomSpace

AtomSpace is the foundational data structure at the heart of Hyperon — a typed, content-addressed metagraph that serves as both shared memory and control plane for all cognitive processes. It is the substrate in which knowledge, code, inference results, attention values, motivational states, and neural representations all coexist and interoperate.

Status: The AtomSpace concept and Space API abstraction are current — implemented in the reference Hyperon codebase (hyperon-experimental) and in MORK. The reference AtomSpace, MORK, and DAS backends are operational. Neural Spaces are experimental; blockchain-backed Spaces via F1R3FLY are proposed.

What Is a Metagraph?

An AtomSpace is a generalization of a hypergraph. Where a traditional graph connects pairs of nodes with edges, and a hypergraph allows edges to connect arbitrary sets of nodes, a metagraph goes further: edges (Links) can themselves be members of other edges, and both nodes and links carry typed values. This recursive structure naturally represents the nested, multi-relational knowledge structures required for general intelligence — logical implications, probabilistic dependencies, procedural programs, and attention metadata can all be expressed as atoms within the same graph.

Every atom in AtomSpace is typed. The type system encodes data categories (symbols, numbers, expressions), function types, and logical connectives. The scope and enforcement of type constraints varies across backends — the reference implementation and MORK each handle types somewhat differently. MeTTa programs can introspect and manipulate the type structure itself.

Code Is Data

A defining feature of AtomSpace is that programs and data share the same representation. A MeTTa function definition, a PLN inference rule, a MOSES-generated program, and a factual knowledge assertion are all atoms in the metagraph. This homoiconicity enables:

• Reflective self-modification: Programs can inspect, analyze, and rewrite themselves and each other at runtime.
• Cognitive synergy: Different cognitive processes naturally share representations because they all operate on the same substrate.
• Inference over code: PLN can reason about the properties of programs just as it reasons about factual knowledge.

The Space API

AtomSpace is accessed through a universal Space API that abstracts over multiple possible backends. A Space supports operations for adding, removing, querying, and pattern-matching atoms. Current and planned backends:

• Reference AtomSpace (current) — The Rust implementation in hyperon-experimental, providing the canonical semantics for MeTTa execution.
• MORK (current) — The high-performance core. A prefix-tree (trie-map) based engine achieving large speedups over previous implementations. MORK stores S-expressions as paths in a radix tree, enabling near-constant-time content-addressed lookup. Its Zipper Abstract Machine (ZAM) supports multi-threaded parallel execution. (See MORK for details.)
• DAS (Distributed AtomSpace) (current) — A distributed backend that decouples persistence (Long-Term Importance) from immediate dynamics (Short-Term Importance via an Attention Broker). DAS enables AtomSpaces spanning multiple machines with Hebbian learning-based resource allocation. (See DAS for details.)
• Neural Spaces (experimental) — Wrappers that expose neural network models (LLMs, embedding models, vision systems) as queryable Spaces, enabling symbolic processes to interact with neural outputs through the same API.
• Blockchain-backed Spaces (proposed) — AtomSpaces persisted on ASI Chain via F1R3FLY's RSpaces, providing cryptographic provenance and decentralized access.

Content Addressing

Atoms in AtomSpace are content-addressed — identified by what they contain rather than where they are stored. In MORK, this is implemented through content identifiers (CIDs) derived from the atom's path in the trie structure, enabling efficient verification and deduplication. Content addressing is what makes distributed and decentralized AtomSpaces practical: the same atom resolves to the same identifier regardless of which node stores it.

Truth Values and Metadata

Atoms carry associated values beyond their structural content:

• Truth Values: Probabilistic confidence measures used by PLN for uncertain reasoning. Hyperon supports multiple truth value types including simple (strength, confidence), distributional, and indefinite truth values.
• Attention Values: Short-Term Importance (STI) and Long-Term Importance (LTI) scalars managed by ECAN to regulate which atoms receive computational resources.
• Custom Values: Arbitrary typed metadata can be attached to atoms, including tensors, timestamps, provenance records, and motivational annotations.

Historical Context

The AtomSpace concept originated in the OpenCog project as a C++/Scheme hypergraph database. The original implementation stored atoms in an in-memory graph with optional PostgreSQL persistence. In Hyperon, the concept has been generalized: AtomSpace is now an abstract interface (the Space API) that can be implemented on different backends — from MORK's prefix trees to DAS's distributed storage — while preserving consistent semantics for cognitive processes built on top of it.

Technical Deep Dive: AtomSpace Full — metagraph formal definition, Atom/Value distinction, TruthValue-to-FloatValue transition, Space API abstraction, classical C++ vs. Rust implementations, performance architecture, and historical design decisions.

Key References

• Goertzel, B. (2025). Hyperon for AGI⇒ASI Whitepaper, §2: Hyperon System Design
• Goertzel, B. (2012). Building Better Minds, Ch. 19–20: OpenCog Framework and Knowledge Representation
• opencog/atomspace — Original C++ AtomSpace implementation
• trueagi-io/hyperon-experimental — Reference Rust AtomSpace in Hyperon