YantrikDB — A Cognitive Memory Engine for Persistent AI Systems

The memory engine for AI that actually knows you.

Get Started in 60 Seconds

For AI agents (MCP — works with Claude, Cursor, Windsurf, Copilot)

pip install yantrikdb-mcp

Add to your MCP client config:

{
  "mcpServers": {
    "yantrikdb": {
      "command": "yantrikdb-mcp"
    }
  }
}

That's it. The agent auto-recalls context, auto-remembers decisions, and auto-detects contradictions — no prompting needed. See yantrikdb-mcp for full docs.

As a Python library

pip install yantrikdb

The engine ships a default embedder (potion-base-2M, ~7 MB, distilled from BGE-base-en-v1.5) — record_text() / recall_text() work out of the box. No sentence-transformers install. No first-run model download. No ONNX runtime. Just one pip install.

import yantrikdb

# Default: bundled embedder, dim=64. Just works.
db = yantrikdb.YantrikDB.with_default("memory.db")

db.record("Alice is the engineering lead", importance=0.8, domain="people")
db.record("Project deadline is March 30", importance=0.9, domain="work")
db.record("User prefers dark mode", importance=0.6, domain="preference")

results = db.recall("who leads the team?", top_k=3)
# → [{"text": "Alice is the engineering lead", "score": 1.0}, ...]

db.relate("Alice", "Engineering", "leads")
db.get_edges("Alice")

db.think()  # consolidate, detect conflicts, mine patterns

db.close()

Want higher-quality embeddings?

Three opt-in upgrade paths, in increasing weight:

# 1. Larger bundled variant — downloads on first call, caches under
#    your user data dir. Self-hosted from yantrikos/yantrikdb-models;
#    no HuggingFace dependency, no rate limits.
db = yantrikdb.YantrikDB("memory.db", embedding_dim=256)
db.set_embedder_named("potion-base-8M")   # ~28 MB, ~92% MiniLM
# or:  db.set_embedder_named("potion-base-32M")  # ~121 MB, ~95% MiniLM

# 2. Bring your own embedder (sentence-transformers, fastembed, custom).
from sentence_transformers import SentenceTransformer
db = yantrikdb.YantrikDB("memory.db", embedding_dim=384)
db.set_embedder(SentenceTransformer("all-MiniLM-L6-v2"))

# 3. Slim build (no bundled embedder, must set_embedder yourself).
#    For deployments where the ~7 MB bundle is intolerable.
#    Rust:  yantrikdb = { version = "0.7", default-features = false }

Path	Quality vs MiniLM	Size on disk	Install network
Bundled default (`with_default`)	~89%	~7 MB (bundled)	none
`set_embedder_named("potion-base-8M")`	~92%	~28 MB (cached)	first call only
`set_embedder_named("potion-base-32M")`	~95%	~121 MB (cached)	first call only
`set_embedder(MiniLM)`	100% (baseline)	~80 MB	sentence-transformers' own download

As a Rust crate

[dependencies]
yantrikdb = "0.7"

# Want set_embedder_named() for runtime model upgrades?
# yantrikdb = { version = "0.7", features = ["embedder-download"] }

# Slim build (no bundled embedder, no network code path):
# yantrikdb = { version = "0.7", default-features = false }

The Problem

Current AI memory is:

Store everything → Embed → Retrieve top-k → Inject into context → Hope it helps.

That's not memory. That's a search engine with extra steps.

Real memory is hierarchical, compressed, contextual, self-updating, emotionally weighted, time-aware, and predictive. YantrikDB is built for that.

Why Not Existing Solutions?

Solution	What it does	What it lacks
Vector DBs (Pinecone, Weaviate)	Nearest-neighbor lookup	No decay, no causality, no self-organization
Knowledge Graphs (Neo4j)	Structured relations	Poor for fuzzy memory, not adaptive
Memory Frameworks (LangChain, Mem0)	Retrieval wrappers	Not a memory architecture — just middleware
File-based (CLAUDE.md, memory files)	Dump everything into context	O(n) token cost, no relevance filtering

Benchmark: Selective Recall vs. File-Based Memory

