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

Mohamed Diomande
OpenClaw Research
Brooklyn, NY, USA
[email]

---

> Manuscript Type: Full Research Paper (V2 — Post-Audit Definitive Edition)
> Track: AI Systems & Knowledge Infrastructure
> Date: July 2026
> Revision: 2.0 — Incorporates DEP Audit findings, Evo³ roadmap, and implemented improvements

---

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 (~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 (~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.

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

---

1. Introduction

1.1 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 [1] — 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 [2, 3], not RAG pipelines [4, 5], not general-purpose graph databases [6, 7], not memory layers [8] — addresses these requirements as first-class concerns. They optimize for relevance, latency, or scale, but not for provenance.

1.2 The Provenance Engine Category

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

> 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).

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

• INV-001 (Determinism). For all anchors a, policies π, and graph states G: slice(a, π, G) = slice(a, π, 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.

1.3 Contributions

This paper makes six contributions:

1. Formal provenance engine definition with four invariants and type-level enforcement via Rust's ownership system (§4).

2. HMAC-signed deterministic context windows with a six-field canonical binding providing 128-bit tamper resistance, verified through constant-time comparison (§4.2).

3. Policy-governed context expansion via `SlicePolicyV1`, a parameterized framework supporting phase-weighted priority queues, budget bounds, distance decay, and sibling expansion (§4.3).

4. Native Rust entity normalization addressing a 22

5. 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 (§6).

6. Comprehensive evaluation and audit across 27 queries, four retrieval methods, ten comparative systems, and a 47-finding engineering audit with implemented fixes (§7–§9).

1.4 Paper Organization

Section 2 surveys related work. Section 3 describes the system architecture post-improvements. Section 4 presents the deterministic context slicing model. Section 5 details entity normalization. Section 6 describes the hybrid retrieval architecture. Section 7 reports evaluation results. Section 8 provides comparative analysis. Section 9 discusses implementation experience from the DEP audit. Section 10 discusses broader implications and limitations. Section 11 presents the evolution roadmap. Section 12 concludes.

---

2. Background and Related Work

2.1 Knowledge Graphs and Triple Stores

Knowledge graphs have evolved from early semantic networks [9] through the modern paradigm popularized by Google's Knowledge Graph [10]. RDF-based systems like Apache Jena [11] and Blazegraph [12] provide standards-compliant triple stores with SPARQL query interfaces and OWL-based reasoning. Property graph databases such as Neo4j [6] and its Cypher language [13] offer schema-on-read flexibility. Recent surveys [14, 15, 16] 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, ~20MB) and provenance guarantees (HMAC-signed bundles).

2.2 Retrieval-Augmented Generation

RAG [4] 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 [17] (joint pre-training), FiD [18] (independent passage processing), Self-RAG [19] (retrieval-time self-reflection), and CRAG [20] (corrective retrieval). Comprehensive surveys [5, 21] track the rapid evolution of the paradigm.

Vector databases — Weaviate [2], Pinecone [22], Chroma [23], Qdrant [24], and Milvus [25] — 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 (§7) 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 (§6) combines both modalities.

2.3 Graph-Enhanced RAG

Microsoft's GraphRAG [26] combines LLM-driven entity extraction with the Leiden community detection algorithm [27] 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 [28] reduces the computational overhead of GraphRAG through incremental graph updates and dual-level retrieval. KG-RAG [29] integrates domain-specific knowledge graphs with RAG for biomedical applications. HippoRAG [30] draws on hippocampal memory theory for knowledge integration. None of these systems address the provenance and determinism requirements we identify.

LlamaIndex [31] and LangChain [32] 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.

2.4 Context Window Management

Managing context for LLMs has received increasing attention. Longformer [33] and BigBird [34] extend attention to longer sequences. Memory-augmented architectures like MemoryBank [35] and RMT [36] provide external memory for conversation continuity. Zep [8] offers a purpose-built memory layer with automatic entity extraction and temporal awareness. MemGPT [37] 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.

2.5 Provenance and Trust in AI Systems

Provenance tracking in data systems has a long history [38, 39]. The W3C PROV specification [40] provides a data model for provenance but lacks integration with LLM context windows. Blockchain-based provenance [41] offers tamper resistance but introduces inappropriate latency. Recent work on AI auditing and accountability [42, 43, 44] emphasizes the regulatory imperative for traceable AI decisions, particularly under the EU AI Act [45] and NIST AI RMF [46].

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

2.6 Deterministic Systems

Deterministic replay systems [48, 49] 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⁶, 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.

---

3. System Architecture

3.1 Architecture Overview

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

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

Feature: default    → Core library only (zero I/O, no async runtime)
Feature: postgres   → Adds sqlx + tokio for database access
Feature: service    → Full HTTP service with Axum, CORS, tracing

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).

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:

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;
    fn is_healthy(&self) -> bool;
    fn pool_stats(&self) -> PoolStats;
}

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.

