The Synapse Context Engine (SCE) is a brain-inspired memory and context layer for AI systems, designed to function as a System‑2‑like substrate for context assembly.

Instead of treating context as a static retrieval problem (as in traditional RAG pipelines), SCE models memory as an explicit, typed hypergraph. Context is assembled dynamically through spreading activation, allowing systems to recall, relate, and reason over information via network dynamics rather than keyword or embedding similarity alone.

Live activation spreading through memory graph

The result is memory that is:

• Coherent instead of fragmented
• Inspectable instead of opaque
• Bounded instead of unbounded

License: Apache 2.0 • Maintainer: Sasu • Updates: docs/updates/

Constrain and observe the space in which context is constructed, rather than hoping the model behaves safely inside an opaque prompt.

SCE shifts safety and alignment concerns upstream, from model behavior to memory and context construction.

As AI systems move toward greater autonomy and persistence, their memory architectures become fragile:

• Vector databases retrieve isolated chunks and lose relational structure
• Prompt assembly hides context construction inside token sequences
• Hallucinations emerge from fragmented, ungrounded memory representations
• Prompt injection and context poisoning are structurally easy
• Alignment is layered on top of black boxes

SCE explores a different axis of control: architectural safety through explicit structure and observability.

Note: This project originated from need for better memory architecture for agentic systems. While capability / long-term memory improvements were the initial driver, the safety properties that emerged from the architecture became the primary reason for open-sourcing.

The core insight: context construction should be inspectable, bounded, and auditable by design —not retrofitted with behavioral constraints after the model is already deployed.

SCE processes queries through a staged pipeline where each step is independently observable:

Stimulus (Query / Event)
        ↓
Active Focus (Anchor Node)
        ↓
Controlled Graph Propagation
        ↓
Context Synthesis (Pruned + Weighted)
        ↓
LLM Inference ──→ Response
        ↓
Extraction (Phase 1: Concepts, Phase 2: Relations)
        ↓
Integrity & Layout (Mesh Wiring + Hygiene)
        ↓
Memory Encoding (Graph Update)
        ↓
Telemetry & Audit Signals

Modular Design: Each stage in the pipeline is independently configurable. Security layers, pruning strategies, and activation mechanics can be added, modified, or replaced without changing the core architecture. This allows base level experimentation with different safety mechanisms, custom context filters, and domain-specific optimizations. You can always create more advanced methods pipelines (these were created so you can just get a feel of the engine).

Memory is represented as a hypergraph:

Note: there are multiple ways to build these configurations, the following was just created for the preview.

• Nodes represent heterogeneous entities (projects, artifacts, preferences, behaviors, constraints)
• Synapses encode weighted pairwise relationships (source→target)
• Hyperedges connect multiple nodes simultaneously for atomic multi-way relationships

When any node in a hyperedge activates, energy distributes to all connected members (clique activation). This preserves higher-order context that is lost when relationships are decomposed into isolated pairs or flat embeddings.

Example: Instead of separate edges:

• Alice -[ATTENDED]-> Meeting
• Meeting -[DISCUSSED]-> Budget
• Budget -[AFFECTS]-> Project_X

SCE can group these as a hyperedge:

• {Alice, Meeting, Budget, Project_X} labeled DECISION_CONTEXT

When you query about Alice, all four nodes activate simultaneously through the hyperedge —not by traversing three separate edges.

All activation is evaluated relative to an explicit Active Focus node representing the current task or operational context.

Note: This is just an one idea / mechanism to alter the energy flow, there are unlimited possibilities here.

This anchoring prevents free‑floating activation and helps contain:

• Prompt injection
• Context drift
• Runaway propagation

When a stimulus occurs, activation energy is injected into seed nodes and propagates outward with:

• Decay factors (configurable, e.g., 0.8)
• Activation thresholds (e.g., 0.3)
• Depth limits (bounded traversal)

Only meaningfully activated nodes participate in context synthesis. Global flooding is structurally prevented.

Activated nodes are distilled into a structured synthesis layer:

• Ordered by relevance
• Pruned for redundancy
• Fully auditable

The LLM never sees the raw graph—only the synthesized context.

Note: This is very experimental and can be taken to multiple different directions.

