AtomSpace Backend Integration

Draft — This content has not been approved for publication.

Scope

This card synthesizes the AtomSpace Backend Integration Cluster Pilot (2026-04-29). It is the cross-source consolidation of integration design findings for the Phase 3 (Jan–Apr 2026) prototype of a Decko/Rails/PostgreSQL → AtomSpace integration. The pilot ran four sources under cross-model triangulation (Claude orchestrator + Codex + Gemini, with reconciliation across all three). Per-source briefs, per-model findings, and reconciliations live at scripts/archive/atomspace_pilot/source*/ in this repo.

Use this card as the entry point for any future integration-engineering work; the four-layer taxonomy and the Phase 3 architecture lock-in below are the canonical statements, and the source-by-source reconciliations are the canonical evidence record.

Four-Layer AtomSpace Taxonomy

"AtomSpace" at this point in time is not a single coherent backend. The cluster pilot locked in a four-layer taxonomy (R4.J1) that any future agent MUST resolve before drawing conclusions about features, performance, or Decko-integration suitability:

#	Layer	Repos / Evidence	Decko relevance
1	Classical AtomSpace StorageNode	atomspace + atomspace-storage + atomspace-pgres + atomspace-rocks + atomspace-cog + atomspace-bridge	Best read-side SQL import ancestor; not Decko-write-ready
2	Hyperon Space	hyperon-experimental: GroundingSpace / SpaceMut / DynSpace; `lib_spaces.metta`	MeTTa-facing demos; not primary Decko backend
3	DAS AtomDB + services	singnet/das: AtomDB + Query Engine + AttentionBroker + agents; MorkDB	Candidate later query/deployment layer; delete + server-pin caveats
4	MORK native substrate	trueagi-io/MORK + PathMap + `mork_ffi` + SDK + server branch	Performance substrate; requires adapter layer for Decko semantics

Phase 3 Architecture (Lock-In)

Architecture: READONLY-ATOMSPACE-BRIDGE. Decko/Rails/PostgreSQL stays the source of truth. AtomSpace serves as a read-only semantic mirror. The Decko MCP API (mature, JWT-authenticated, full card CRUD + history + files + relations) is the extraction surface. NO write-through to DAS or MORK in Phase 3.

Implementation mechanism: open question for Phase 3 prototype benchmark. Two viable options under the read-only umbrella:

atomspace-bridge style import / small custom exporter — Source 2 verified atomspace-bridge as a one-way SQL→Atomese loader (BridgeStorageNode, public-schema only, write stubs empty). Lower complexity if it meets the <500ms fetch gate.
mork_ffi for low-latency queries + mork_loader.py for periodic hydration — Source 4 verified the Docker-based mork_loader.py (das-toolbox) and the mork_ffi C-callable surface (rust_mork(cmd, input)). Higher engineering effort but can directly meet latency targets.

Decision criterion: <500ms fetch gate + simplest Decko-mirror semantics. If atomspace-bridge style import meets the gate, prefer it (lower complexity). If FFI is required for latency, use it under the read-only umbrella (Decko stays source of truth; FFI serves queries; Loader serves periodic re-hydration).

Cluster-Narrative Findings

