Executable Knowledge Graphs (xKG)

• Executable Knowledge Graphs (xKG) are graph-based systems where the structure itself acts as an operational substrate, enabling direct execution of control flows.
• They compile high-level specifications—using methods like RDF/OWL schemata, SPARQL templates, and Python class synthesis—into runnable, verifiable graph programs.
• xKG systems have been applied across domains, demonstrating enhanced reliability, performance gains, and improved debugging in areas from ML analytics to cyber threat intelligence.

Searching arXiv for papers on executable knowledge graphs and closely related systems to ground the article. arxiv_search query: "executable knowledge graphs xKG knowledge graph executable reasoning" Executable Knowledge Graphs, often abbreviated as xKG or ExeKG, denote a family of knowledge-graph systems in which graph structure is treated as an operational substrate rather than as a passive store of triples. Across recent work, this executability appears in several concrete forms: RDF/OWL graphs that are validated and compiled into Python ML pipelines, dialogue-derived conditions that constrain logical query generation over a KG, competency-question libraries that become run-time SPARQL plans, schema-derived class systems that support sandboxed code execution on graph objects, state–action memories navigated by search, and operator graphs whose traversal itself instantiates an algorithm (Klironomos et al., 1 Aug 2025, Gao et al., 29 May 2026, Barla et al., 2 Apr 2026, Ding et al., 2 Jun 2026, Qin et al., 12 May 2026, Sartori et al., 30 Mar 2026).

1. Definitional scope and conceptual boundaries

In the xKG literature, the central shift is from representational adequacy to operational adequacy. In ExeKGLib, the graph is “the authoritative specification of what will be executed,” and the library “automate[s] the process of translating pipelines from RDF to Python code” (Klironomos et al., 1 Aug 2025). In HypoAgent, natural-language dialogue is compiled into “executable KG conditions,” then into logical hypotheses that are executed over a KG and repaired through graph probing (Gao et al., 29 May 2026). In the cultural-heritage setting, competency questions cease to be only design-time ontology tests and become run-time “executable narrative plans” instantiated as parameterized SPARQL templates (Barla et al., 2 Apr 2026). In CoG, the KG schema is reified as Python classes and the factual subgraph is instantiated as runtime objects, so reasoning is carried by executable code rather than by direct prompt injection of triples (Ding et al., 2 Jun 2026).

Taken together, these systems suggest that xKG is not a single formalism but a design space. Some xKGs are graph-to-code compilers, some are graph-query planners, some are graph-executable memories, and some are procedural graphs whose nodes already store runnable operators. What unifies them is that the graph exposes machine-usable control structure: paths, conditions, templates, workflows, state transitions, or operator compositions. This also distinguishes xKG from a purely descriptive KG, from vanilla KG-RAG that only injects retrieved facts into prompts, and from ontology engineering that never reaches an execution layer (Barla et al., 2 Apr 2026, Ding et al., 2 Jun 2026).

A recurrent misconception is that executability is reducible to OWL reasoning. The surveyed work does not support that reduction. ExeKGLib is explicitly ontology- and SHACL-backed, but semantic-unit modularization argues for a broader architecture in which each unit can be annotated with its own logic base, including OWL, First-Order Logic, or none, and queried selectively for reasoning purposes (Klironomos et al., 1 Aug 2025, Vogt, 2024). Another misconception is that xKG implies end-to-end symbolic execution only. Several systems instead combine symbolic executability with learned planning or search, such as MCTS with a Q-function in EAM, GRPO-trained path exploration in EoG, or autoregressive priors over semantically valid graph states in ARK and SAIL (Qin et al., 12 May 2026, Yan et al., 25 Feb 2026, Thanapalasingam et al., 6 Feb 2026).

2. Representational substrates and executable semantics

