Deterministic Provenance Engines for Autonomous Agent Systems: Architecture, Implementation, and Evaluation of the Graph Kernel

Deterministic Provenance Engines for Autonomous Agent Systems: Architecture, Implementation, and Evaluation of the Graph Kernel

\author{Mohamed Diomande
\IEEEauthorblockA{OpenClaw Research

Brooklyn, NY, USA

[email]}}

Abstract

Autonomous AI agents making consequential decisions require infrastructure that ensures every reasoning step is traceable, reproducible, and verifiable. We present the Graph Kernel, a deterministic provenance engine implemented as a single Rust binary (${\sim}15$~KLOC) that produces cryptographically-signed, policy-governed context windows---termed admissible evidence bundles---for autonomous agent reasoning. Unlike general-purpose graph databases, vector stores, or RAG pipelines, the Graph Kernel introduces a formal category of infrastructure we call the provenance engine: a service whose output is not information retrieval but the construction of verifiable evidence with unforgeable authorization proofs.

We evaluate the Graph Kernel across 27 queries spanning five categories (factual recall, relationship mapping, multi-hop reasoning, fuzzy/semantic search, and predicate-specific queries) against three baselines (keyword, BM25, vector-similarity RAG). Results demonstrate perfect relevance (1.00) on multi-hop structural queries---returning causally-connected knowledge chains rather than keyword-coincidence result sets---at sub-300ms latency over a remote PostgreSQL backend. A comprehensive Deep Engineering Posture (DEP) audit scoring 7.4/10 identified 47 findings across 12 dimensions; we implemented 10 critical fixes including native Rust entity normalization, parameterized SQL queries, server-side multi-hop traversal, and connection pool optimization, raising the projected score to 8.4/10.

We further present RAG++, a complementary semantic retrieval engine (${\sim}26$~KLOC Rust core with Python bindings), and describe the hybrid retrieval architecture that bridges structural graph reasoning with vector-similarity search. Comparative analysis against ten industry systems (Neo4j, Amazon Neptune, Apache Jena, Dgraph, TypeDB, Weaviate, LangChain/LlamaIndex, Microsoft GraphRAG, and Zep) establishes that no existing system provides the combination of HMAC-signed deterministic context windows, type-level admissibility enforcement, and policy-governed multi-hop provenance that the Graph Kernel offers. We conclude with a three-phase evolution roadmap spanning optimization, expansion, and transformation of the provenance engine into a universal context authority for heterogeneous agent ecosystems.

IEEEkeywords
provenance engines, knowledge graphs, deterministic context slicing, autonomous agents, HMAC authentication, retrieval-augmented generation, policy governance, Rust systems programming
IEEEkeywords

Introduction

The Context Authority Problem

The deployment of autonomous AI agents---systems that plan, reason, and act across extended multi-turn conversations spanning tens of thousands of turns~[citation: vaswani2017attention]---has exposed a critical infrastructure gap. At inference time, vast conversation histories must be compressed into fixed-size context windows. The prevailing approaches---truncation, summarization, and embedding-based retrieval---treat context selection as an information retrieval problem. But for agents making consequential decisions (code deployment, financial transactions, system administration), context selection is fundamentally a governance problem requiring four properties:

- Reproducibility. Given the same inputs, the system must produce the identical context window, enabling replay and debugging.

- Auditability. Downstream consumers must be able to verify that a context window was authorized by a trusted authority, without accessing the authority's signing secret.

- Policy Compliance. Governance rules must determine which conversation phases (e.g., synthesis vs. debugging artifacts) receive priority in context construction.

- Tamper Resistance. Any modification to a context window after construction must be detectable.

No widely-deployed system---not vector databases~[citation: weaviate2023, johnson2021billion], not RAG pipelines~[citation: lewis2020rag, gao2023rag_survey], not general-purpose graph databases~[citation: neo4j2024, angles2017foundations], not memory layers~[citation: zep2024]---addresses these requirements as first-class concerns. They optimize for relevance, latency, or scale, but not for provenance.

The Provenance Engine Category

We propose that autonomous agent systems require a new infrastructure category:

skip
Definition 1 (Provenance Engine). A service that, given a target anchor in a conversation DAG and a governance policy, produces a deterministic, cryptographically-signed context window (evidence bundle) such that: (a)~the same inputs always produce the same output (determinism); (b)~the output includes an unforgeable proof of authorization binding six provenance fields (authenticity); (c)~downstream services can verify the proof without accessing the signing secret (zero-knowledge verification); and (d)~the construction process is bounded by configurable policy parameters (governance).
skip

We formalize four invariants that any conforming provenance engine must satisfy:

- INV-001 (Determinism). For all anchors $a$, policies $\pi$, and graph states $G$: $\mathrm{slice}(a, \pi, G) = \mathrm{slice}(a, \pi, G)$.

- INV-002 (Provenance Completeness). Every output evidence bundle contains all six provenance fields: slice ID, anchor turn ID, policy ID, policy parameters hash, graph snapshot hash, and schema version.

- INV-003 (No Phantom Authority). An evidence bundle cannot exist without a valid HMAC computation. Unverified bundles are unrepresentable in the type system.

- INV-004 (Non-Escalation). A missing or invalid admissibility token implies non-admissibility. The system defaults to rejection.

The Graph Kernel is the first purpose-built implementation of this category.

Contributions

This paper makes six contributions:

- Formal provenance engine definition with four invariants and type-level enforcement via Rust's ownership system (\S[ref: sec:slicing]).

- HMAC-signed deterministic context windows with a six-field canonical binding providing 128-bit tamper resistance, verified through constant-time comparison (\S[ref: sec:hmac]).

- Policy-governed context expansion via SlicePolicyV1, a parameterized framework supporting phase-weighted priority queues, budget bounds, distance decay, and sibling expansion (\S[ref: sec:policy]).

- Native Rust entity normalization addressing a 22\

- Hybrid retrieval architecture bridging the Graph Kernel's structural reasoning with RAG++'s semantic vector search, including a server-side multi-hop traversal endpoint that eliminates the $N$-round-trip penalty (\S[ref: sec:hybrid]).

- Comprehensive evaluation and audit across 27 queries, four retrieval methods, ten comparative systems, and a 47-finding engineering audit with implemented fixes (\S[ref: sec:evaluation]--\S[ref: sec:audit]).

Paper Organization

Section~[ref: sec:related] surveys related work. Section~[ref: sec:architecture] describes the system architecture post-improvements. Section~[ref: sec:slicing] presents the deterministic context slicing model. Section~[ref: sec:normalization] details entity normalization. Section~[ref: sec:hybrid] describes the hybrid retrieval architecture. Section~[ref: sec:evaluation] reports evaluation results. Section~[ref: sec:comparative] provides comparative analysis. Section~[ref: sec:audit] discusses implementation experience from the DEP audit. Section~[ref: sec:discussion] discusses broader implications and limitations. Section~[ref: sec:roadmap] presents the evolution roadmap. Section~[ref: sec:conclusion] concludes.

Background and Related Work

Knowledge Graphs and Triple Stores