The literal from hyperon import Atomspace, MCP snippet in docs/ATOMSPACE-INTEGRATION.md is APOCRYPHAL. Source 2 R2.3 verified, Source 4 re-confirmed via independent Python audit: no MCP symbol exported from hyperon. Decko-MCP is real; ATOMSPACE-MCP does not exist as a package. DECKO-MCP / ATOMSPACE-MCP disambiguation is locked: Decko MCP is the only deployed MCP API in this repo; treat any ATOMSPACE-MCP reference in legacy design docs as a "Conceptual Sketch" until real code emerges.
atomspace-pgres is BACKING-STORE-ONLY and NOT Decko-compatible. Source 2 R2.1: rigid schema (Atom/Value tables, no card semantics, no permissions, no history). Cluster-pilot directive: do NOT recommend atomspace-pgres as the lowest-friction Decko seam.
DAS-MORK coupling is code-real with three caveats (split implementation): DAS-side MorkDB AtomDB backend is real (subclass of RedisMongoDB); MORK server is pinned through Docker/server-branch path; link/S-expression delete is not supported (MorkDB.cc:268-270 hard-fails). flush_pattern + re_index_patterns provide batch-rebuild workarounds, NOT live mutable-store CRUD. See DAS Full.
MORK is an 8-member workspace, not 7; PeTTa/MORK has been benchmarked to 400M atoms (NOT 500M+). Source 3 R3.3 + R3.5 corrected long-standing wiki claims. PathMap is a foundational sibling repo, not a bundled crate (R3.4); now has its own card at PathMap.
MORK server branch has 49-commit drift past the DAS pin (Source 4 R4.4). DAS Dockerfile pins 578a759 (2025-07-21); local origin/server HEAD is 5b04a1d (2026-04-18) with deadlock and UTF-8 fixes in the gap. Three references not yet reconciled: das-toolbox CLI image tags 1.0.5, Dockerfile pin 578a759, server-branch HEAD 5b04a1d. Production deployment must reconcile all three.
DAS AttentionBroker is the third member of the ECAN-engineering-surrogate lineage (Source 4 R4.D4). ExactCountHebbianUpdater + TokenSpreader; 0/4 strict-literal against the 2009 ECAN paper, like Classic OpenCog C++ ECAN and the metta-attention port. See Attention and Motivation.
Sandbox-tier seams (NOT Phase 3 candidates): hyperon-experimental/python/sandbox/sql_space.py (psycopg2 SELECT generator, no Decko schema/permission/history/file/RichText awareness) and python/sandbox/mork/mork.py (preliminary HTTP wrapper; query() returns empty, add() is pass). Useful as API-style references only.

Phase 4+ Blockers (for any future write-through)

MorkDB link delete (R4.E1) — currently blocking-integration; required for Decko trash/restore semantics and per-card rollback.
MORK server-branch reconciliation (R4.F1, R4.F2) — Dockerfile pin / image-tag / origin/server HEAD must converge with security and deadlock fixes integrated.
Decko semantics not yet expressed as AtomSpace types — card identity vs rename/aliases, revision/event model, file attachment representation, permissions and published/draft status, RichText rendering, sections/TOC, read-after-write / rollback semantics. MORK alone does not provide them; an adapter layer is required (Source 1 R1.A5-A7 + Source 2 R2.B4 + Source 3 R3.G2).
PLN game-rule No-Go theorem still applies — backend integration MUST NOT be described as making PLN globally complete. The PLN cluster pilot No-Go theorem (xiPLN §5; Lean-proven) holds regardless of storage choice. Phase 5 PLN over the integrated AtomSpace requires explicit joint-state / evidence-structure caveats.

Source Archive Map

Source	Scope	Reconciliation
1	Existing design docs (`ATOMSPACE-INTEGRATION.md`, `ROADMAP.md`) + acceptance gates	`scripts/archive/atomspace_pilot/source1_existing_design/findings_reconciled_crossmodel.txt`
2	Classical StorageNode persistence family + atomspace-bridge + atomspace-pgres + Hyperon Space (hyperon-experimental)	`scripts/archive/atomspace_pilot/source2_atomspace_persistence/findings_reconciled_crossmodel.txt`
3	MORK production substrate (kernel + PathMap + FFI/SDK + fork tree)	`scripts/archive/atomspace_pilot/source3_mork_substrate/findings_reconciled_crossmodel.txt`
4	DAS deployment layer + runtime bridge + Attention Broker + integration design memo	`scripts/archive/atomspace_pilot/source4_das_runtime_bridge/findings_reconciled_crossmodel.txt`

The Source 4 reconciliation at Sections A through M plus the Bottom Line is the canonical integration design memo (R4.B4). This synthesis card distills it; consult Source 4 for full evidence.

Related Wiki Cards

About Hyperon+AtomSpace+AtomSpace Full — four-layer taxonomy lock-in lives at the +Implementations subcard.
MORK Full — 8-crate workspace, PathMap dep, server-branch caveats, 400M-not-500M correction.
DAS Full — split-implementation framing, AttentionBroker engineering-surrogate, server-branch drift.
PathMap — foundational sibling-repo trie substrate.
Attention and Motivation — DAS AttentionBroker added to ECAN-engineering-surrogate lineage.

Source

This card was created by the AtomSpace Backend Integration Cluster Pilot on 2026-04-29 as the cluster synthesis deliverable. Cluster archive at scripts/archive/atomspace_pilot/. Top-level orientation in CLAUDE.md (AtomSpace Backend Integration Cluster Pilot section) mirrors the PLN/ECAN/OpenPsi cluster-pilot pattern.