3.2 Data Model

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

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_knowledge_subject ON knowledge_graph(subject);
CREATE INDEX idx_knowledge_predicate ON knowledge_graph(predicate);
CREATE INDEX idx_knowledge_object ON knowledge_graph(object);
CREATE INDEX idx_knowledge_confidence ON knowledge_graph(confidence DESC);

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:

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', 'consolidation', 'debugging', 'exploration'
    content_hash      TEXT,    -- SHA-256 of normalized content
    salience          FLOAT,   -- 0.0 - 1.0
    depth             INTEGER,
    created_at        TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE edges (
    id              UUID PRIMARY KEY,
    parent_turn_id  UUID REFERENCES memory_turns(id),
    child_turn_id   UUID REFERENCES memory_turns(id),
    edge_type       TEXT    -- 'reply', 'branch', 'merge'
);

3.3 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, construction restricted)
• `types/verification.rs` — `TokenVerifier` with LRU cache and constant-time comparison
• `types/boundary.rs` — `SliceBoundaryGuard`, `BoundedQueryBuilder` (SQL injection prevention)
• `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.

3.4 Atlas Subsystem

The Atlas subsystem provides higher-level graph analytics:

• `GraphSnapshot` — Point-in-time graph state capture
• `BatchSlicer` — Parallel slice generation for multiple anchors
• `OverlapAnalyzer` — Pairwise overlap detection via Jaccard similarity
• `TurnInfluence` — Influence scoring (frequency, centrality, bridge score)
• `AtlasBundler` — Package all analysis into a manifest

This subsystem enables pre-computed structural analysis of the conversation DAG, supporting use cases like identifying bridge turns that connect otherwise-separate conversation branches.

---

4. Deterministic Context Slicing

4.1 Formal Model

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

Algorithm 1: PolicyWeightedBFS

Input:  anchor_id ∈ TurnId, policy ∈ SlicePolicyV1, store ∈ GraphStore
Output: bundle ∈ AdmissibleEvidenceBundle

1.  anchor ← store.get_turn(anchor_id)
2.  frontier ← MaxHeap⟨ExpansionCandidate⟩
3.  frontier.push(anchor, distance=0, priority=score(anchor, policy))
4.  selected ← [], visited ← {anchor_id}

5.  while frontier ≠ ∅ ∧ |selected| < policy.max_nodes:
6.      c ← frontier.pop()
7.      if c.distance > policy.max_radius: continue
8.      selected ← selected ∪ {c.turn}
9.      for each neighbor ∈ parents(c) ∪ children(c):
10.         if neighbor ∉ visited:
11.             frontier.push(neighbor, c.distance+1,
                    score(neighbor, policy, c.distance+1))
12.             visited ← visited ∪ {neighbor}
13.     if policy.include_siblings:
14.         for each sibling ∈ siblings(c, policy.max_siblings_per_node):
15.             frontier.push(sibling, c.distance,
                    score(sibling, policy, c.distance))

16. edges ← store.get_edges(selected)
17. snapshot_hash ← xxHash64(sort(content_hashes(selected)))
18. slice_id ← xxHash64(anchor, sort(turn_ids), sort(edges),
                policy_id, params_hash, schema_version)
19. token ← HMAC-SHA256(secret,
                canonical(slice_id, anchor, policy_id, params_hash,
                          snapshot_hash, schema_version))[0..16]
20. return AdmissibleEvidenceBundle(selected, edges, slice_id, token)

The priority scoring function combines three factors:

score(turn, policy, distance) = W_phase(turn.phase) × (1 - α + α × turn.salience) × β^distance

where `W_phase` maps conversation phases to importance weights (Synthesis=1.0, Planning=0.9, Consolidation=0.6, Debugging=0.5, Exploration=0.3), `α` is the salience weight (default 0.3), and `β` is the distance decay (default 0.9).

4.2 HMAC-Signed Admissibility Tokens

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

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

[sensitive field redacted], canonical_string)[0..16]

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:

> 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.

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.

4.3 Policy Governance Framework

Context expansion is parameterized by `SlicePolicyV1`:

Policies are registered in an immutable `PolicyRegistry` with deterministic fingerprints. Policy parameter hashes use quantized floats (multiply by 10⁶, 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.

4.4 Determinism Guarantees

Four mechanisms ensure cross-platform reproducibility:

1. Canonical sorting. `BTreeMap` over `HashMap` everywhere. Turns sorted by `TurnId`, edges sorted by `(parent_id, child_id)`. No iteration order depends on hash randomization.

2. Quantized float hashing. Policy parameters are hashed as `i64(float × 10⁶)`, avoiding IEEE 754 representation issues across platforms.

3. Content-derived fingerprints. `slice_id = xxHash64(anchor, sort(turn_ids), sort(edges), policy_id, params_hash, schema_version)`. The fingerprint is purely a function of content.

4. 100-run determinism tests. Golden tests verify that the same anchor + policy + graph produces byte-identical fingerprints across 100 consecutive runs. This is the gold standard for deterministic system testing.

---

5. Entity Normalization

5.1 The Problem

Our DEP audit revealed a 22

This fragmentation directly suppressed benchmark relevance: relationship queries dropped from a projected 1.00 to 0.94, and predicate-specific queries from ~0.95+ to 0.80. The most egregious failure: a query for "Dream Weaver" files returned zero results because the stored subject was "dream-weaver-engine."

5.2 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 Graph Kernel API directly (bypassing the middleware) stored un-normalized entities, creating new aliases.
2. Inconsistency. The normalization rules existed in Python, not where the data was validated — a classic boundary violation.
3. Maintenance burden. Two codebases (Python and Rust) needed to agree on entity canonicalization.

5.3 Rust Implementation

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

// src/service/normalize.rs (simplified)
static ALIAS_TABLE: LazyLock<HashMap<&str, &str>> = LazyLock::new(|| {
    let mut m = HashMap::new();
    m.insert("dream weaver", "dream-weaver-engine");
    m.insert("dreamweaver", "dream-weaver-engine");
    m.insert("gcp", "google-cloud-platform");
    m.insert("google cloud platform", "google-cloud-platform");
    // ... 300+ aliases across 50+ canonical 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)
}

Normalization is enforced on all data paths:

• `add_knowledge_handler` — subject and object normalized; predicate lowercased
• `add_knowledge_batch_handler` — same, within the transaction
• `query_knowledge_handler` — subject and object normalized before lookup
• `delete_knowledge_handler` — subject and object normalized before matching
• `traverse_knowledge_handler` — start entity normalized

The module includes 16 unit tests covering known entities, unknown entities, empty strings, mixed case, and punctuation variants.

5.4 Impact

---

6. Hybrid Retrieval Architecture

6.1 The Complementarity Thesis

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

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

6.2 RAG++ System Architecture

RAG++ consists of two Rust crates (`rag-plusplus-core` at ~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 and conservation-validated bounded forgetting.

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, which uses vector-only search. Activating existing algorithms is projected to raise relevance from 0.70 to 0.90+.

6.3 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.

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

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 ~874ms (3 sequential HTTP round-trips × ~291ms each) to a single round-trip (~291ms remote, projected ~15ms with local SQLite).

6.4 Enrichment Bridge Design

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

1. RAG++ returns top-K semantically similar turns for a query.
2. For each result, entities are extracted from the result text.
3. Extracted entities are resolved to Graph Kernel subjects via `canonicalize_entity()`.
4. The server-side traversal endpoint retrieves 1–2 hop neighborhoods for resolved entities.
5. Results are re-ranked using a combined score: `semantic_score × α + structural_score × (1 - α)`.
6. The enriched result set preserves provenance metadata from both sources.

This transforms flat vector similarity into structured, provenance-tagged reasoning while maintaining sub-second latency.

---

7. Evaluation

7.1 Methodology

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

Methods under test:

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). We note that the relevance metric does not capture structural quality — whether results are causally connected (knowledge chains) or merely co-occurring (coincidence piles).

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), ~200ms RTT.

7.2 Results

Factual Recall

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

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

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 → works_on → clawdbot → uses → Gemini batch API). Each result is causally linked through graph edges.
• Keyword returns 20.0 coincidence results — documents that happen to contain matching substrings with no concept of why the terms co-occur.

The relevance metric masks this quality difference. With the new server-side traversal endpoint, multi-hop latency drops from ~587ms (multiple HTTP calls) to a single request (~291ms remote, projected ~15ms local).

Fuzzy/Semantic Search

The Graph Kernel's weakest category, confirming the expected limitation of exact field matching. This is the primary motivation for the hybrid architecture (§6).

Predicate-Specific Queries

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

7.3 Overall Summary

7.4 Latency Decomposition

Critical insight. The Graph Kernel is compute-efficient (~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×, making it competitive with BM25.

---

8. Comparative Analysis

8.1 System Comparison

We compare the Graph Kernel against ten systems across seven dimensions. The comparison is informed by both our benchmark data and the specific weaknesses identified in the DEP audit.

8.2 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 (§6) 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.

8.3 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:

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

In the CompCore architecture, it serves as the context authority layer between raw conversation storage (PostgreSQL) and agent reasoning (LLM inference), providing the trust boundary that ensures every downstream decision is traceable to a specific, authorized context window.

---

9. Implementation Experience: Lessons from the DEP Audit

9.1 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.

9.2 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. While column names were code-controlled (not user input), the confidence filter used `format!("confidence >= {}", min_conf)` — safe for f64 but inconsistent with the parameterized approach elsewhere. 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 `triples.len()` (page count) instead of the actual matching count. Fixed with a separate `SELECT COUNT(*)` query using the same filters.

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

Request Timeout (OP-3). Added `tower_http::timeout::TimeoutLayer` with a 30-second configurable default to prevent unbounded resource consumption.

Dependency Cleanup (DP-1). Removed `async-trait` proc-macro in favor of native Rust 1.75+ async trait syntax, eliminating a dependency and improving compile times.

9.3 Known Limitations Remaining

No SQLite backend (Evo 1.1). The `GraphStore` trait abstraction makes this clean — implementing `SqliteGraphStore` requires only the trait — but the estimated effort is 2 weeks including sync logic. This would reduce query latency by 20× (291ms → ~15ms).

No query caching (PF-1). Identical knowledge queries hit the database every time. An LRU cache (the infrastructure already exists for token verification) would eliminate repeated queries.

Development HMAC secret fallback (SC-1). When `KERNEL_HMAC_SECRET` is not set, the service falls back to a hardcoded development secret with a warning log. This should be a hard failure in production deployments.

CORS allows any origin (SC-4). Acceptable for local development but needs lockdown for cloud deployments.

No Prometheus metrics (OP-1). Metrics are log-based only, introducing minutes of delay versus real-time monitoring.

Scale uncertainty (SC-1). The system has been tested with ~3,500 triples. Behavior at 100K+ triples is untested. Connection pool size of 10 supports ~34 queries/second at current latencies.

9.4 What the Audit Validated

The DEP audit validated several architectural decisions:

• Feature-gated layering (Architecture: 9/10) — the ability to compile three different profiles (library, postgres, service) 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) — the research paper, architecture doc, evaluation report, and inline docs were noted as exceeding most 100K-line projects.
• Zero unsafe blocks (Code Quality: 8/10) — the entire codebase uses safe Rust with no transmutes, raw pointers, or FFI unsafety.

The audit demonstrated that systematic engineering assessment — measuring across code quality, architecture, performance, security, testing, documentation, dependencies, operations, scale, and known bugs — provides actionable improvement vectors that targeted development can address efficiently.

---

10. Discussion

10.1 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 [42, 43] — 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: what was included, why (policy), and proof of authorization (token).

10.2 Formal Properties of the Provenance Engine Category

We observe that a provenance engine satisfying our four invariants provides three emergent properties:

Regulatory compliance. As AI regulation evolves (EU AI Act [45], NIST AI RMF [46]), the ability to audit which information influenced an agent's decision becomes a compliance requirement. The Graph Kernel's deterministic slicing enables exact reconstruction of any historical context window.

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. This is the cryptographic foundation for multi-agent accountability.

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. This property is absent from every probabilistic retrieval system we evaluated.

10.3 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 (§6). The provenance engine is not a replacement for RAG — it is a complementary layer.

Scale constraints. The evaluated corpus contains 3,502 triples. The system has not been tested at scales beyond tens of thousands. For billion-scale applications, purpose-built distributed databases (Neo4j, Neptune, Dgraph) remain necessary. The single-binary architecture trades scale for deployment simplicity.

Relevance metric limitations. Our relevance metric (fraction of expected terms found) does not capture structural quality. As demonstrated in §7.2, 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 (are results connected through graph edges?), provenance completeness (does the result set form a valid subgraph?), and causal coherence (do the edges form a directed path from anchor to leaf?).

Single-user scope. The current system serves a single user's knowledge graph. Federation across users, teams, or organizations requires the protocol extensions described in §11.

HMAC key management. No key rotation mechanism exists. If the signing secret is compromised, all previously issued tokens remain valid. Key versioning with dual-key verification (current key, then fallback to previous) is needed for production deployments.

RAG++ deployment gap. The RAG++ Rust core contains sophisticated algorithms (HNSW, BM25 hybrid fusion, 5 reranking strategies, trajectory memory) but the deployed FastAPI service uses vector-only search, explaining the 0.70 benchmark relevance. Activating existing algorithms is projected to raise relevance to 0.90+ without new development.

---

11. Evolution Roadmap

Based on the DEP audit findings and the Evo³ analysis, we present a three-phase evolution roadmap.

11.1 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 (~5ms), writes propagate to Supabase asynchronously. Projected latency improvement: 291ms → 5–15ms. Feature-gated via `sqlite` Cargo feature.

Query Caching. LRU cache keyed on query parameters with TTL-based invalidation. Cache invalidated on any write. Using the existing `lru` + `parking_lot` infrastructure already in Cargo.toml.

Activate RAG++ Hybrid Search. Wire the existing `HybridQueryEngine` and `Reranker` through to the FastAPI service endpoints. Default: RRF fusion (k=60) of HNSW + BM25, with Composite reranker (original=0.5, outcome=0.3, recency=0.2). Projected RAG++ relevance: 0.70 → 0.90+.

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

11.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?subject=X&hops=2&format=d3|mermaid|dot` 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 ("what did the system use in January?") and knowledge lifecycle management.