The representational layer of an xKG determines what can be executed, validated, or optimized. ExeKGLib uses RDF/OWL schemata with one upper-level data-science schema and lower-level ML, statistics, and visualization schemata, plus a SHACL shapes graph that “validate[s] every constructed ExeKG and guarantee[s] executability” (Klironomos et al., 1 Aug 2025). Its core classes include ExeKG, Task, and DataEntity, and execution follows a hasNextTask chain whose nodes are mapped to Python classes implementing run_method().

HypoAgent’s substrate is different: it treats abductive hypotheses themselves as executable objects. A hypothesis is a FOL query pattern over a triple KG, with literals of the form $r(u,v)$ or $\neg r(u,v)$, and execution yields an answer set $\mathcal{A}_{\mathcal{G}(H)}$ compared against observations via Jaccard, Dice, or Overlap (Gao et al., 29 May 2026). Its condition language is typed and compact: relation, entity, relationnumber, entitynumber, and pattern, with the pattern expressed using the token alphabet $\{i,u,n,p,e\}$ and 13 predefined logical query types.

Other xKGs make the executable object more explicit. GEAKG defines a graph

$$\mathcal{G} = (\mathcal{S}, V, E, \Lambda, \Phi, \Sigma),$$

where nodes are roles, $\Lambda$ maps nodes to executable operators, $\Phi$ stores learned edge weights, and $\Sigma$ stores symbolic rules (Sartori et al., 30 Mar 2026). EAM defines a GUI Logic Knowledge Graph

$G = (S, A, E),$

where $S$ are GUI state nodes, $\neg r(u,v)$0 are action nodes, and directed edges encode availability and deterministic successor states (Qin et al., 12 May 2026). CoG derives executable class definitions from KG schema and uses them as a strongly typed interface over a retrieved subgraph (Ding et al., 2 Jun 2026). TITAN makes typed, bidirectional CTI relations into an executable query language whose programs are relation chains plus operators such as filter, select, exec_common, and exec_difference (Simoni et al., 16 Oct 2025). Semantic units extend the design space further by making statement-scale subgraphs first-class resources and by introducing some-instance, most-instances, every-instance, and all-instances resources to distinguish assertional, contingent, prototypical, and universal knowledge (Vogt, 2024).

xKG pattern	Executable artifact	Representative systems
Code-coupled workflow graph	RDF/OWL pipeline compiled to Python	ExeKGLib (Klironomos et al., 1 Aug 2025)
Conditioned logical-query graph	FOL hypotheses and condition schemas	HypoAgent (Gao et al., 29 May 2026)
Plan library over a KG	Parameterized CQ-to-SPARQL templates	CQ planning for storytelling (Barla et al., 2 Apr 2026)
Schema-mediated program interface	Python classes and instantiated graph objects	CoG (Ding et al., 2 Jun 2026)
State–action execution graph	Deterministic GUI transitions plus MCTS	EAM (Qin et al., 12 May 2026)
Operator-composition graph	Role graph with runnable operators	GEAKG (Sartori et al., 30 Mar 2026)
Logic-annotated semantic modules	Statement/compound units with logic bases	Semantic units (Vogt, 2024)

This heterogeneity has an important consequence: xKG expressivity depends less on the presence of triples per se than on the presence of typed executable interfaces. In one branch of the literature, those interfaces are SHACL-constrained classes and methods; in another, they are relation chains; in another, they are macro-actions; in another, they are reusable semantic units with explicit logic annotations.

3. Compilation pipelines: from language, plans, and schemas to executable graphs

A defining characteristic of xKG systems is compilation from higher-level specifications into executable graph forms. HypoAgent exemplifies a dialogue-to-execution stack. Its Intent Recognition Agent computes

$\neg r(u,v)$1

where $\neg r(u,v)$2 is a set of executable KG conditions. The Hypothesis Generation Agent then models

$\neg r(u,v)$3