Memories	File-Based	YantrikDB	Token Savings	Precision
100	1,770 tokens	69 tokens	96%	66%
500	9,807 tokens	72 tokens	99.3%	77%
1,000	19,988 tokens	72 tokens	99.6%	84%
5,000	101,739 tokens	53 tokens	99.9%	88%

At 500 memories, file-based exceeds 32K context windows. At 5,000, it doesn't fit in any context window — not even 200K. YantrikDB stays at ~70 tokens per query. Precision improves with more data — the opposite of context stuffing.

Evidence (reproducible)

Every claim here points at a runnable harness — not a static number. Each is gated in CI (.github/workflows/benchmark.yml) so a regression fails the build.

Recall doesn't degrade as the corpus grows, and stays fast. python -m yantrikdb.eval.benchmark holds a fixed signal corpus while adding distractors and measures recall + latency at each scale. Sample run: recall@k 0.938 → 0.929 as memories grow 7×, with p95 recall latency under 3 ms. regression_check() is the CI gate.
The knowledge graph earns its keep on connected data. python -m yantrikdb.eval.graph_lift measures recall with entity-expansion ON vs OFF. Verdict on the connected corpus: +2.5% recall, +1.7% MRR — graph expansion helps where memories are actually linked.
Apples-to-apples vs other memory systems. python -m yantrikdb.eval.competitors scores YantrikDB, mem0, Zep, and Letta on the same corpus, same queries, same metrics, no per-system tuning. (Competitors run once their libraries are installed; results are not pre-tuned.)

These run dependency-free on the bundled embedder, so anyone can reproduce them with one command.

Architecture

Design Principles

Embedded, not client-server — single file, no server process (like SQLite)
Local-first, sync-native — works offline, syncs when connected
Cognitive operations, not SQL — record(), recall(), relate(), not SELECT
Living system, not passive store — does work between conversations
Thread-safe — Send + Sync with internal Mutex/RwLock, safe for concurrent access

Five Indexes, One Engine

┌──────────────────────────────────────────────────────┐
│                   YantrikDB Engine                    │
│                                                      │
│  ┌──────────┬──────────┬──────────┬──────────┐       │
│  │  Vector  │  Graph   │ Temporal │  Decay   │       │
│  │  (HNSW)  │(Entities)│ (Events) │  (Heap)  │       │
│  └──────────┴──────────┴──────────┴──────────┘       │
│  ┌──────────┐                                        │
│  │ Key-Value│  WAL + Replication Log (CRDT)          │
│  └──────────┘                                        │
└──────────────────────────────────────────────────────┘

Vector Index (HNSW) — semantic similarity search across memories
Graph Index — entity relationships, profile aggregation, bridge detection
Temporal Index — time-aware queries ("what happened Tuesday", "upcoming deadlines")
Decay Heap — importance scores that degrade over time, like human memory
Key-Value Store — fast facts, session state, scoring weights

Decoupled Write Path (v0.6.6+)

The vector index is structured as a two-tier LSM: a small mutable delta and an immutable HNSW cold tier swapped atomically via ArcSwap. Foreground writes only touch the delta (brief lock, O(1) push); HNSW work amortizes on a dedicated compactor thread. This is what eliminated the production wedge where sustained writes starved readers — see CONCURRENCY.md and docs/decoupled_write_path_rfc.md.

flowchart LR
    subgraph CLIENT["Caller"]
        C1["record / record_with_rid"]
        C2["recall / recall_with_seq"]
    end

    subgraph FG["Foreground — P1, brief locks only"]
        F1["assign_seq<br/>vec_seq.fetch_add<br/>(or fetch_max for cluster seq)"]
        F2["DeltaIndex.append<br/>brief RwLock&lt;Vec&gt; push"]
        F3["bump_visible_seq<br/>DashMap + AtomicU64<br/>(lock-free)"]
        F4["log_op → SQLite WAL"]
    end

    subgraph IDX["DeltaIndex (per engine)"]
        D1[("delta<br/>RwLock&lt;Vec&lt;DeltaEntry&gt;&gt;<br/>cap = delta_max (256)")]
        D2[("cold<br/>ArcSwap&lt;HnswIndex&gt;<br/>lock-free read")]
    end

    subgraph BG["Background — P3, dedicated threads"]
        B1["Compactor (1s tick)<br/>fires when delta past half-cap<br/>OR oldest entry > max_dirty_age"]
        B2["Materializer pool<br/>N = cores / 2<br/>drains pending oplog ops"]
    end

    subgraph STORE["SQLite (WAL mode, single file)"]
        S1["memories"]
        S2["oplog"]
        S3["entity_edges, sessions, ..."]
    end

    C1 --> F1
    F1 --> F2
    F2 --> D1
    F1 --> F3
    F1 --> F4
    F4 --> S2

    C2 -.->|"optional<br/>wait_for_visible_seq"| F3
    C2 --> D1
    C2 --> D2

    B1 -->|"seal + clone + ArcSwap.store"| D1
    B1 --> D2
    B2 --> S2
    B2 --> S1
    B2 --> S3