Community Detection. Louvain/Leiden algorithm over the knowledge graph topology to identify hierarchical entity clusters, enabling "what is this corpus about?" queries.

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

11.3 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. Configurable sharing policies per predicate type. 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 (messages, text, triples, graph).

Graph Kernel SDK. First-party client libraries for Rust (productize existing crate), Python (`pip install graph-kernel`), and JavaScript/TypeScript (`npm install @openclaw/graph-kernel`). Generated from OpenAPI specification.

W3C PROV-DM Integration. Map the Graph Kernel's provenance model to W3C PROV [40], enabling export to PROV-compliant systems and alignment with international standards.

Graph Kernel Protocol (GKP/1). Open protocol specification for provenance-governed context authorities. Defines context request, token verification, policy registration, knowledge assertion, and federation semantics. Includes conformance test suite.

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

---

12. 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.

---

References

[1] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, and I. Polosukhin, "Attention is all you need," in Advances in Neural Information Processing Systems (NeurIPS), vol. 30, 2017.

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

[3] J. J. Johnson, M. Douze, and H. Jégou, "Billion-scale similarity search with GPUs," IEEE Trans. Big Data, vol. 7, no. 3, pp. 535–547, 2021.

[4] P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. Küttler, M. Lewis, W.-t. Yih, T. Rocktäschel, S. Riedel, and D. Kiela, "Retrieval-augmented generation for knowledge-intensive NLP tasks," in NeurIPS, vol. 33, 2020, pp. 9459–9474.