producing query_tokens that are run by a logical query engine; when similarity or condition adherence is poor, the Root Cause Analysis Agent invokes graph_validation, incoming_edge_intersection, and intersection_candidates to diagnose weak fragments and propose executable repairs (Gao et al., 29 May 2026).

The smart-manufacturing framework follows a different compiler chain: natural-language intent $\neg r(u,v)$4 constrained JSON requirement model $\neg r(u,v)$5 ISA-95-aligned Neo4j subgraph updates (Jradi et al., 12 Feb 2026). The JSON schema includes goal, mode, trigger, and action.constraint, and the fine-tuned Mistral-7B-Instruct-v0.2 model is used purely as an intent compiler. The KG then becomes the execution schema against which downstream schedulers or controllers can interpret processes, resources, and constraints.

The cultural-heritage storytelling system compiles persona and narrative length into a beat plan consisting of instantiated competency questions. Each CQ has a stable identifier, parameter signature, and a hand-authored SPARQL template, so the run-time artifact is not a free-form prompt but an explicit sequence of query invocations over the Live Aid KG (Barla et al., 2 Apr 2026). TITAN follows the same broad pattern in cyber threat intelligence: a path planner maps natural-language queries to typed relation chains that a graph executor traverses deterministically over the TITAN Ontology (Simoni et al., 16 Oct 2025).

CoG compiles in yet another direction. After planning a subtask, it retrieves a relevant subgraph, identifies the corresponding KG schema, represents those schemas as Python classes, and then generates executable code over those classes (Ding et al., 2 Jun 2026). KGA-ECoT similarly decomposes a math problem into a Structured Task Graph, retrieves callable nodes from a SymPy-based DAG, generates Python code, and validates reasoning via Docker execution (Chen et al., 6 Aug 2025). In both cases, the executable interface is neither raw triples nor SPARQL, but callable abstractions derived from graph structure.

A plausible implication is that compilation is the core abstraction layer of xKG. Natural language, personas, task descriptions, and domain objectives are not executed directly. They are lowered into explicit graph-program objects: condition schemas, relation chains, CQs, structured JSON, class APIs, or task graphs. The more disciplined this lowering step is, the more tractable auditing and repair become.

4. Execution backends, search, and verification regimes

Execution in xKG systems ranges from direct graph traversal to code execution and learned search. In ExeKGLib, a validated ExeKG is parsed with rdflib, traversed via hasNextTask, mapped dynamically to Python task classes, and executed through each task’s run_method() against libraries such as scikit-learn, matplotlib, and NumPy (Klironomos et al., 1 Aug 2025). In HypoAgent, execution is logical query evaluation over a triple KG, with answer sets scored by semantic similarity and condition adherence; its RCA stage is essentially a program debugger over graph fragments (Gao et al., 29 May 2026).

CoG replaces prompt-time factual injection with programmatic execution. Once Python classes are synthesized from KG schema and facts are instantiated as objects, the LLM writes code that traverses attributes, filters, aggregates, and combines objects in a sandbox (Ding et al., 2 Jun 2026). KGA-ECoT uses an analogous pattern over a callable library graph, but the execution target is mathematical code rather than entity selection; external code execution is the decisive correctness check (Chen et al., 6 Aug 2025).

Several systems add explicit search or control algorithms over the xKG substrate. EAM defines a finite-horizon MDP over GUI state and action nodes and uses a UCT-style MCTS objective,

$\neg r(u,v)$6

where $\neg r(u,v)$7 is initialized and refined by a lightweight Q-model trained to approximate $\neg r(u,v)$8, the Q-function under a uniform random policy (Qin et al., 12 May 2026). Its graph is executable because each path is already a replayable GUI routine discovered offline. GEAKG uses a different control layer: Ant Colony Optimization learns pheromone weights $\neg r(u,v)$9 over edges between typed roles, while a Symbolic Executor chooses phases such as Refine, Explore, or Restart and then binds selected roles to runnable operators in $\mathcal{A}_{\mathcal{G}(H)}$0 (Sartori et al., 30 Mar 2026).