SCE exposes internal dynamics through rigorous, information-theoretic metrics—not opaque "vibes":

• Focus (Normalized Entropy): Measures attention drift. 0.02 means diffuse noise; 0.95 means sharp logical coherence.
• Stability (Inverse Variance): Detects when the system is confident vs. chaotic.
• Plasticity (Burst vs Mean): Distinguishes between background learning and sudden "paradigm shift" rewiring.

These signals enable runtime safety gating (e.g., "Stop generation if Focus < 0.1") and precise post-hoc auditing. The math is pure, visible, and unchangeable by the model.

SCE treats context construction as a staged pipeline, not a single opaque function call.

Key properties:

• Every activation path is observable
• Security violations can terminate execution
• Context growth is measurable and bounded

Failure modes become visible instead of implicit.

• Orchestrator: lib/sce/engine/SCEEngine.ts (Thin wrapper, manages subsystems)
• Graph: lib/sce/graph/ (Adjacency Index)
• Physics: lib/sce/activation/ (Spreading Activation, Energy Dynamics)
• Learning: lib/sce/learning/ (Hebbian, Co-Activation)
• Structure: lib/sce/hyperedges/ (Clustering, Consolidation)
• Safety: lib/sce/safety/ (Contradictions, Orthogonality)
• Metrics: lib/sce/metrics/ (Telemetry)
• components/CoreEngine.tsx - UI orchestration and visualization

The CoreEngine component acts as a memory observatory rather than a simple demo UI.

It provides:

• Explicit stimulus injection ("Trigger Pulse")
• Focus anchoring
• Live graph visualization
• Context synthesis output
• Telemetry dashboard

Think of it as mission control for context assembly—designed for debugging, research, and safety analysis.

Security rules block harmful queries before LLM inference

SCE is not a silver bullet for all security concerns— but it reshapes the threat landscape:

Incoming Query
       ↓
[🔥 Cognitive Firewall] ──(Violation)──→ 🛑 Blocked
  (Regex Patterns + Rules)
       ↓
Extraction & Grounding
       ↓
Context Anchoring
       ↓
Spreading Activation
       ↓
[🛡️ System 2 Logic] ──(Contradiction)──→ ⚠️ Flagged
  (Dissonance Check)
       ↓
Context Synthesis ──(Sanitization)──→ 🛑 Filtered
       ↓
LLM Inference

Note on Hallucinations: While not primarily a security concern, SCE's structured memory with source attribution provides better factual grounding than flat retrieval systems. Each activated node carries metadata about its origin, making fabricated information architecturally harder (though not impossible).

Instead of asking the model to behave, SCE limits what it can meaningfully see

Note: in order to force security at runtime / memory layers C++ or Rust is required.

SCE is an exploratory architecture with challenges:

🔴 Critical / Not mature (can be taken to various different directions):

Graph Growth Mechanics

• Connection strategy: Currently connects everything during chat, leading to over-dense graphs
• Node creation heuristics: What triggers new node creation vs. updating existing nodes?
• Node hierarchy different configurations / layers for node creation
• Natural weight distribution: How should weights evolve to reflect true semantic relationships?

Prompt Engineering

• Entity extraction prompts need refinement for different domains
• Response synthesis prompts balancing creativity vs. grounding
• What information should be extracted and persisted vs. discarded?

🟡 Scalability & Performance:

Over-Connection Issues

• Over-connection creates performance issues as graphs grow beyond 1K+ nodes (visible in TypeScript, in Rust "production" this is almost impossible to see)
• Need pruning strategies: temporal decay, relevance thresholds, or periodic consolidation

🟢 Thoughts / Findings:

RAG Comparison

• While the "production" versions (C++ or Rust) of the SCE can be used to replace RAG, I don't think it should. At it's core it's nothing like RAG (SCE is a brain-like a physics based memory engine) so viewing it as a pure "RAG replacement" is waste of capabilities.
• Rust / C++ allow extreme performance and capabilities, but even after extreme optimization it still cannot beat the RAG / Vector database in pure performance.
• My suggestions is, do not try to use / view it as RAG replacement, instead find novel ways to truly utilize it.

Parameter Sensitivity