[5] Y. Gao, Y. Xiong, X. Gao, K. Jia, J. Pan, Y. Bi, Y. Dai, J. Sun, M. Wang, and H. Wang, "Retrieval-augmented generation for large language models: A survey," arXiv:2312.10997, 2023.

[6] Neo4j, Inc., "Neo4j Graph Database," 2024. [Online]. Available: https://neo4j.com

[7] R. Angles, M. Arenas, P. Barceló, A. Hogan, J. Reutter, and D. Vrgoč, "Foundations of modern query languages for graph databases," ACM Computing Surveys, vol. 50, no. 5, pp. 1–40, 2017.

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

[9] J. F. Sowa, "Semantic networks," in Encyclopedia of Artificial Intelligence, 2nd ed., S. C. Shapiro, Ed. Wiley, 1992.

[10] A. Singhal, "Introducing the Knowledge Graph: Things, not strings," Google Official Blog, May 2012.

[11] Apache Software Foundation, "Apache Jena," 2024. [Online]. Available: https://jena.apache.org

[12] Blazegraph, "Blazegraph Database," 2024. [Online]. Available: https://blazegraph.com

[13] N. Francis, A. Green, P. Guagliardo, L. Libkin, T. Lindaaker, V. Marsault, S. Plantikow, M. Rydberg, P. Selmer, and A. Taylor, "Cypher: An evolving query language for property graphs," in SIGMOD, 2018, pp. 1433–1445.