EoG provides a path-centric neighboring design. It treats the KG as an environment and trains an LLM policy with GRPO on two reward components: answer correctness and path coverage. The outcome reward is entity-level F1, while the path reward is the fraction of ground-truth triples explicitly covered in the > trace,

$\mathcal{A}_{\mathcal{G}(H)}$1

thereby aligning exploration with executable reasoning paths over the KG (Yan et al., 25 Feb 2026). ARK and SAIL occupy a more probabilistic frontier: they linearize KGs into token sequences and learn $\mathcal{A}_{\mathcal{G}(H)}$2 over whole graphs, producing semantically valid graph states that can be used for completion, scenario construction, or query answering (Thanapalasingam et al., 6 Feb 2026).

These systems indicate that xKG execution need not be limited to deterministic symbolic traversal. It can also include neural value estimation, RL over paths, sandboxed code execution, or probabilistic generation of graph states, provided the graph remains the operational substrate and the runtime semantics remain inspectable.

5. Domain instantiations and empirical patterns

The xKG paradigm has been instantiated across scientific workflow construction, biomedical and commonsense reasoning, cultural-heritage storytelling, cyber threat intelligence, GUI automation, manufacturing, AI research replication, mathematical coding, and algorithm search. ExeKGLib shows that RDF/OWL- and SHACL-backed executable graphs can support industrial ML analytics, with user-study dimensions of $\mathcal{A}_{\mathcal{G}(H)}$3 for transparency (communication), $\mathcal{A}_{\mathcal{G}(H)}$4 for reusability, and $\mathcal{A}_{\mathcal{G}(H)}$5 for communication easiness in the broader SemML deployment (Klironomos et al., 1 Aug 2025). In the paper-replication setting, xKG improves PaperBench reproduction performance, with “substantial performance gains (10.9% with o3-mini)” and an average increase from 42.31% to 53.21% for PaperCoder + o3-mini in the detailed results (Luo et al., 20 Oct 2025).

In interactive abductive reasoning, HypoAgent reports state-of-the-art semantic similarity across single-turn, multi-turn, and unconditional settings; the detailed results include single-turn Overlap often above 0.96–0.99 and a PharmKG Jaccard improvement from 63.3 to 82.4 (Gao et al., 29 May 2026). In controlled narrative generation, the CQ architecture exposes a quantifiable trade-off: KG-RAG yields the highest support ratio, Hybrid-RAG the highest coverage, and Graph-RAG the strongest global_cohesion, reported as 1.0 across all runs (Barla et al., 2 Apr 2026). In smart manufacturing, the intent-to-KG compiler reaches 89.33% exact match accuracy and 97.27% overall accuracy on structured JSON generation (Jradi et al., 12 Feb 2026).

Programmatic xKG interfaces also show strong empirical gains. CoG outperforms prior state-of-the-art models by up to 10.5% on WebQSP, CWQ, and GrailQA, and its Token Utility Rate analysis attributes this to schema-level prompt compression plus runtime access to much larger factual subgraphs (Ding et al., 2 Jun 2026). KGA-ECoT reports “absolute accuracy improvements ranging from several to over ten percentage points” and attributes them to GraphRAG over callable nodes and executable code verification (Chen et al., 6 Aug 2025). EAM outperforms baselines like UI-TARS-7B by up to 19.6% on AndroidWorld, reduces token costs $\mathcal{A}_{\mathcal{G}(H)}$6 relative to GPT-4o, and achieves a 2.8s average latency (Qin et al., 12 May 2026). In CTI, TITAN provides 88,209 examples pairing questions with executable paths and shows that CoT supervision materially improves path accuracy over NoCoT across path-length and operator buckets (Simoni et al., 16 Oct 2025).