• The preview has manual inputs, but these be automated instead than hand-tuned.

• Competing with vector databases on raw retrieval speed
• Replacing LLMs or transformer architectures
• Acting as a drop‑in RAG replacement
• Claiming solved alignment

This TypeScript / standalone version of SCE is an exploratory architecture & research preview, not a production framework:

• I have created an production version of SCE (for broader system), but even I cannot quarantee my approach was the best one, so I'm quite interested to see where others will take this.
• Created so more people can experiment with the architecture and share their (non production) version of the architecture
• Can be benefial for multiple fields: ML, Neuroscience, Cybersecurity, Biology and so on.
• The benefits of TypeScript is that it reveals architectural & algorithmic problems in physics based systems more clearly than "production" Rust or C++ versions.
• This is a physics based system, so C++ or Rust is required for production performance and true security.

npm install
npm run dev

Requires Rust & Platform Dependencies (see Quick Start Guide)

npm run tauri dev

or you can build the app (it wil create an installer for your computer)

npm run tauri build

The chat interface exposes the complete pipeline. Active Context Focus (top) shows anchored nodes. Quick Actions (right) provide exploration prompts. System Audit (left) logs every operation in real-time.

Add an API key in settings to use the app (Default / Recommended is Groq)

Note: The stack prioritizes inspectability and cross-platform deployment. Tauri allows the codebase to run as desktop app with SQLite persistence.

SCE draws from neuroscience, graph theory, and cognitive architecture research—adapting concepts for practical AI systems:

• Neuroscience & Memory: Hebbian learning (Hebb, 1949), hippocampal cognitive maps (O'Keefe & Nadel, 1978), complementary learning systems (McClelland et al., 1995)
• Cognitive Architecture: Spreading activation theory (Collins & Loftus, 1975), ACT-R (Anderson et al., 2004), SOAR (Laird et al., 1987)
• Graph Theory: Hypergraphs (Berge, 1973), network communicability (Estrada & Hatano, 2008), spectral graph theory (Chung, 1997)
• Information Theory: Maximal marginal relevance (Carbonell & Goldstein, 1998), information-theoretic pruning (Cover & Thomas, 2006)

For full citations and detailed connections to research traditions, see CITATIONS.md.

This project is developed by a single dev (not a software company, nor a research lab). This project is the result of my personal research, "originally" intended to create more realistic NPC behavior & long-term memory for agentic systems.

Why Open-Sourced: While SCE was built to solve long-term memory challenges, it was open-sourced specifically because of its potential to address many security concerns in current AI systems and perhaps enable safer alignment. If this were purely about better memory architecture, it would have remained proprietary.

Community:

Applications & Extensions:

• Domain-specific adaptations
• Alternative activation strategies
• New core engine ideas
• Novel security methods

If you are interested in:

• AI safety & alignment through architectural constraints
• Alternative memory architectures for agentic / evolving AI systems
• Graph-based context construction
• Inspectable AI reasoning

SCE (TypeScript) research preview is meant for experimentation and does not ship with traditional retrieval benchmarks.

TypeScript is not fit for creating accurate Benchmarks for physics based systems, requires "production" C++ or Rust to utilize the full performance & security.

Even for production versions, there is currently no accepted baseline for evaluating:

• Relational memory coherence
• Context inspectability
• Activation trace quality
• Long-term memory

Premature benchmarks would bias development toward legacy retrieval metrics and misrepresent SCE’s goals.

WARNING: if you plan to proceed with production, make sure you know what you're doing (when you play with runtimes / kernels etc, has the potential to fry your computer)!

All source code and datasets in this repository are licensed under the Apache License, Version 2.0, unless otherwise noted. See the LICENSE file for details.

All content within the docs/ directory (including notes, architectural diagrams, conceptual papers, and images) is licensed under Creative Commons Attribution 4.0 (CC BY 4.0).

If you use SCE or its underlying concepts in academic research, technical reports, or publications, please cite:

@misc{sce_2025,
  title  = {The Synapse Context Engine (SCE): An Inspectable Memory Architecture for Safe AI},
  author = {Lasse Sainia},
  year   = {2025},
  url    = {https://github.com/sasus-dev/synapse-context-engine}
}