Back to corpus
experimentexperiment writeup candidatescore 46

Graph Kernel Comprehensive Evaluation Report

**OpenClaw CompCore — Technical Evaluation** **Version:** 1.0.0 · **Date:** 2026-02-13 **Authors:** Mohamed Diomande, OpenClaw Research **Classification:** Internal Technical Report

Full HTML reader

Read the full artifact

Open in new tab

Extracted abstract or opening context

**OpenClaw CompCore — Technical Evaluation** **Version:** 1.0.0 · **Date:** 2026-02-13 **Authors:** Mohamed Diomande, OpenClaw Research **Classification:** Internal Technical Report The OpenClaw Graph Kernel (GK) is a deterministic context slicing engine implemented as a single Rust binary (Axum/Tokio) that serves a dual purpose: (1) constructing reproducible, policy-governed, HMAC-signed context windows for autonomous AI agents, and (2) operating as a lightweight knowledge graph triple store over a PostgreSQL backend. We evaluated the Graph Kernel against three baseline retrieval methods (keyword search, BM25, and RAG++ vector similarity) across 27 queries spanning five categories. Additionally, we performed an extensive comparative analysis against nine industry-grade graph databases, knowledge graph frameworks, and RAG orchestrators: **Neo4j, Amazon Neptune, Apache Jena/Fuseki, Dgraph, TypeDB, Weaviate, LangChain/LlamaIndex Knowledge Graphs, Microsoft GraphRAG, and Zep**. 1. **Context Slicing is Irreplaceable.** No evaluated alternative provides deterministic, HMAC-signed, policy-governed context window construction. This is the Graph Kernel's unique value proposition and cannot be replicated by bolting features onto general-purpose graph databases. 2. **Multi-hop Reasoning Achieves Perfect Relevance.** The GK achieves 1.00 relevance on multi-hop traversal queries, returning *structurally connected* knowledge chains rather than keyword-coincidence result sets. This is qualitatively distinct from high relevance scores achieved by text-matching baselines.

Promotion decision

What has to happen next

Attach run IDs, datasets, metrics, and reproduction commands.

Why this is not always a full paper yet

Corpus pages are public-safe readers for discovered workspace artifacts. They are not automatically final papers. A corpus item becomes a polished paper only after the editable source, evidence checkpoints, references, figures, render path, and release status are attached through the paper schema.