The same pattern appears in generative and procedural xKGs. ARK attains 89.2% to 100.0% semantic validity on IntelliGraphs while generating novel graphs (Thanapalasingam et al., 6 Feb 2026). GEAKG shows that procedural knowledge can be learned and transferred zero-shot across domains: its NAS case study reports 70/70 wins over Random Search across transfer pairs, and its optimization case study transfers TSP-derived procedural structure to scheduling and assignment domains without changing the engine code (Sartori et al., 30 Mar 2026). In clinical decision support, Guideline2Graph reports edge and triplet precision/recall improving from 19.6%/16.1% in existing models to 69.0%/87.5%, while node recall rises from 78.1% to 93.8%, supporting decomposition-first guideline-to-CDS conversion on the adjudicated prostate-guideline benchmark (Kilic et al., 2 Apr 2026).

A broad empirical pattern emerges. Systems that move from step-wise free-form generation to retrieval-and-execution or plan-and-execute generally report gains in reliability, cost, or long-horizon performance. This suggests that the principal benefit of xKG is not merely more structured storage, but the externalization of control flow into inspectable graph artifacts.

6. Limitations, debates, and research directions

The current xKG literature also exposes non-trivial limitations. HypoAgent depends heavily on KG quality, is local in its RCA probing, and faces a controllability-versus-adherence trade-off when better explanations conflict with user-prescribed relations or structures (Gao et al., 29 May 2026). ExeKGLib currently focuses on “classic ML methods and tasks,” uses essentially linear hasNextTask execution, lacks a graph-database backend, and requires ongoing ontology and SHACL maintenance as libraries evolve (Klironomos et al., 1 Aug 2025). The cultural-heritage CQ framework remains a single-concert case study and explicitly calls for automatic CQ and plan generation, path-aware metrics for subgraph summarization, and richer planning languages with branching and loops (Barla et al., 2 Apr 2026).

Other systems reveal different fault lines. The smart-manufacturing framework uses the KG mainly for mapping and storage; it models only three process types and does not yet provide an explicit execution engine connected to controllers or digital twins (Jradi et al., 12 Feb 2026). CoG’s gains depend on strong coding models and can fail through subtask-planning errors, retrieval misses, semantic misinterpretation, or retry exhaustion on complex Freebase CVT structures (Ding et al., 2 Jun 2026). EAM assumes relatively static UIs and deterministic transitions; app updates or distribution shift can invalidate paths or action groups (Qin et al., 12 May 2026). ARK and SAIL assume a closed vocabulary, operate on subgraphs rather than web-scale KGs, and learn constraints only implicitly, which limits inspectability and open-world adaptation (Thanapalasingam et al., 6 Feb 2026). GEAKG requires manual RoleSchema engineering and learns offline rather than online (Sartori et al., 30 Mar 2026).

There is also an unresolved representational debate. One branch centers xKG on executable code, workflows, and operators; another centers it on path-executable graph programs; another on logic-annotated semantic modularization. The semantic-unit framework argues that a future xKG stack should tolerate logical heterogeneity by annotating each unit with its logic base and then querying only those units that are compatible with a given reasoner (Vogt, 2024). This suggests a federated execution architecture rather than a monolithic one.

Several forward directions recur across the corpus. HypoAgent points toward richer condition languages and external execution backends beyond static KGs (Gao et al., 29 May 2026). ExeKGLib points toward graph-database integration and richer method catalogs (Klironomos et al., 1 Aug 2025). CoG points toward stronger schema-aware program synthesis and tighter sandboxed execution (Ding et al., 2 Jun 2026). EAM points toward broader memory coverage and more robust value-guided planning (Qin et al., 12 May 2026). GEAKG points toward broader procedural transfer through reusable ontological role systems (Sartori et al., 30 Mar 2026). A plausible synthesis is that the next generation of xKGs will combine typed graph substrates, explicit compilation layers, heterogeneous execution engines, and modular reasoning over named semantic units, with provenance and debuggability treated as first-class requirements rather than afterthoughts.