[14] 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.

[15] A. Hogan et al., "Knowledge graphs," ACM Computing Surveys, vol. 54, no. 4, pp. 1–37, 2021.

[16] A. Hogan et al., "Knowledge graphs," Synthesis Lectures on Data, Semantics, and Knowledge, Morgan & Claypool, 2022.

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

[18] G. Izacard and E. Grave, "Leveraging passage retrieval with generative models for open domain question answering," in EACL, 2021, pp. 874–880.

[19] 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.

[20] S.-C. Yan, S.-W. Gu, L.-Y. Wu, and S. Singh, "Corrective retrieval augmented generation," arXiv:2401.15884, 2024.

[21] 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.

[22] Pinecone Systems, "Pinecone: Vector Database for Machine Learning," 2024. [Online]. Available: https://www.pinecone.io

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

[24] Qdrant, "Qdrant: Vector similarity search engine," 2024. [Online]. Available: https://qdrant.tech

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

[26] D. Edge, H. Trinh, N. Cheng, J. Bradley, A. Chao, C. Mody, S. Truitt, and J. Larson, "From local to global: A graph RAG approach to query-focused summarization," arXiv:2404.16130, 2024.

[27] 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.

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

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

[30] B. Gutiérrez, Y. Yang, H. Gu, M. Sami, and Y. Su, "HippoRAG: Neurobiologically inspired long-term memory for large language models," in NeurIPS, 2024.