The structural invariant. Foreground (P1) and background (P3) do not share a lock primitive that holds for non-O(1) work. The cold tier is read lock-free via ArcSwap; the delta's RwLock is held for the O(1) push only. This is what makes "no single background task can wedge reads, writes, or recovery" enforceable — see CONCURRENCY.md Rules 2 and 3 for the names and failure modes if violated.

Cluster Mode (RFC 010 + Phase 6 RYW)

For multi-node deployments, yantrikdb-server wraps the engine with openraft for leader-elected replication. The four cluster-mutation primitives take the openraft commit-log index as their seq, so all nodes agree on a single global monotonic sequence — read-your-writes works across the cluster, not just within a node.

flowchart LR
    L["Leader<br/>HTTP request"]
    LR["Leader engine<br/>record_with_rid(seq=Some(log_idx))"]
    OR["openraft<br/>commit log"]
    F1["Follower 1 applier<br/>record_with_rid(seq=Some(log_idx))"]
    F2["Follower 2 applier<br/>record_with_rid(seq=Some(log_idx))"]
    R["Reader on any node<br/>recall_with_seq(min_seq=log_idx)"]

    L --> LR
    LR --> OR
    OR -->|replicate + apply| F1
    OR -->|replicate + apply| F2
    F1 -.->|"visible_seq[ns] reaches log_idx"| R
    F2 -.->|"visible_seq[ns] reaches log_idx"| R
    LR -.->|"visible_seq[ns] reaches log_idx"| R

Each record_with_rid / tombstone_with_rid / upsert_entity_edge_with_id / delete_entity_edge_with_id accepts an optional seq: Option<u64>. Single-node callers pass None and the engine allocates; cluster appliers pass Some(commit_log_index) and the engine ratchets vec_seq up to at least that value via fetch_max. After apply, visible_seq[namespace] reaches the log index, so any subsequent recall_with_seq(min_seq=N) blocks just long enough for the local node to have applied through index N — and no longer.

