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.
"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 |
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:
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).
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.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.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.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.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.| 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.
+Implementations subcard.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.