[31] J. Liu, "LlamaIndex: A data framework for LLM applications," 2024. [Online]. Available: https://www.llamaindex.ai

[32] H. Chase, "LangChain," 2024. [Online]. Available: https://www.langchain.com

[33] I. Beltagy, M. E. Peters, and A. Cohan, "Longformer: The long-document transformer," arXiv:2004.05150, 2020.

[34] M. Zaheer et al., "Big Bird: Transformers for longer sequences," in NeurIPS, vol. 33, 2020, pp. 17283–17297.

[35] 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.

[36] A. Bulatov, Y. Kuratov, and M. S. Burtsev, "Recurrent memory transformer," in NeurIPS, vol. 35, 2022, pp. 11079–11091.

[37] 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.

[38] P. Buneman, S. Khanna, and W.-C. Tan, "Why and where: A characterization of data provenance," in ICDT, 2001, pp. 316–330.

[39] 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.

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

[41] 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.

[42] D. Amodei, C. Olah, J. Steinhardt, P. Christiano, J. Schulman, and D. Mané, "Concrete problems in AI safety," arXiv:1606.06565, 2016.

[43] S. Weidinger et al., "Ethical and social risks of harm from language models," arXiv:2112.04359, 2021.

[44] M. Mitchell et al., "Model cards for model reporting," in FAT\*, 2019, pp. 220–229.

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

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