Knowledge graphs have evolved from early semantic networks~[citation: sowa1992semantic] through the modern paradigm popularized by Google's Knowledge Graph~[citation: singhal2012knowledge]. RDF-based systems like Apache Jena~[citation: jena2024] and Blazegraph~[citation: blazegraph2024] provide standards-compliant triple stores with SPARQL query interfaces and OWL-based reasoning. Property graph databases such as Neo4j~[citation: neo4j2024] and its Cypher language~[citation: francis2018cypher] offer schema-on-read flexibility. Recent surveys~[citation: ji2022survey, hogan2021knowledge, hogan2022knowledge] identify knowledge graphs as foundational to AI systems but focus on construction, completion, and embedding---not governance or provenance for agent context.

The Graph Kernel differs from these systems by being purpose-built for a narrower mandate: it is not a general-purpose knowledge representation system but a context authority layer that uses a triple store as its storage substrate. It trades query expressiveness (no SPARQL, no Cypher) for deployment simplicity (single binary, ${\sim}20$MB) and provenance guarantees (HMAC-signed bundles).

Retrieval-Augmented Generation

RAG~[citation: lewis2020rag] has become the dominant paradigm for grounding LLM outputs in external knowledge. Lewis et~al. demonstrated that combining retrieval with generation improves factual accuracy. Subsequent refinements include REALM~[citation: guu2020realm] (joint pre-training), FiD~[citation: izacard2021fid] (independent passage processing), Self-RAG~[citation: asai2024selfrag] (retrieval-time self-reflection), and CRAG~[citation: yan2024crag] (corrective retrieval). Comprehensive surveys~[citation: gao2023rag_survey, zhao2024dense] track the rapid evolution of the paradigm.

Vector databases---Weaviate~[citation: weaviate2023], Pinecone~[citation: pinecone2024], Chroma~[citation: chroma2024], Qdrant~[citation: qdrant2024], and Milvus~[citation: milvus2024]---provide the retrieval backbone, offering approximate nearest-neighbor search over dense embeddings. These systems optimize for semantic similarity but lack structural reasoning capability and provide no governance over what is retrieved.

The Graph Kernel is complementary to RAG, not competitive. Our evaluation (\S[ref: sec:evaluation]) confirms that RAG achieves 0.65 relevance on fuzzy/semantic queries where the Graph Kernel scores 0.42, while the Graph Kernel achieves 1.00 on multi-hop structural queries where RAG drops to 0.40. The hybrid architecture (\S[ref: sec:hybrid]) combines both modalities.

Graph-Enhanced RAG

Microsoft's GraphRAG~[citation: edge2024graphrag] combines LLM-driven entity extraction with the Leiden community detection algorithm~[citation: traag2019leiden] to construct hierarchical topic clusters. Queries are answered through local search (entity-centric subgraph retrieval) or global search (community summary aggregation). GraphRAG advances holistic corpus understanding but is non-deterministic by construction---its outputs depend on LLM behavior during both indexing and querying---and provides no cryptographic provenance chain.

LightRAG~[citation: guo2024lightrag] reduces the computational overhead of GraphRAG through incremental graph updates and dual-level retrieval. KG-RAG~[citation: soman2023kgrag] integrates domain-specific knowledge graphs with RAG for biomedical applications. HippoRAG~[citation: gutierrez2024hipporag] draws on hippocampal memory theory for knowledge integration. None of these systems address the provenance and determinism requirements we identify.

LlamaIndex~[citation: llamaindex2024] and LangChain~[citation: langchain2024] provide knowledge graph integrations wrapping external stores in LLM-friendly interfaces. These are orchestration layers, not graph engines; they inherit backend limitations and add LLM-dependent extraction without formal reproducibility guarantees.

Context Window Management

Managing context for LLMs has received increasing attention. Longformer~[citation: beltagy2020longformer] and BigBird~[citation: zaheer2020bigbird] extend attention to longer sequences. Memory-augmented architectures like MemoryBank~[citation: zhong2024memorybank] and RMT~[citation: bulatov2022rmt] provide external memory for conversation continuity. Zep~[citation: zep2024] offers a purpose-built memory layer with automatic entity extraction and temporal awareness. MemGPT~[citation: packer2023memgpt] introduces virtual context management through an OS-inspired paging system.

These systems optimize for the content of context windows. The Graph Kernel optimizes for the governance of context windows---who authorized inclusion, whether the window is reproducible, and whether consumers can verify provenance. These are complementary concerns.

Provenance and Trust in AI Systems

Provenance tracking in data systems has a long history~[citation: buneman2001provenance, cheney2009provenance]. The W3C PROV specification~[citation: moreau2013prov] provides a data model for provenance but lacks integration with LLM context windows. Blockchain-based provenance~[citation: liang2023blockchain] offers tamper resistance but introduces inappropriate latency. Recent work on AI auditing and accountability~[citation: amodei2016concrete, weidinger2021ethical, mitchell2019model] emphasizes the regulatory imperative for traceable AI decisions, particularly under the EU AI Act~[citation: euaiact2024] and NIST AI RMF~[citation: nist2023airisk].

The Graph Kernel's HMAC-based provenance model is inspired by JSON Web Tokens~[citation: jones2015jwt] but adapted for context window authorization: binding six provenance fields into a single unforgeable token that downstream systems verify through a dedicated endpoint.

Deterministic Systems

Deterministic replay systems~[citation: geels2007friday, laadan2010transparent] ensure that identical inputs produce identical outputs, primarily for debugging distributed systems. The Graph Kernel applies this principle to context construction: canonical sorting (BTreeMap, sorted vectors), quantized float hashing (multiply by $10^6$, round to i64), and content-derived fingerprints (xxHash64) ensure cross-platform reproducibility. This enables a property rare in AI infrastructure: exact replay of any historical context window.

System Architecture

Architecture Overview

The Graph Kernel is implemented as a single Rust binary (${\sim}15$~KLOC, ${\sim}11{,}241$ lines audited) built on Axum 0.7~[citation: axum2024] with the Tokio async runtime~[citation: tokio2024]. It compiles to a statically-linked binary (${\sim}20$MB) deployable as a local service, Docker container, or cloud function.

The architecture comprises three cleanly separated layers controlled by Cargo feature flags:

lstlisting
Feature: default -> Core library only (zero I/O)
Feature: postgres -> Adds sqlx + tokio for DB access
Feature: service -> Full HTTP service with Axum, CORS
lstlisting

This layering means the core slicing logic can be embedded as a library in other Rust crates without pulling in a web framework---a design principle validated during the DEP audit as ``exemplary'' (Architecture score: 9/10).

tikzpicture[
box/.style={draw, rounded corners, minimum width=2.2cm, minimum height=0.8cm, font=\scriptsize, align=center},
layer/.style={draw, rounded corners, minimum width=7.5cm, minimum height=2.4cm, fill=gray!5}
]
\node[layer] (service) at (0,0) {};
\node[font= \bfseries] at (0,1.5) {Graph Kernel Service (Rust, ${\sim}15$~KLOC)};