Memory Types (Tulving's Taxonomy)

Type	What it stores	Example
Semantic	Facts, knowledge	"User is a software engineer at Meta"
Episodic	Events with context	"Had a rough day at work on Feb 20"
Procedural	Strategies, what worked	"Deploy with blue-green, not rolling update"

All memories carry importance, valence (emotional tone), domain, source, certainty, and timestamps — used in a multi-signal scoring function that goes far beyond cosine similarity.

Key Capabilities

Relevance-Conditioned Scoring

Not just vector similarity. Every recall combines:

Semantic similarity (HNSW) — what's topically related
Temporal decay — recent memories score higher
Importance weighting — critical decisions beat trivia
Graph proximity — entity relationships boost connected memories
Retrieval feedback — learns from past recall quality

Weights are tuned automatically from usage patterns.

Conflict Detection & Resolution

When memories contradict, YantrikDB doesn't guess — it creates a conflict segment:

"works at Google" (recorded Jan 15) vs. "works at Meta" (recorded Mar 1)
→ Conflict: identity_fact, priority: high, strategy: ask_user

Resolution is conversational: the AI asks naturally, not programmatically.

Semantic Consolidation

After many conversations, memories pile up. think() runs:

Consolidation — merge similar memories, extract patterns
Conflict scan — find contradictions across the knowledge base
Pattern mining — cross-domain discovery ("work stress correlates with health entries")
Trigger evaluation — proactive insights worth surfacing

Proactive Triggers

The engine generates triggers when it detects something worth reaching out about:

Memory conflicts needing resolution
Approaching deadlines (temporal awareness)
Patterns detected across domains
High-importance memories about to decay
Goal tracking ("how's the marathon training?")

Every trigger is grounded in real memory data — not engagement farming.

Multi-Device Sync (CRDT)

Local-first with append-only replication log:

CRDT merging — graph edges, memories, and metadata merge without conflicts
Vector indexes rebuild locally — raw memories sync, each device rebuilds HNSW
Forget propagation — tombstones ensure forgotten memories stay forgotten
Conflict detection — contradictions across devices are flagged for resolution

Sessions & Temporal Awareness

sid = db.session_start("default", "claude-code")
db.record("decided to use PostgreSQL")  # auto-linked to session
db.record("Alice suggested Redis for caching")
db.session_end(sid)
# → computes: memory_count, avg_valence, topics, duration

db.stale(days=14)    # high-importance memories not accessed recently
db.upcoming(days=7)  # memories with approaching deadlines

Full API

Operation	Methods
Core	`record`, `record_batch`, `recall`, `recall_with_response`, `recall_refine`, `forget`, `correct`
Knowledge Graph	`relate`, `get_edges`, `search_entities`, `entity_profile`, `relationship_depth`, `link_memory_entity`
Cognition	`think`, `get_patterns`, `scan_conflicts`, `resolve_conflict`, `derive_personality`
Triggers	`get_pending_triggers`, `acknowledge_trigger`, `deliver_trigger`, `act_on_trigger`, `dismiss_trigger`
Sessions	`session_start`, `session_end`, `session_history`, `active_session`, `session_abandon_stale`
Temporal	`stale`, `upcoming`
Procedural	`record_procedural`, `surface_procedural`, `reinforce_procedural`
Lifecycle	`archive`, `hydrate`, `decay`, `evict`, `list_memories`, `stats`
Sync	`extract_ops_since`, `apply_ops`, `get_peer_watermark`, `set_peer_watermark`
Maintenance	`rebuild_vec_index`, `rebuild_graph_index`, `learned_weights`

Technical Decisions

Decision	Choice	Rationale
Core language	Rust	Memory safety, no GC, ideal for embedded engines
Architecture	Embedded (like SQLite)	No server overhead, sub-ms reads, single-tenant
Bindings	Python (PyO3), TypeScript	Agent/AI layer integration
Storage	Single file per user	Portable, backupable, no infrastructure
Sync	CRDTs + append-only log	Conflict-free for most operations, deterministic
Thread safety	Mutex/RwLock, Send+Sync	Safe concurrent access from multiple threads
Query interface	Cognitive operations API	Not SQL — designed for how agents think

Ecosystem

Package	What	Install
yantrikdb	Rust engine	`cargo add yantrikdb`
yantrikdb	Python bindings (PyO3)	`pip install yantrikdb`
yantrikdb-mcp	MCP server for AI agents	`pip install yantrikdb-mcp`

Roadmap

V0 — Embedded engine, core memory model (record, recall, relate, consolidate, decay)
V1 — Replication log, CRDT-based sync between devices
V2 — Conflict resolution with human-in-the-loop
V3 — Proactive cognition loop, pattern detection, trigger system
V4 — Sessions, temporal awareness, cross-domain pattern mining, entity profiles
V5 — Multi-agent shared memory, federated learning across users

Worked example: Wirecard (RFC 008 substrate — with honest limits)

For nearly a decade, Wirecard's filings and EY's audit attested to €1.9B in Philippine escrow accounts. In June 2020 both banks and the central bank formally denied the accounts existed.

When the source_lineage fields are hand-populated — EY as [wirecard, ey] to capture audit dependence on Wirecard-provided documents, BSP as [bsp, bpi, bdo] to capture restatement of the commercial banks — RFC 008's ⊕ discounts the dependent claims, and the contest operator's temporal split distinguishes present-tense contradictions from historical state changes. On this hand-populated data, the substrate produces useful annotations.

Honest limits (surfaced by Phase 2 empirical testing, Apr 2026):

On naturalistic evidence where a real agent populates the fields, the substrate's gates don't reliably fire. Cases B and C of the Phase 2 eval need an extractor/canonicalizer (not yet built) to work; Case A exposed that ⊕ is mathematically incapable of flipping decisions at realistic N, regardless of coefficient tuning.
Current claim: structured schema for evidence provenance/temporal/conflict annotation, useful for audit and inspection. The dependence-discount operator works on curated inputs but needs replacement before it can drive decisions.
Not a current claim: "decision-improvement substrate for AGI-capable agents." That framing is withdrawn pending RFC 009.

See docs/showcase/wirecard.md for the full walkthrough including the Phase 2 negative result and the gold-state ablation that partitioned operator failure from extraction failure. Run the hand-populated demonstration directly:

cargo run --example showcase_wirecard

Research & Publications

📄 Skill as Memory, Not Document (May 2026)

Sarkar, P. (2026). Skill as Memory, Not Document: A Database-Native Substrate for Agent Skill Catalogs. Zenodo.

A measurement paper at 5K-skill scale: token cost vs filesystem catalogs (with the honest 1.49× ablation), retrieval latency (87.3 ms p50), and invalid-skill admission (0% YantrikDB vs 97% document-only baseline). Reproducible scripts + raw CSVs at yantrikdb-server/benchmarks/skill_recall/. Companion blog: yantrikdb.com/papers/skill-substrate.

Earlier work

U.S. Patent Application 19/573,392 (March 2026): "Cognitive Memory Database System with Relevance-Conditioned Scoring and Autonomous Knowledge Management"
Zenodo (software): YantrikDB: A Cognitive Memory Engine for Persistent AI Systems

Author

Pranab Sarkar — ORCID · LinkedIn · developer@pranab.co.in

License

AGPL-3.0. See LICENSE for the full text.

The MCP server is MIT-licensed — using the engine via the MCP server does not trigger AGPL obligations on your code.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

yantrikdb-0.9.3.tar.gz (8.4 MB view details)

Uploaded Jul 14, 2026 Source

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

The dropdown lists show the available interpreters, ABIs, and platforms. Enable javascript to be able to filter the list of wheel files.

yantrikdb-0.9.3-cp314-cp314-win_amd64.whl (12.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.14Windows x86-64

yantrikdb-0.9.3-cp314-cp314-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (13.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.14manylinux: glibc 2.17+ x86-64

yantrikdb-0.9.3-cp314-cp314-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (13.4 MB view details)

Uploaded Jul 14, 2026 CPython 3.14manylinux: glibc 2.17+ ARM64

yantrikdb-0.9.3-cp314-cp314-macosx_11_0_arm64.whl (13.0 MB view details)

Uploaded Jul 14, 2026 CPython 3.14macOS 11.0+ ARM64

yantrikdb-0.9.3-cp314-cp314-macosx_10_12_x86_64.whl (13.2 MB view details)

Uploaded Jul 14, 2026 CPython 3.14macOS 10.12+ x86-64

yantrikdb-0.9.3-cp313-cp313-win_amd64.whl (12.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.13Windows x86-64

yantrikdb-0.9.3-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (13.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.13manylinux: glibc 2.17+ x86-64

yantrikdb-0.9.3-cp313-cp313-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (13.4 MB view details)

Uploaded Jul 14, 2026 CPython 3.13manylinux: glibc 2.17+ ARM64

yantrikdb-0.9.3-cp313-cp313-macosx_11_0_arm64.whl (13.0 MB view details)

Uploaded Jul 14, 2026 CPython 3.13macOS 11.0+ ARM64

yantrikdb-0.9.3-cp313-cp313-macosx_10_12_x86_64.whl (13.2 MB view details)

Uploaded Jul 14, 2026 CPython 3.13macOS 10.12+ x86-64

yantrikdb-0.9.3-cp312-cp312-win_amd64.whl (12.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.12Windows x86-64

yantrikdb-0.9.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (13.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.12manylinux: glibc 2.17+ x86-64

yantrikdb-0.9.3-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (13.4 MB view details)

Uploaded Jul 14, 2026 CPython 3.12manylinux: glibc 2.17+ ARM64

yantrikdb-0.9.3-cp312-cp312-macosx_11_0_arm64.whl (13.0 MB view details)

Uploaded Jul 14, 2026 CPython 3.12macOS 11.0+ ARM64

yantrikdb-0.9.3-cp312-cp312-macosx_10_12_x86_64.whl (13.2 MB view details)

Uploaded Jul 14, 2026 CPython 3.12macOS 10.12+ x86-64

yantrikdb-0.9.3-cp311-cp311-win_amd64.whl (12.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.11Windows x86-64

yantrikdb-0.9.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (13.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.11manylinux: glibc 2.17+ x86-64

yantrikdb-0.9.3-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (13.5 MB view details)

Uploaded Jul 14, 2026 CPython 3.11manylinux: glibc 2.17+ ARM64

yantrikdb-0.9.3-cp311-cp311-macosx_11_0_arm64.whl (13.0 MB view details)

Uploaded Jul 14, 2026 CPython 3.11macOS 11.0+ ARM64

yantrikdb-0.9.3-cp311-cp311-macosx_10_12_x86_64.whl (13.2 MB view details)

Uploaded Jul 14, 2026 CPython 3.11macOS 10.12+ x86-64

yantrikdb-0.9.3-cp310-cp310-win_amd64.whl (12.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.10Windows x86-64

yantrikdb-0.9.3-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (13.6 MB view details)

Uploaded Jul 14, 2026 CPython 3.10manylinux: glibc 2.17+ x86-64

yantrikdb-0.9.3-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (13.5 MB view details)

Uploaded Jul 14, 2026 CPython 3.10manylinux: glibc 2.17+ ARM64

yantrikdb-0.9.3-cp310-cp310-macosx_11_0_arm64.whl (13.0 MB view details)

Uploaded Jul 14, 2026 CPython 3.10macOS 11.0+ ARM64

yantrikdb-0.9.3-cp310-cp310-macosx_10_12_x86_64.whl (13.2 MB view details)

Uploaded Jul 14, 2026 CPython 3.10macOS 10.12+ x86-64

File details

Details for the file yantrikdb-0.9.3.tar.gz.

File metadata

Download URL: yantrikdb-0.9.3.tar.gz
Upload date: Jul 14, 2026
Size: 8.4 MB
Tags: Source
Uploaded using Trusted Publishing? Yes
Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for yantrikdb-0.9.3.tar.gz
Algorithm	Hash digest
SHA256	`990f57d966fb448ef3a87e197bbbde97f31fc3bc3b71eb50d754b62229d26717`
MD5	`331c876c6f24780ba602577e2ac6db62`
BLAKE2b-256	`c27de54828f3911c7609912f45c2b1ec2c687951029586fc621492f66ffec9bd`

Algorithm	Hash digest
SHA256	`f04a8be6019c5d69fa004d6828af4e67f94c98171528e912bde3bf709ca886df`
MD5	`58971b15ee93fc231803ed2fdc0943c5`
BLAKE2b-256	`90af569f0c7e3233332b0e099c8242604fb14d6475a439006d56fea69ae185df`

Algorithm	Hash digest
SHA256	`1852fa19ed66a64ce51502d8cf41aec734ddc4237918c01ba866083b66f76a3b`
MD5	`2df1d15f3222bf5aa81b65d20ff2f545`
BLAKE2b-256	`5d5602cc7a873983552d9d0f3e5f70e1f27ecc82084c58a8c1d1d1d1161dc74d`

Algorithm	Hash digest
SHA256	`2eca84a29c8e729f8d9a02bb208639d87082b7014aef981d85ea0f3f283ad30e`
MD5	`eb128241eb3c08e855b060b326e0ef30`
BLAKE2b-256	`8709ca9d9ff097f1bd4f63b8394ed0711acbecac5fb62a94647e0d56ab39822f`

Algorithm	Hash digest
SHA256	`5cfe9a425c0be0af528532b8f19bbfa3349d147f7fb9917560c2702d88ba8cf3`
MD5	`f39b1afc9e067c63342a78cb32129a63`
BLAKE2b-256	`7dc673a5aeee0085c8f8eb987e25aae531df10689d3cc543cab4fc8d9c495d20`

Algorithm	Hash digest
SHA256	`38b20fcb2c1af3f9dcd81a8db532799ccbc42921da442a1a52cc5454f7457404`
MD5	`39303d04ba2612fb7b84fe9e3e8f1417`
BLAKE2b-256	`86d9894aaf33a39d8fbbd84b91272a35a8100c22127cbd44c7c98db69397a2be`

Algorithm	Hash digest
SHA256	`b98f3080f0d04f1899ec76ab88d022b227933786bc9e1d66bd96d35a8b7d9068`
MD5	`e246aff26db6a214edcb9b0d374ca6f6`
BLAKE2b-256	`5020a5cb573a9b8c2a695062399a01e5aae7361ade725bafb1b6728862f3498c`

Algorithm	Hash digest
SHA256	`e18ec0c5dc86cb20be5aaf1df61fb4881ca16a6cead41a00250460a6ff1ebaad`
MD5	`03eead7e6bf1f73492f8e03b4cb011ce`
BLAKE2b-256	`4e466a904a743e3124087a7c3b1987c9d3994989fa3e5120cc8392008038d38b`

Algorithm	Hash digest
SHA256	`f96e0a1df7fbc81a783ab259638b9562b0e27f7088a36f4004371beab5a3448d`
MD5	`5b4ca12c6b5e11d7381a858a1b9266ae`
BLAKE2b-256	`6d05d9fd8cccd55e8af8c9b856846ccc54553353ceebb58c30722c5300946a27`

Algorithm	Hash digest
SHA256	`c0728a310cd498210fece041a97cf0c21d0e8a7f936d4a0f35fcf3a04e664a9b`
MD5	`a643325d751bb883c4ea8a4156dfc247`
BLAKE2b-256	`e9c40530ed5d82e5e3838f09ee2841d92e0181a5882acef814153a4dd7e0acef`

Algorithm	Hash digest
SHA256	`fbe0075c0486f85b0fedb07479f6b51314aecad27a1460bb76ff6f6ded885d44`
MD5	`a87b8bab29c1c50bba0ede551694bac5`
BLAKE2b-256	`53e8e118d1d7c734f28f3eabcda03a0f13bac49d8d41f90b7d19cbba5e2d37a8`

Algorithm	Hash digest
SHA256	`bb67a2922148bd8b2fd2cba866799967bced97c4c36c02adb7fa55e8aa08649e`
MD5	`9de3bcd0e16a14a61af00eb4918a365e`
BLAKE2b-256	`88ddccb8dd0b077295e5473f81c2ab179e88fefe09ba35001447fd20976dd883`

Algorithm	Hash digest
SHA256	`318ac02baf2e261a44acd4c2af88f1b25662aec7cb199acf36deefe0715d09f0`
MD5	`f5f4b443ba4684e1b1fd785f7be91365`
BLAKE2b-256	`a914041164dcf26d4a5dee76059848c42d2433c6c6bf05722967543b8a1ce841`

Algorithm	Hash digest
SHA256	`64ea4d202e42c8782f8f5f8a6e8965640fe33d061d54448dc8cabcc9f6ffc301`
MD5	`ec2cbb7d4385e68cf55cbc10d4e50d60`
BLAKE2b-256	`669d8cfc2bd50ca553cd07b9ca28d38cb075f2f1e01042940c750175373332e3`

Algorithm	Hash digest
SHA256	`eadb365aa666a830fd3d6067028a67e616b99fbab111d5b41db197dc480d6778`
MD5	`fe64c2a2221465848379ddfb0186243f`
BLAKE2b-256	`c8f80d75a8c4a56ad2ce5d05454300518925abe213326e3e27ffdb05c260005f`

Algorithm	Hash digest
SHA256	`0c56b10ae3979faed5a9393441b5155c46e3f31bfbe1b8cc3a3b936deb1c249e`
MD5	`9a21583a8b89093e6fcbebcb0faa106b`
BLAKE2b-256	`a38f92915f4ea1aad30106a6d30742cc7fe90fb428a8ea478a4cbc2ac1912426`

Algorithm	Hash digest
SHA256	`3f9bc3d16fafac95a2469116b8ef6f728241689b7add9f611f10c138167c7631`
MD5	`16b1df1e63e0076400546fe7053cdcce`
BLAKE2b-256	`34fb75ac7960e6839f7c6483ded2516550e215d51b41cadcb5a7675757958958`

Algorithm	Hash digest
SHA256	`db8bc10cc7f6ddd48dc72c14ff23086de6798297b245afbed4834dd9ce3889d3`
MD5	`11f3c061bbc2c59b420561bbd164b151`
BLAKE2b-256	`bee51810f6a157931017a8c2e69eaffacbfda1e9a53acfa2caa64fe0e42d154b`

Algorithm	Hash digest
SHA256	`7eccdcd93ebbfcd47fa7dd5971a13443b4b790c9f4c4ce6d0a9ad022ca75e312`
MD5	`1fc8760957a736c3a99fd33b55bcbe97`
BLAKE2b-256	`f21ebe874a93994d602bb42391d587e72d24b456d67368623779f4df69a13415`

Algorithm	Hash digest
SHA256	`f2a69348612bcfd708d1b64da974eea851c31d4a350320f6414dca8227f0c471`
MD5	`a8b460037c4ac2755fc01ab5a70f536a`
BLAKE2b-256	`83abb14b8a900ace810094fdf851470a0189a9e6a3fa3fb286521246f04a712e`

Algorithm	Hash digest
SHA256	`9cc0c141d1f6e5b808446a2c3986387c82f5c4fc3ffe440bfd84bb3c922a641d`
MD5	`e84af08081c1d12a3dda97a572c42f87`
BLAKE2b-256	`290d584ec22e989d17da3d29a009ccab10c58071f1a02234c4bc74a88604299e`

yantrikdb 0.9.3

YantrikDB — A Cognitive Memory Engine for Persistent AI Systems

Get Started in 60 Seconds

For AI agents (MCP — works with Claude, Cursor, Windsurf, Copilot)

As a Python library

Want higher-quality embeddings?

As a Rust crate

The Problem

Why Not Existing Solutions?

Benchmark: Selective Recall vs. File-Based Memory

Evidence (reproducible)

Architecture

Design Principles

Five Indexes, One Engine

Decoupled Write Path (v0.6.6+)

Cluster Mode (RFC 010 + Phase 6 RYW)

Memory Types (Tulving's Taxonomy)

Key Capabilities

Relevance-Conditioned Scoring

Conflict Detection & Resolution

Semantic Consolidation

Proactive Triggers

Multi-Device Sync (CRDT)

Sessions & Temporal Awareness

Full API

Technical Decisions

Ecosystem

Roadmap

Worked example: Wirecard (RFC 008 substrate — with honest limits)

Research & Publications

📄 Skill as Memory, Not Document (May 2026)

Earlier work

Author

License

Project links

Key dates

Owner

Credits

GitHub Statistics

License expression

Requires

Provides Extra

Tags

Classifiers

Download files

Source Distribution

Built Distributions

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

Algorithm	Hash digest
SHA256	`b16cc5f09b6e7843cc5f11354c4394307dacc3c85006b7a44afdd1dec2da1fbc`
MD5	`e540e27236bb2a66db004788da46607a`
BLAKE2b-256	`21f1c7a8abfb51e8747aa363e1339443805b8bf3f1d5c23f3f495c6eaf314330`

Algorithm	Hash digest
SHA256	`dcfdf55b15d50880f99e9015f9563e6521328f141d99337cda471e914b853446`
MD5	`a4e265c860d18ef18689634207af4492`
BLAKE2b-256	`33a5d12d9c73e5ab55289181e4e681171cd728c450f124ef7f44cdbb909c404b`

Algorithm	Hash digest
SHA256	`997e821e9c8a10e36d3e2267be435bfcc3a3df3facfece47d44f6934bdf0da8b`
MD5	`a6d2ff9584c6a49a3067f812adddff5d`
BLAKE2b-256	`a76bc66cedab316e822ec09b8016943aa9397ff418c353b8e3a664b7ed7f8d90`

Algorithm	Hash digest
SHA256	`639a8535f281d4fd864d95e524e427324bd5250525b23d40231300bc61ea50c4`
MD5	`b113a65a61d6c36e8ad5b5b3bf0c26b3`
BLAKE2b-256	`ba134eff6f69498272fb15dc430cb119dd38d665604cffe4d61a3870a5ff7e42`

Algorithm	Hash digest
SHA256	`b5dc4fd28487a8cdc38f9c242f8744943d09422743a5bc89abc7ad1fa6243e22`
MD5	`1fd9402c4a64b80e51ccaf2a4703e556`
BLAKE2b-256	`3258fe34b3ff1d067b017cf59e004d4148a9b9e0e494dc565e0c0fa74950b52e`