[47] M. Jones, J. Bradley, and N. Sakimura, "JSON Web Token (JWT)," RFC 7519, IETF, 2015.

[48] D. Geels, G. Altekar, P. Maniatis, T. Roscoe, and I. Stoica, "Friday: Global comprehension for distributed replay," in NSDI, 2007, pp. 285–298.

[49] O. Laadan, N. Viennot, and J. Nieh, "Transparent, lightweight application execution replay on commodity multiprocessor operating systems," in SIGMETRICS, 2010, pp. 155–166.

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

[51] C. Lerche et al., "Tokio: An asynchronous runtime for Rust," 2024. [Online]. Available: https://tokio.rs

[52] Amazon Web Services, "Amazon Neptune," 2024. [Online]. Available: https://aws.amazon.com/neptune/

[53] Dgraph Labs, "Dgraph: Distributed graph database," 2024. [Online]. Available: https://dgraph.io

[54] Vaticle, "TypeDB: The polymorphic database," 2024. [Online]. Available: https://typedb.com

[55] F. Petroni et al., "Language models as knowledge bases?" in EMNLP-IJCNLP, 2019, pp. 2463–2473.

[56] 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.

[57] J. Wei et al., "Chain-of-thought prompting elicits reasoning in large language models," in NeurIPS, vol. 35, 2022, pp. 24824–24837.

[58] T. Schick et al., "Toolformer: Language models can teach themselves to use tools," in NeurIPS, vol. 36, 2024.

[59] S. Yao et al., "ReAct: Synergizing reasoning and acting in language models," in ICLR, 2023.

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

---

Appendix A: 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 `[home-path]`. 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).

Appendix B: Corpus Statistics

Appendix C: DEP Audit Score Summary

Post-fix projected score: 8.4/10 (+1.0 from entity normalization, traversal endpoint, SQL fixes, pool optimization, pagination fix, DELETE endpoint, request timeout, dependency cleanup).

Appendix D: Post-Audit Changes Summary

---

Paper V2 — Definitive post-audit edition. Graph Kernel v0.1.0+fixes, Schema v1.0.0. OpenClaw CompCore, July 2026.