\node[box, fill=blue!10] (api) at (-2.5,0) {API Layer
(Axum 0.7)
[2pt]/api/slice
[-1pt]/api/verify
[-1pt]/api/knowledge
[-1pt]/api/traverse};
\node[box, fill=green!10] (core) at (0,0) {Core Engine
[2pt]ContextSlicer
[-1pt]PolicyRegistry
[-1pt]TokenAuthority
[-1pt]Normalizer};
\node[box, fill=orange!10] (store) at (2.5,0) {Storage Layer
[2pt]GraphStore trait
[-1pt]PostgreSQL
[-1pt](sqlx, pool 5--20)};

\draw[->, thick] (api) -- (core);
\draw[->, thick] (core) -- (store);
tikzpicture

Caption: Graph Kernel three-layer architecture with feature-flag separation.

API Layer (Axum). Route handlers expose RESTful endpoints for context slicing (POST /api/slice, POST /api/slice/batch), token verification (POST /api/verify\_token), policy management (GET/POST /api/policies), knowledge graph CRUD (GET/POST/DELETE /api/knowledge, POST /api/knowledge/batch), server-side traversal (POST /api/knowledge/traverse), and health monitoring (/health/*). All handlers enforce a 30-second configurable timeout via tower\_http::timeout::TimeoutLayer.

Core Engine. The ContextSlicer implements priority-queue BFS expansion over the conversation DAG. The PolicyRegistry maintains an immutable store of registered policies with hash-stable fingerprints. The TokenAuthority issues and verifies HMAC-SHA256 admissibility tokens. Entity normalization is enforced at the service layer through canonicalize\_entity() on all read and write paths.

Storage Layer. The GraphStore trait abstracts database access:

lstlisting[language=Rust,escapechar=|]
pub trait GraphStore {
fn get_turn(&self, id: &TurnId)
-> impl Future<Output = Result<Option<TurnSnapshot>>>
+ Send;
fn get_parents(&self, id: &TurnId)
-> impl Future<Output = Result<Vec<TurnId>>>
+ Send;
fn get_children(&self, id: &TurnId)
-> impl Future<Output = Result<Vec<TurnId>>>
+ Send;
fn get_siblings(&self, id: &TurnId, limit: usize)
-> impl Future<Output = Result<Vec<TurnId>>>
+ Send;
fn get_edges(&self, turn_ids: &[TurnId])
-> impl Future<Output = Result<Vec<Edge>>>
+ Send;
}
lstlisting

Two implementations exist: PostgresGraphStore for production (sqlx connection pool, configurable 5--20 connections, test\_before\_acquire now configurable via DB\_TEST\_BEFORE\_ACQUIRE) and InMemoryGraphStore for testing. The trait uses native Rust async traits (stabilized in Rust 1.75), having removed the async-trait proc-macro dependency during the post-audit update.

Data Model

The knowledge graph uses a triple store schema with confidence scoring and source provenance:

lstlisting[language=SQL]
CREATE TABLE knowledge_graph (
id BIGSERIAL PRIMARY KEY,
subject TEXT NOT NULL,
predicate TEXT NOT NULL,
object TEXT NOT NULL,
confidence DOUBLE PRECISION DEFAULT 0.5,
source TEXT DEFAULT 'unknown',
created_at TIMESTAMPTZ DEFAULT NOW(),
UNIQUE(subject, predicate, object)
);
CREATE INDEX idx_kg_subject ON knowledge_graph(subject);
CREATE INDEX idx_kg_predicate ON knowledge_graph(predicate);
CREATE INDEX idx_kg_object ON knowledge_graph(object);
CREATE INDEX idx_kg_confidence
ON knowledge_graph(confidence DESC);
lstlisting

The object index was added during the post-audit update (finding DM-2). On conflict (duplicate SPO), the system retains the higher confidence value and updates the source. The evaluated corpus contains 3{,}502 triples across 221 unique subjects and 88 unique predicates.

The conversation DAG schema supports the context slicing function:

lstlisting[language=SQL]
CREATE TABLE memory_turns (
id UUID PRIMARY KEY,
conversation_id UUID REFERENCES conversations(id),
parent_turn_id UUID REFERENCES memory_turns(id),
role TEXT, -- user/assistant/system
phase TEXT, -- synthesis/planning/...
content_hash TEXT, -- SHA-256
salience FLOAT, -- 0.0 - 1.0
depth INTEGER,
created_at TIMESTAMPTZ DEFAULT NOW()
);
lstlisting

Crate Structure and Type System

The crate follows a domain-driven structure with strong newtype enforcement:

- types/turn.rs --- TurnId, TurnSnapshot, Role, Phase (typed enums, not strings)

- types/slice.rs --- SliceExport, SliceFingerprint, AdmissibilityToken

- types/admissible.rs --- AdmissibleEvidenceBundle (verified wrapper)

- types/verification.rs --- TokenVerifier with LRU cache and constant-time comparison

- types/boundary.rs --- SliceBoundaryGuard, BoundedQueryBuilder

- policy/v1.rs --- SlicePolicyV1 with quantized float hashing

- service/normalize.rs --- Entity normalization with 50+ canonical entities

The codebase uses \#![warn(missing\_docs)] and \#![warn(clippy::all)] at the crate root, has zero unsafe blocks, and enforces canonical ordering via BTreeMap over HashMap and Ord implementations on all domain types.

Atlas Subsystem

The Atlas subsystem provides higher-level graph analytics: GraphSnapshot (point-in-time graph state capture), BatchSlicer (parallel slice generation), OverlapAnalyzer (pairwise overlap via Jaccard similarity), TurnInfluence (frequency, centrality, bridge scoring), and AtlasBundler (manifest packaging). This enables pre-computed structural analysis of the conversation DAG, supporting use cases like identifying bridge turns that connect otherwise-separate conversation branches.

Deterministic Context Slicing

Formal Model

The core algorithm is a policy-weighted BFS expansion from an anchor turn through the conversation DAG.

Algorithm: PolicyWeightedBFS

Input: anchor_id ∈ TurnId, policy ∈ SlicePolicyV1, store ∈ GraphStore
Output: bundle ∈ AdmissibleEvidenceBundle
anchor ← store.get_turn(anchor_id)
frontier ← MaxHeap<ExpansionCandidate>
frontier.push(anchor, d=0, p=score(anchor, policy))
selected ← [ ]; visited ← anchor_id
while frontier ≠ ∅ and |selected| < policy.max_nodes:
  c ← frontier.pop()
  if c.distance > policy.max_radius:
    continue
  selected ← selected ∪ c.turn
  for each nbr ∈ parents(c) ∪ children(c):
    if nbr ∉ visited:
      frontier.push(nbr, c.d+1, score(nbr, policy, c.d+1))
      visited ← visited ∪ nbr
  if policy.include_siblings:
    for each sib ∈ siblings(c, policy.max_sib):
      frontier.push(sib, c.d, score(sib, policy, c.d))
edges ← store.get_edges(selected)
sh ← xxHash64(sort(content_hashes(selected)))
sid ← xxHash64(anchor, sort(ids), sort(edges), pid, ph, sv)
tok ← HMAC-256(secret, canon(sid, anchor, pid, ph, sh, sv))[0:16]
return AdmissibleEvidenceBundle(selected, edges, sid, tok)

HMAC-Signed Admissibility Tokens

The admissibility token creates an unforgeable proof-of-authorization binding six provenance fields:

lstlisting
canonical = "{slice_id}|{anchor_turn_id}|
{policy_id}|{policy_params_hash}|
{graph_snapshot_hash}|{schema_version}|
admissibility_token_v2_hmac"

[sensitive field redacted], canonical)[0..16]
lstlisting

The token is a 128-bit (32 hex character) truncation of the full HMAC-SHA256 digest. Downstream services verify tokens via POST /api/verify\_token without accessing the HMAC secret. The DEP audit (finding SC-2) identified that the original constant-time comparison implementation (fold(true, |acc, (a, b)| acc \&\& (a == b))) may be optimized by LLVM into a short-circuit comparison; we recommend migration to the subtle::ConstantTimeEq crate for guaranteed timing-attack resistance.

We enforce a critical invariant at the Rust type level:

skip
INV-003 (No Phantom Authority). The AdmissibleEvidenceBundle type can only be constructed through the from\_verified() pathway, which requires a valid HMAC computation. Unverified context windows are unrepresentable in the type system.
skip

This turns security violations into compile-time errors rather than runtime bugs. No test, no refactoring, no careless modification can bypass the authorization pathway---the Rust type checker enforces it.

Policy Governance Framework

Context expansion is parameterized by SlicePolicyV1:

Caption: SlicePolicyV1 Parameters

Policies are registered in an immutable PolicyRegistry with deterministic fingerprints. Policy parameter hashes use quantized floats (multiply by $10^6$, round to i64) to ensure cross-platform determinism between Rust and Python clients. The registry itself has a composite fingerprint (xxHash64 of sorted policy hashes), enabling clients to detect policy changes.

Determinism Guarantees

Four mechanisms ensure cross-platform reproducibility:

- Canonical sorting. BTreeMap over HashMap everywhere. Turns sorted by TurnId, edges sorted by (parent\_id, child\_id). No iteration order depends on hash randomization.

- Quantized float hashing. Policy parameters are hashed as i64(float $\times$ $10^6$), avoiding IEEE~754 representation issues across platforms.

- Content-derived fingerprints. slice\_id = xxHash64(anchor, sort(turn\_ids), sort(edges), policy\_id, params\_hash, schema\_version).

- 100-run determinism tests. Golden tests verify that the same anchor + policy + graph produces byte-identical fingerprints across 100 consecutive runs.

Entity Normalization

The Problem

Our DEP audit revealed a 22\

Caption: Entity Normalization Examples

This fragmentation directly suppressed benchmark relevance: relationship queries dropped from a projected 1.00 to 0.94, and predicate-specific queries from ${\sim}0.95$+ to 0.80.

Prior Approach: Python Middleware

The initial mitigation was a Python script (scripts/entity-normalizer.py) that ran outside the Rust service boundary. This introduced three problems: (1)~Bypassability---any client calling the API directly stored un-normalized entities; (2)~Inconsistency---normalization rules existed in Python, not where data was validated; (3)~Maintenance burden---two codebases needed to agree on canonicalization.

Rust Implementation

The post-audit update moved entity normalization into the Rust service as a normalize module (280 lines):

lstlisting[language=Rust]
static ALIAS_TABLE: LazyLock<HashMap<&str, &str>> =
LazyLock::new(|| {
let mut m = HashMap::new();
m.insert("dream weaver", "dream-weaver-engine");
m.insert("gcp", "google-cloud-platform");
// ... 300+ aliases across 50+ entities
m
});

pub fn canonicalize_entity(name: &str) -> String {
let normalized = name.trim().to_lowercase()
.replace(|c: char|
c.is_ascii_punctuation() && c != '-', " ")
.split_whitespace().collect::<Vec<_>>().join("-");
ALIAS_TABLE.get(normalized.as_str())
.map(|s| s.to_string())
.unwrap_or(normalized)
}
lstlisting

Normalization is enforced on all data paths: add\_knowledge\_handler, add\_knowledge\_batch\_handler, query\_knowledge\_handler, delete\_knowledge\_handler, and traverse\_knowledge\_handler. The module includes 16 unit tests covering known entities, unknown entities, empty strings, mixed case, and punctuation variants.

Impact

Caption: Entity Normalization Impact

Hybrid Retrieval Architecture

The Complementarity Thesis

The Graph Kernel and RAG++ occupy complementary niches in the retrieval landscape:

Caption: Graph Kernel vs. RAG++ Comparison

Neither system alone addresses the full retrieval needs of an autonomous agent. The hybrid architecture combines both.

RAG++ System Architecture

RAG++ consists of two Rust crates (rag-plusplus-core at ${\sim}26$~KLOC, rag-plusplus-py with PyO3 bindings) and a Python FastAPI service at port 8000. The core library implements:

- Index types. FlatIndex (brute-force, $O(n)$), HNSWIndex (hierarchical navigable small worlds, $O(\log n)$), ParallelHNSW (rayon-parallel construction), BM25Index (sparse keyword retrieval).

- Hybrid search. Score fusion via Reciprocal Rank Fusion (RRF), CombSUM, and CombMNZ across dense and sparse retrievers.

- Re-ranking. Five strategies---None, OutcomeWeighted, Recency, MMR (Maximal Marginal Relevance), and Composite---with configurable weights.

- Trajectory memory. A 5D coordinate system (depth, sibling\_order, homogeneity, temporal, complexity) enabling trajectory-weighted distance computation.

The DEP audit of RAG++ (7.2/10) identified a critical deployment gap: the algorithms for high relevance (hybrid BM25 fusion, re-ranking, query expansion) exist in the Rust core but were not wired through to the deployed FastAPI service. Activating existing algorithms is projected to raise relevance from 0.70 to 0.90+.

Server-Side Multi-Hop Traversal

The most impactful improvement from the post-audit update: a server-side traversal endpoint that eliminates the $N$-round-trip penalty for multi-hop queries.

lstlisting
POST /api/knowledge/traverse
{
"start": "clawdbot",
"predicates": ["uses", "depends_on"],
"direction": "outgoing",
"max_hops": 3,
"max_results": 100,
"min_confidence": 0.5
}
lstlisting

The endpoint performs BFS traversal within a single database connection, returning full paths with entities, edges, hop counts, and minimum confidence per path. Entity normalization is applied to the start entity. The traversal is bounded by max\_hops (default~3) and max\_results (default~100) to prevent unbounded expansion.

Impact: A 3-hop query drops from ${\sim}874$ms (3 sequential HTTP round-trips $\times$ ${\sim}291$ms each) to a single round-trip (${\sim}291$ms remote, projected ${\sim}15$ms with local SQLite).

Enrichment Bridge Design

The planned enrichment endpoint (POST /api/enrich) accepts RAG++ semantic results and augments them with graph context:

- RAG++ returns top-$K$ semantically similar turns for a query.

- For each result, entities are extracted from the result text.

- Extracted entities are resolved to Graph Kernel subjects via canonicalize\_entity().

- The server-side traversal retrieves 1--2 hop neighborhoods for resolved entities.

- Results are re-ranked using a combined score: $\text{semantic\_score} \times \alpha + \text{structural\_score} \times (1 - \alpha)$.

- The enriched result set preserves provenance metadata from both sources.

tikzpicture[
box/.style={draw, rounded corners, minimum width=2.8cm, minimum height=1.2cm, font=\scriptsize, align=center},
merge/.style={draw, rounded corners, minimum width=3.2cm, minimum height=0.9cm, font=\scriptsize, align=center, fill=yellow!15}
]
\node[box, fill=blue!10] (rag) at (-1.8,1.5) {RAG++ (Semantic)
Vector embedding
$\rightarrow$ similarity
$\rightarrow$ top-$K$ turns};
\node[box, fill=green!10] (gk) at (1.8,1.5) {Graph Kernel
(Structural)
Subject/predicate
$\rightarrow$ exact triples};
\node[merge] (merge) at (0,0) {Merge \& Rank
Deduplicate $\cdot$ Cross-enrich
Provenance-tag};
\node[font=\scriptsize\itshape] (out) at (0,-1) {Enriched Result Set};

\draw[->, thick] (rag) -- (merge);
\draw[->, thick] (gk) -- (merge);
\draw[->, thick] (merge) -- (out);
tikzpicture

Caption: Hybrid retrieval architecture combining semantic and structural search with provenance tagging.

Evaluation

Methodology

We evaluated four retrieval methods across 27 queries in five categories:

Caption: Query Categories

Methods under test:

Caption: Retrieval Methods

Important caveat. The Graph Kernel, keyword, and BM25 operate on the same triple corpus. RAG++ operates on a fundamentally different and much larger corpus. Direct comparison is informational, not apples-to-apples.

Metrics. Response time (ms, wall-clock with network), result count, and relevance score (0--1, fraction of expected terms found).

Environment. MacBook Air (Apple M3, arm64), Darwin 24.6.0, Graph Kernel v0.1.0 (Rust), RAG++ v0.1.0 (Python FastAPI), Supabase PostgreSQL (remote, us-east-1), ${\sim}200$ms RTT.

Results

Factual Recall

Caption: Factual Recall Results

All triple-based methods achieve perfect relevance. The Graph Kernel returns precisely scoped results (3.7 average) versus keyword's broader 20.0, reflecting exact field matching versus substring coincidence.

Relationship Queries

Caption: Relationship Query Results

The 0.94 is attributable to a single entity normalization failure: ``GCP'' not matching ``Google Cloud Platform.'' With the Rust normalizer now deployed, this projects to 1.00.

Multi-hop Reasoning

Caption: Multi-hop Reasoning Results

Multi-hop is the Graph Kernel's distinguishing capability. While keyword and BM25 achieve identical 1.00 scores, the nature of their results differs fundamentally:

- Graph Kernel returns 7.6 structurally connected results forming verified relationship chains (e.g., Mohamed $\rightarrow$ works\_on $\rightarrow$ clawdbot $\rightarrow$ uses $\rightarrow$ Gemini batch API).

- Keyword returns 20.0 coincidence results---documents containing matching substrings with no concept of why the terms co-occur.

The relevance metric masks this quality difference. With the server-side traversal endpoint, multi-hop latency drops from ${\sim}587$ms to a single request (${\sim}291$ms remote, projected ${\sim}15$ms local).

Fuzzy/Semantic Search

Caption: Fuzzy/Semantic Search Results

The Graph Kernel's weakest category, confirming the expected limitation of exact field matching. This is the primary motivation for the hybrid architecture (\S[ref: sec:hybrid]).

Predicate-Specific Queries

Caption: Predicate-Specific Query Results

Entity normalization failures suppress relevance from projected 0.95+ to 0.80. The Rust normalizer addresses this.

Overall Summary

Caption: Overall Results Summary

Latency Decomposition

Caption: Latency Decomposition

Critical insight. The Graph Kernel is compute-efficient (${\sim}1$--2ms of Rust processing). Its latency problem is an architecture choice (remote Supabase), not a fundamental limitation. Migration to local SQLite reduces query latency by 20$\times$, making it competitive with BM25.

Comparative Analysis

System Comparison

We compare the Graph Kernel against ten systems across seven dimensions.

Caption: Comparative Analysis: Graph Kernel vs. Industry Alternatives

Detailed Findings

No existing system provides deterministic context slicing with cryptographic provenance. To replicate the Graph Kernel's core capability with Neo4j, one would need to build a custom application layer implementing BFS expansion with priority scoring, HMAC token issuance, deterministic fingerprinting, policy registry management, and type-level verification enforcement---essentially re-implementing the Graph Kernel on top of a more complex substrate.

General-purpose graph databases offer superior query expressiveness and scale. Neo4j (Cypher), Neptune (SPARQL/Gremlin/openCypher), Jena (SPARQL), and TypeDB (TypeQL) provide significantly more expressive query languages. For complex graph pattern matching, recursive path queries, or billion-scale traversal, these systems are superior. The Graph Kernel does not compete on this axis, and the DEP audit confirmed this as an acceptable trade-off (Scale score: 6/10).

Vector databases address the Graph Kernel's primary weakness. Weaviate's hybrid search and GraphRAG's community-level understanding directly address the 0.42 fuzzy/semantic relevance. The hybrid architecture (\S[ref: sec:hybrid]) bridges this gap.

LLM-dependent systems are non-deterministic by construction. GraphRAG and LangChain/LlamaIndex knowledge graphs depend on LLM behavior for both indexing and querying, which varies across model versions, temperatures, and infrastructure. The Graph Kernel's determinism guarantee---same input, same output---is fundamentally incompatible with LLM-in-the-loop systems.

Memory-oriented systems sacrifice determinism for developer experience. Zep provides automatic entity extraction and temporal memory decay but offers no formal reproducibility. The same query at different times may return different results. For auditability-critical applications, this is a significant limitation.

Positioning

The Graph Kernel occupies a distinct niche: the provenance authority layer for autonomous agent systems. It does not compete with Neo4j on expressiveness, Neptune on scale, Weaviate on semantic search, or GraphRAG on holistic understanding. Its value proposition is:

quote
Given a target turn, which other turns are allowed to influence meaning---and can you prove it?
quote

Implementation Experience: Lessons from the DEP Audit

Audit Overview

We subjected the Graph Kernel to a Deep Engineering Posture (DEP) assessment covering 12 dimensions with 47 specific findings. The audit scored the system 7.4/10 (``production-viable with clear improvement paths'') and identified critical improvements across performance, data integrity, security, and operational concerns.

Critical Fixes Implemented

Entity Normalization in Rust (DM-1, BG-1). The highest-impact fix. Moving normalization from a bypassable Python middleware into the Rust service as a normalize.rs module with 50+ canonical entities and 300+ alias variants, enforced on all read and write paths. This addresses the 22\

SQL Injection Risk Mitigation (AR-1, BG-3). The knowledge graph query handler used dynamic string formatting for SQL WHERE clauses. We migrated all query parameters to bind variables (\$N parameters), eliminating all string interpolation in SQL construction.

Server-Side Traversal (MF-1). The highest-priority missing feature: multi-hop queries previously required $N$ sequential HTTP round-trips. The new POST /api/knowledge/traverse endpoint performs BFS within a single database connection, bounded by max\_hops and max\_results.

Connection Pool Optimization (PF-4, PF-5). test\_before\_acquire (which added a SELECT 1 round-trip before every connection checkout) is now configurable via DB\_TEST\_BEFORE\_ACQUIRE (default: false). min\_connections increased from 2 to 5 for faster burst response.

Pagination Fix (BG-2). The total field in knowledge query responses returned page count instead of the actual matching count. Fixed with a separate SELECT COUNT(*) query.

DELETE Endpoint (MF-7, DM-5). Added DELETE /api/knowledge with safety guards (requires at least one filter to prevent full-table deletion).

Request Timeout (OP-3). Added tower\_http::timeout::TimeoutLayer with a 30-second configurable default.

Dependency Cleanup (DP-1). Removed async-trait proc-macro in favor of native Rust 1.75+ async trait syntax.

Known Limitations Remaining

- No SQLite backend (Evo 1.1). The GraphStore trait abstraction makes this clean---estimated 2 weeks. Would reduce latency by 20$\times$.

- No query caching (PF-1). Identical queries hit the database every time.

- Development HMAC secret fallback (SC-1). Should be a hard failure in production.

- CORS allows any origin (SC-4). Acceptable for development only.

- No Prometheus metrics (OP-1). Metrics are log-based only.

- Scale uncertainty. Tested with ${\sim}3{,}500$ triples; behavior at 100K+ untested.

What the Audit Validated

The DEP audit validated several architectural decisions:

- Feature-gated layering (Architecture: 9/10) --- the ability to compile three different profiles was called ``exemplary.''

- Type-driven security (Security: 9/10) --- the AdmissibleEvidenceBundle pattern was described as ``the strongest security implementation I've seen in a sub-15KLOC codebase.''

- Documentation density (Documentation: 9/10) --- noted as exceeding most 100K-line projects.

- Zero unsafe blocks (Code Quality: 8/10) --- the entire codebase uses safe Rust.

Discussion

The Provenance Gap in AI Infrastructure

Our evaluation reveals a significant gap: no widely-deployed system provides deterministic, cryptographically-verifiable context windows for autonomous agents. This is not because the need is unrecognized---the AI safety community has extensively discussed auditable AI~[citation: amodei2016concrete, weidinger2021ethical]---but because the infrastructure has not been built.

The Graph Kernel addresses this gap by making provenance a first-class architectural concern. The AdmissibleEvidenceBundle type, the HMAC-signed admissibility token, and the policy governance framework together ensure that every context window carries a complete provenance chain.

Formal Properties of the Provenance Engine Category

A provenance engine satisfying our four invariants provides three emergent properties:

Regulatory compliance. As AI regulation evolves (EU AI Act~[citation: euaiact2024], NIST AI RMF~[citation: nist2023airisk]), the ability to audit which information influenced an agent's decision becomes a compliance requirement.

Multi-agent trust. In systems where multiple agents collaborate, provenance tokens enable trust delegation: Agent A can verify that Agent B's context window was authorized by a shared policy authority without accessing the authority's signing secret.

Deterministic debugging. When an agent produces an unexpected output, deterministic context slicing enables exact reproduction of input conditions---same anchor, same policy, same graph state yields the same context window.

Limitations

No semantic search capability. The Graph Kernel achieves 0.42 average relevance on fuzzy/semantic queries. This is a fundamental limitation of exact field matching and motivates the hybrid architecture (\S[ref: sec:hybrid]).

Scale constraints. The evaluated corpus contains 3{,}502 triples. For billion-scale applications, purpose-built distributed databases remain necessary.

Relevance metric limitations. Our relevance metric does not capture structural quality. As demonstrated in \S[ref: sec:evaluation], keyword search and Graph Kernel can achieve identical 1.00 relevance while producing qualitatively different results (coincidence piles vs. causal chains). Future work should incorporate structural metrics: chain validity, provenance completeness, and causal coherence.

Single-user scope. The current system serves a single user's knowledge graph. Federation requires the protocol extensions described in \S[ref: sec:roadmap].

HMAC key management. No key rotation mechanism exists. Key versioning with dual-key verification is needed for production deployments.

RAG++ deployment gap. The RAG++ Rust core contains sophisticated algorithms but the deployed FastAPI service uses vector-only search, explaining the 0.70 relevance. Activating existing algorithms is projected to raise relevance to 0.90+.

Evolution Roadmap

Evolution 1: Optimization (3.5 weeks)

SQLite Backend Migration. Implement SqliteGraphStore as a native Rust backend using SQLite with WAL mode. Reads from local SQLite (${\sim}5$ms), writes propagate to Supabase asynchronously. Projected latency improvement: 291ms $\rightarrow$ 5--15ms. Feature-gated via sqlite Cargo feature.

Query Caching. LRU cache keyed on query parameters with TTL-based invalidation, using existing lru + parking\_lot infrastructure.

Activate RAG++ Hybrid Search. Wire existing HybridQueryEngine and Reranker through to FastAPI endpoints. Default: RRF fusion ($k{=}60$) of HNSW + BM25. Projected RAG++ relevance: 0.70 $\rightarrow$ 0.90+.

Projected DEP score after Evo 1: 8.6/10 (+1.2).

Evolution 2: Expansion (4 weeks)

WebSocket Subscriptions. Real-time push notifications when triples are created, updated, or deleted. Using Axum's built-in WebSocket support with tokio::sync::broadcast.

Graph Visualization Endpoint. GET /api/knowledge/graph returning D3-compatible JSON, Mermaid syntax, or Graphviz DOT format. Reuses the server-side traversal with output rendering.

Temporal Versioning. valid\_from and valid\_until columns on triples, with supersession tracking. Enables temporal queries and knowledge lifecycle management.

Community Detection. Louvain/Leiden algorithm over the knowledge graph topology to identify hierarchical entity clusters.

Projected DEP score after Evo 2: 9.1/10 (+0.5).

Evolution 3: Transformation (3--6 months)

Federated Graph Kernel. Multiple Graph Kernel instances (per-user, per-team) share and merge knowledge while preserving provenance boundaries. Federation tokens extend the HMAC model to multi-party verification.

Universal Context Authority. Framework-agnostic context API accepting requests from any agent system (LangChain, CrewAI, AutoGen, custom). Token budget-aware context construction with pluggable output formats.

Graph Kernel SDK. First-party client libraries for Rust, Python (pip install graph-kernel), and JavaScript/TypeScript (npm install @openclaw/graph-kernel).

W3C PROV-DM Integration. Map the Graph Kernel's provenance model to W3C PROV~[citation: moreau2013prov], enabling export to PROV-compliant systems.

Graph Kernel Protocol (GKP/1). Open protocol specification for provenance-governed context authorities with conformance test suite.

Graph Kernel Cloud. Multi-tenant managed service with per-tenant SQLite isolation, JWT authentication, and usage-based billing.

Conclusion

We have presented the Graph Kernel, a deterministic provenance engine that introduces a new category of infrastructure for autonomous AI agent systems. Through evaluation across 27 queries and four retrieval methods, we demonstrate that it achieves perfect relevance on multi-hop structural queries while providing properties no existing system offers: HMAC-signed deterministic context windows, type-level admissibility enforcement, and policy-governed context expansion.

The DEP audit process proved valuable: systematic assessment across 12 engineering dimensions identified 47 specific findings, of which 10 critical fixes were implemented, raising the projected health score from 7.4 to 8.4/10. The most impactful improvements---native Rust entity normalization, server-side multi-hop traversal, and parameterized SQL queries---addressed real correctness and performance issues that would have affected production reliability.

The hybrid architecture with RAG++ demonstrates that the provenance engine is not a replacement for semantic retrieval but a complementary layer. Where RAG++ finds what sounds relevant, the Graph Kernel proves what is structurally connected and authorized. Together, they provide the semantic-plus-structural retrieval backbone that consequential agent decisions require.

The Graph Kernel is not a general-purpose search engine (0.84 overall relevance vs. keyword's 0.96), nor a general-purpose graph database (REST filters vs. Cypher/SPARQL), nor a semantic retrieval system (0.42 fuzzy relevance). It is a provenance engine---and in that role, among the eleven systems we evaluated, it is irreplaceable.

As autonomous AI agents assume greater responsibility in production systems, the infrastructure to ensure their decisions are traceable, reproducible, and verifiable becomes not optional but essential. The Graph Kernel, and the provenance engine category it establishes, is a step toward that infrastructure.

\appendices

Reproducibility Statement

All benchmark scripts, raw results, and evaluation code are available in the OpenClaw CompCore repository at benchmarks/run\_benchmark.py. The Graph Kernel binary can be compiled from source with cargo build --release --features service. The evaluation corpus (3{,}502 triples) is stored in the Supabase PostgreSQL instance; a SQLite snapshot is maintained at \texttt{\~{}/.compcore/graph-kernel.db}. Complete benchmark results in JSON format are archived at /tmp/benchmark\_results.json. The codebase compiles cleanly with all 29 tests passing (14 atlas integration, 13 golden determinism, 2 doc tests).

Corpus Statistics

Caption: Corpus Statistics

DEP Audit Score Summary

Caption: DEP Audit Scores by Dimension

Post-fix projected score: 8.4/10.

Post-Audit Changes Summary

Caption: Post-Audit Implementation Status

References

- [vaswani2017attention]
A.~Vaswani, N.~Shazeer, N.~Parmar, J.~Uszkoreit, L.~Jones, A.~N.~Gomez, \L.~Kaiser, and I.~Polosukhin, ``Attention is all you need,'' in Advances in Neural Information Processing Systems (NeurIPS), vol.~30, 2017.

- [weaviate2023]
B.~Mohr, E.~Bueno~de~Mesquita, and S.~van~Cranenburgh, ``Weaviate: An open-source vector database,'' 2023. [Online]. Available: https://weaviate.io

- [johnson2021billion]
J.~J.~Johnson, M.~Douze, and H.~J\'{e}gou, ``Billion-scale similarity search with GPUs,'' IEEE Transactions on Big Data, vol.~7, no.~3, pp.~535--547, 2021.

- [lewis2020rag]
P.~Lewis et~al., ``Retrieval-augmented generation for knowledge-intensive NLP tasks,'' in NeurIPS, vol.~33, 2020, pp.~9459--9474.

- [gao2023rag_survey]
Y.~Gao et~al., ``Retrieval-augmented generation for large language models: A survey,'' arXiv:2312.10997, 2023.

- [neo4j2024]
Neo4j, Inc., ``Neo4j Graph Database,'' 2024. [Online]. Available: https://neo4j.com

- [angles2017foundations]
R.~Angles, M.~Arenas, P.~Barcel\'{o}, A.~Hogan, J.~Reutter, and D.~Vrgoc, ``Foundations of modern query languages for graph databases,'' ACM Computing Surveys, vol.~50, no.~5, pp.~1--40, 2017.

- [zep2024]
Zep, ``Zep: Long-term memory for AI assistants,'' 2024. [Online]. Available: https://www.getzep.com

- [sowa1992semantic]
J.~F.~Sowa, ``Semantic networks,'' in Encyclopedia of Artificial Intelligence, 2nd~ed., S.~C.~Shapiro, Ed. Wiley, 1992.

- [singhal2012knowledge]
A.~Singhal, ``Introducing the Knowledge Graph: Things, not strings,'' Google Official Blog, May 2012.

- [jena2024]
Apache Software Foundation, ``Apache Jena,'' 2024. [Online]. Available: https://jena.apache.org

- [blazegraph2024]
Blazegraph, ``Blazegraph Database,'' 2024. [Online]. Available: https://blazegraph.com

- [francis2018cypher]
N.~Francis et~al., ``Cypher: An evolving query language for property graphs,'' in SIGMOD, 2018, pp.~1433--1445.

- [ji2022survey]
S.~Ji, S.~Pan, E.~Cambria, P.~Marttinen, and P.~S.~Yu, ``A survey on knowledge graphs: Representation, acquisition, and applications,'' IEEE Trans. NNLS, vol.~33, no.~2, pp.~494--514, 2022.

- [hogan2021knowledge]
A.~Hogan et~al., ``Knowledge graphs,'' ACM Computing Surveys, vol.~54, no.~4, pp.~1--37, 2021.

- [hogan2022knowledge]
A.~Hogan et~al., ``Knowledge graphs,'' Synthesis Lectures on Data, Semantics, and Knowledge, Morgan \& Claypool, 2022.

- [guu2020realm]
K.~Guu, K.~Lee, Z.~Tung, P.~Pasupat, and M.-W.~Chang, ``Retrieval augmented language model pre-training,'' in ICML, 2020, pp.~3929--3938.

- [izacard2021fid]
G.~Izacard and E.~Grave, ``Leveraging passage retrieval with generative models for open domain question answering,'' in EACL, 2021, pp.~874--880.

- [asai2024selfrag]
A.~Asai, Z.~Wu, Y.~Wang, A.~Sil, and H.~Hajishirzi, ``Self-RAG: Learning to retrieve, generate, and critique through self-reflection,'' in ICLR, 2024.

- [yan2024crag]
S.-C.~Yan, S.-W.~Gu, L.-Y.~Wu, and S.~Singh, ``Corrective retrieval augmented generation,'' arXiv:2401.15884, 2024.

- [zhao2024dense]
W.~X.~Zhao, J.~Liu, R.~Ren, and J.-R.~Wen, ``Dense text retrieval based on pretrained language models: A survey,'' ACM Computing Surveys, vol.~56, no.~9, 2024.

- [pinecone2024]
Pinecone Systems, ``Pinecone: Vector Database for Machine Learning,'' 2024. [Online]. Available: https://www.pinecone.io

- [chroma2024]
Chroma, ``Chroma: The AI-native open-source embedding database,'' 2024. [Online]. Available: https://www.trychroma.com

- [qdrant2024]
Qdrant, ``Qdrant: Vector similarity search engine,'' 2024. [Online]. Available: https://qdrant.tech

- [milvus2024]
Milvus, ``Milvus: Open-source vector database for AI,'' 2024. [Online]. Available: https://milvus.io

- [edge2024graphrag]
D.~Edge et~al., ``From local to global: A graph RAG approach to query-focused summarization,'' arXiv:2404.16130, 2024.

- [traag2019leiden]
V.~A.~Traag, L.~Waltman, and N.~J.~van~Eck, ``From Louvain to Leiden: Guaranteeing well-connected communities,'' Scientific Reports, vol.~9, p.~5233, 2019.

- [guo2024lightrag]
Z.~Guo, L.~Shang, J.~Jiang, and J.~X.~Huang, ``LightRAG: Simple and fast retrieval-augmented generation,'' arXiv:2410.05779, 2024.

- [soman2023kgrag]
A.~Soman, P.~G.~Bhat, V.~Barber, and S.~Iyengar, ``Biomedical knowledge graph-enhanced prompt generation for large language models,'' arXiv:2311.17330, 2023.

- [gutierrez2024hipporag]
B.~Guti\'{e}rrez, Y.~Yang, H.~Gu, M.~Sami, and Y.~Su, ``HippoRAG: Neurobiologically inspired long-term memory for large language models,'' in NeurIPS, 2024.

- [llamaindex2024]
J.~Liu, ``LlamaIndex: A data framework for LLM applications,'' 2024. [Online]. Available: https://www.llamaindex.ai

- [langchain2024]
H.~Chase, ``LangChain,'' 2024. [Online]. Available: https://www.langchain.com

- [beltagy2020longformer]
I.~Beltagy, M.~E.~Peters, and A.~Cohan, ``Longformer: The long-document transformer,'' arXiv:2004.05150, 2020.

- [zaheer2020bigbird]
M.~Zaheer et~al., ``Big Bird: Transformers for longer sequences,'' in NeurIPS, vol.~33, 2020, pp.~17283--17297.

- [zhong2024memorybank]
W.~Zhong, L.~Guo, Q.~Gao, H.~Ye, and Y.~Wang, ``MemoryBank: Enhancing large language models with long-term memory,'' in AAAI, vol.~38, 2024.

- [bulatov2022rmt]
A.~Bulatov, Y.~Kuratov, and M.~S.~Burtsev, ``Recurrent memory transformer,'' in NeurIPS, vol.~35, 2022, pp.~11079--11091.

- [packer2023memgpt]
C.~Packer, S.~Wooders, K.~Lin, V.~Fang, S.~Patil, I.~Stoica, and J.~E.~Gonzalez, ``MemGPT: Towards LLMs as operating systems,'' arXiv:2310.08560, 2023.

- [buneman2001provenance]
P.~Buneman, S.~Khanna, and W.-C.~Tan, ``Why and where: A characterization of data provenance,'' in ICDT, 2001, pp.~316--330.

- [cheney2009provenance]
J.~Cheney, L.~Chiticariu, and W.-C.~Tan, ``Provenance in databases: Why, how, and where,'' Found. Trends Databases, vol.~1, no.~4, pp.~379--474, 2009.

- [moreau2013prov]
L.~Moreau, P.~Missier, et~al., ``PROV-DM: The PROV Data Model,'' W3C Recommendation, 2013. [Online]. Available: https://www.w3.org/TR/prov-dm/

- [liang2023blockchain]
R.~Liang, C.~Niu, F.~Zhang, Z.~Qi, and Y.~Hao, ``Blockchain-based data provenance for AI: A comprehensive survey,'' IEEE Access, vol.~11, pp.~61748--61770, 2023.

- [amodei2016concrete]
D.~Amodei et~al., ``Concrete problems in AI safety,'' arXiv:1606.06565, 2016.

- [weidinger2021ethical]
S.~Weidinger et~al., ``Ethical and social risks of harm from language models,'' arXiv:2112.04359, 2021.

- [mitchell2019model]
M.~Mitchell et~al., ``Model cards for model reporting,'' in FAccT, 2019, pp.~220--229.

- [euaiact2024]
European Parliament, ``Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act),'' Official Journal of the European Union, 2024.

- [nist2023airisk]
National Institute of Standards and Technology, ``AI Risk Management Framework (AI RMF 1.0),'' NIST AI 100-1, January 2023.

- [jones2015jwt]
M.~Jones, J.~Bradley, and N.~Sakimura, ``JSON Web Token (JWT),'' RFC~7519, IETF, 2015.

- [geels2007friday]
D.~Geels, G.~Altekar, P.~Maniatis, T.~Roscoe, and I.~Stoica, ``Friday: Global comprehension for distributed replay,'' in NSDI, 2007, pp.~285--298.

- [laadan2010transparent]
O.~Laadan, N.~Viennot, and J.~Nieh, ``Transparent, lightweight application execution replay on commodity multiprocessor operating systems,'' in SIGMETRICS, 2010, pp.~155--166.

- [axum2024]
D.~Tolnay et~al., ``Axum: Ergonomic and modular web framework built with Tokio,'' 2024. [Online]. Available: https://github.com/tokio-rs/axum

- [tokio2024]
C.~Lerche et~al., ``Tokio: An asynchronous runtime for Rust,'' 2024. [Online]. Available: https://tokio.rs

- [neptune2024]
Amazon Web Services, ``Amazon Neptune,'' 2024. [Online]. Available: https://aws.amazon.com/neptune/

- [dgraph2024]
Dgraph Labs, ``Dgraph: Distributed graph database,'' 2024. [Online]. Available: https://dgraph.io

- [typedb2024]
Vaticle, ``TypeDB: The polymorphic database,'' 2024. [Online]. Available: https://typedb.com

- [petroni2019language]
F.~Petroni et~al., ``Language models as knowledge bases?'' in EMNLP-IJCNLP, 2019, pp.~2463--2473.

- [jiang2020know]
Z.~Jiang, F.~F.~Xu, J.~Araki, and G.~Neubig, ``How can we know what language models know?'' TACL, vol.~8, pp.~423--438, 2020.

- [wei2022chain]
J.~Wei et~al., ``Chain-of-thought prompting elicits reasoning in large language models,'' in NeurIPS, vol.~35, 2022, pp.~24824--24837.

- [schick2024toolformer]
T.~Schick et~al., ``Toolformer: Language models can teach themselves to use tools,'' in NeurIPS, vol.~36, 2024.

- [yao2023react]
S.~Yao et~al., ``ReAct: Synergizing reasoning and acting in language models,'' in ICLR, 2023.

- [shinn2024reflexion]
N.~Shinn, F.~Cassano, A.~Gopinath, K.~R.~Narasimhan, and S.~Yao, ``Reflexion: Language agents with verbal reinforcement learning,'' in NeurIPS, vol.~36, 2024.