CypherGuard: Database-Grounded Correction for Reliable Text-to-Cypher

arXiv:2610.41755v1 [cs.DB] 30 Oct 2026

CypherGuard: Database-Grounded Correction for Reliable Text-to-Cypher Zebin Chen

Dong Wen

University of New South Wales Sydney, AU zebin.chen1@unsw.edu.au

University of New South Wales Sydney, AU dong.wen@unsw.edu.au

Makbule Gulcin Ozsoy

Wenjie Zhang

Neo4j London, UK makbule.ozsoy@neo4j.com

University of New South Wales Sydney, AU wenjie.zhang@unsw.edu.au

ABSTRACT Text-to-Cypher translates natural-language questions into Cypher queries over property graphs. Graph database systems increasingly adopt this translation as a native query interface. Large language models generate fluent Cypher but stay unreliable. On CypherBench a small model answers only 31.4% of questions correctly, and even a strong model plateaus at 71.76%. The dominant failure modes are structural rather than linguistic. For example, a generated query may parse correctly and follow the schema, yet still return zero rows because it traverses a relationship against the stored graph direction. To address this issue, we present CypherGuard, a training-free framework that detects and corrects these structural faults. Our approach uses two core components: a graphnative error taxonomy to guide repair, and a mined rule library to guide query generation. At inference time, CypherGuard first rewrites schema-detectable faults, then re-executes each draft and repairs it only when the query errors or returns nothing. On all 2,348 CypherBench test questions, across seven graphs, CypherGuard reaches 88.50% overall execution accuracy, +25.08% over the same-backbone zero-shot floor, surpassing an RL-fine-tuned 7B specialist and the strongest training-based system that we compare against.

1

INTRODUCTION

Querying data in natural language is a long-standing ambition of the database community, pursued on the relational database [28, 47, 58] and, as question answering over knowledge graphs, on the graph [2, 54]. Large language models have made the drafting step cheap, and the relational side has industrialized accordingly. Text-to-SQL systems, open models, and benchmark-scale evaluations are standing subjects at data-management venues [14, 26, 30]. The graph side has reached the same moment. Graph DBMS vendors ship text-to-Cypher datasets, fine-tuned baselines, and integration tooling [25, 37], and GraphRAG pipelines demonstrate graph-backed retrieval at scale [11]. Text-to-Cypher methods are not yet reliable, and the techniques that made text-to-SQL trustworthy do not transfer to text-to-Cypher directly. Text-to-Cypher still falls far short of high execution accuracy. On Spider, the standard text-to-SQL benchmark, GPT-4 with retrieved few-shot examples reaches 86.6% execution accuracy [14]. On CypherBench, an execution-scored text-to-Cypher benchmark,

Q: How many countries does Germany maintain diplomatic relations with? ✗ Naive draft (reads a mutual relation as undirected) MATCH (:Country {name:’Germany’}) -[:hasDiplomaticRelationWith] (c:Country) RETURN count(c)

→ wrong: stored both ways. The undirected match therefore counts each partner twice. Execution returns rows, no alarm.

✓ CypherGuard (storage-reciprocity gate: the probe measures the relation reciprocal, and undirected becomes directed) MATCH (:Country {name:’Germany’}) - [:hasDiplomaticRelationWith]-> (c:Country) RETURN count(c)

→ correct.

Figure 1: A schema-consistent draft on a CypherBench relation runs without error yet returns a wrong count, a fault no execution signal exposes.

claude-3.5-sonnet reaches only 61.6% and gpt-4o only 60.2% zero-shot [12]. RL-tuned Cypher-RI reaches only 69.6% [50] and CypherSmith reaches only 74.8% [66]. Figure 1 illustrates one common failure pattern in text2cypher. Consider asking a model to count how many diplomatic partners a country has. While hasDiplomaticRelationWith appears naturally mutual and undirected, the graph stores it as two directed edges. Consequently, an undirected query pattern matches each relationship twice. The generated query parses correctly, follows the schema, and executes without errors, yet silently returns doubled counts. Prompting the model again cannot expose the double counting. Similarly, simple execution fails to catch the bug because the query still returns rows. Detecting this mismatch requires measuring the actual relationship storage pattern in the database. Prior work covers only some faults. Models frequently make subtle errors in NL2Cypher task. They traverse relationships backwards, connect labels unsupported by the schema, inflate counts through path fan-out, or add unprompted ORDER BY and LIMIT clauses. However, syntactically and at the schema level, these queries remain valid. Static schema checks accept such queries, and running them often raises no error either. Prior work already checks a few of these faults. LangChain’s Cypher corrector rewrites relationship directions that contradict the schema [25]. [36] filter sampled candidates with an openCypher grammar and a relationship-direction

Zebin Chen, Dong Wen, Makbule Gulcin Ozsoy, and Wenjie Zhang

check. They also report an iterative refinement loop whose verifiers include a direction check, an execution check, and an LLM judge [35]. Existing taxonomies categorize these errors purely posthoc [12, 52]. However, no text-to-Cypher method uses these categories to steer query generation. Existing work improves text-to-Cypher accuracy along two routes. The first route trains the model on Cypher data. [50] fine-tunes the model with execution-based rewards using Reinforcement learning (RL). Cypher pairs [66] trains the model on question via Supervised fine-tuning (SFT). The second route leaves the model unchanged and works at inference time. Multi-agent frameworks assign query generation, result checking, and repair to separate LLM agents [18]. Execution-feedback methods regenerate a query after the database reports an error [23]. Both routes have limitations. Training needs gold-labeled data. RL requires a gold query and an executable database for every training question, and has been trained on a benchmark training split. SFT faces a data shortage. Public Cypher datasets hold at most tens of thousands of examples, and recent work synthesizes hundreds of thousands with LLMs. Inferencetime methods take their correction signal from the database’s error message or from an LLM critic’s judgment of the returned rows. A silent fault raises no error, and the critic’s judgment of the returned rows is not checked against the database. We present CypherGuard, an admission-control layer between the LLM and the graph database. Admission here means screening queries and rewrites. Our pipeline consists of three stages: (1) Draft: The LLM generates an initial query guided by mined errorprevention rules and retrieved demonstration examples. (2) Schema Fixes: A deterministic module corrects structural faults revealed by schema constraints or storage statistics, such as an undeclared relationship type. (3) Execution Loop: If a query fails or returns an empty result, the LLM identifies the error type from our Cypher taxonomy and rewrites the query. The layer’s rule library is mined once per dataset, by prompting an LLM agent over the backbone’s failures on that dataset’s train split. Our contributions are: • Repairs backed by database signals. We frame reliable text-toCypher as admission control. The framework consults multiple signals: question phrasing, schema constraints, stored-data statistics, and execution feedback. Each signal triggers only targeted repairs for the specific error it detects. Furthermore, the system accepts a proposed rewrite only if it passes re-verification or replaces an already-failed query. • A transferable Cypher error taxonomy. We distil recurring text-to-Cypher failures into eight families and 32 fine-grained codes. Seven families, spanning 28 codes, name faults that leave the query executable, such as a reversed relationship direction, a wrong pattern topology, or an aggregation over fan-out-inflated rows. • A graph-mined rule library. We automatically mine preventive rules to guide query generation. Specifically, an LLM agent analyzes execution-verified failures from the backbone model across training graphs. The agent extracts one rule per recurring failure mechanism using a standardized prompt. To ensure broad applicability, an independent generality validator filters these rules to keep them graph-agnostic.

• Dataset validation. On CypherBench, CypherGuard reaches 88.50% overall execution accuracy (Section 5). This performance marks a +25.08% improvement over the same-backbone zeroshot baseline. Applying our framework to stronger backbone yields a comparable performance gain. Furthermore, CypherGuard outperforms the reported RL-fine-tuned 7B Cypher specialist.

2

BACKGROUND

A property graph is a directed, labeled multigraph whose vertices and edges carry type labels and key–value properties. Cypher is one of the query languages in graph databases [13]. We study the schema-grounded formulation. Given a natural-language question 𝑞 and the schema 𝑆 (𝐺) of a target graph 𝐺, which specifies node labels, relationship types, and property keys, we aim to produce, via an LLM, a Cypher query 𝑐ˆ that, when executed on 𝐺, returns the answer that 𝑞 asks for. Execution accuracy. Execution accuracy (EA) is the fraction of questions whose predicted query returns a result multiset equal to the gold answer. It is calculated as 𝑛
 1 ∑︁  EA = 1 eq Jˆ𝑐𝑖 K𝐺𝑖 , J𝑐𝑖★K𝐺𝑖 , 𝑛 𝑖=1 where J𝑐K𝐺 is the result of executing 𝑐 on 𝐺, 𝑐𝑖★ is the gold query, and eq is the result-equality comparator. A runtime error or timeout counts as a miss. CypherBench [12] also defines two auxiliaries alongside it: executability(the executable percentage), the fraction of predictions that run without a runtime error, and the provenancesubgraph Jaccard similarity (PSJS), a partial-credit overlap between the subgraphs that the predicted and gold queries match. This paper mainly targets execution accuracy. An LLM first genˆ which our proposed solution CypherGuard erates a draft query 𝑐, then checks. We call 𝑐ˆ a draft for short. CypherGuard rewrites the draft to fix faults by checking the question’s intent, the schema, and the execution result. A fault-free draft is returned unchanged. Section 3 presents the architecture. Section 5 and Section 6 quantify the accuracy gain contributed by each component.

3 THE CYPHERGUARD LAYER 3.1 Pipeline Overview Our method, namely CypherGuard, is built to improve execution accuracy. It runs a sequence of checks on the generated Cypher query and update the query when a fault is found. A straightforward check is to execute the query on a graph database and read any error logs returned by the database. However, only syntax-level errors can be captured in this way. A faulty query may be executed without errors but return empty or wrong results. To improve the Cypher accuracy, our solution inspects multiple types of faults in three stages shown in Figure 2 and Algorithm 1: Draft, Schema Fixes, and Execution Loop. The Draft produces a candidate query (namely draft query for simplicity) at the initial stage. Its prompt carries the static rule library and two kinds of retrieved exemplars, few-shot and shape (Section 3.2). The rule library lists the recurring fault patterns so that certain faults can be avoided at the drafting stage. Schema Fix (Section 3.3) resolves faults whose correct form can be determined

CypherGuard

Algorithm 1 The CypherGuard Algorithm Require: question 𝑞, graph 𝐺, schema 𝑆 (𝐺), rule library 𝑅, traingraph exemplar corpus 𝐷, reciprocity verdicts Σ 1: 𝐸 ← Retrieve(𝑞, 𝐷) ⊲ few-shot + shape exemplars 2: 𝑐 ← Draft(𝑞, 𝑆 (𝐺), 𝑅, 𝐸, Σ) ⊲ stage 1 3: 𝑐 ← FixRelTypes(𝑐, 𝑆 (𝐺)) ⊲ stage 2 4: 𝑐 ← AlignDirections(𝑐, 𝑆 (𝐺)) 5: 𝑐 ← RedirectSelfLoops(𝑞, 𝑐, Σ) 6: return RepairLoop(𝑞, 𝑐, 𝐺) ⊲ stage 3, Algorithm 2 Table 1: Reliability designs for LLM query generation. Schema = declared node labels, relationship types, and edge directions. Stored = stored-data statistics or content. Exec. = execution feedback. Commit = model-issued rewrites must pass a deterministic test. Design

Schema Stored Exec. Commit

Constrained decoding [48] Exec.-triggered rewriting [55] Judge-guarded correction [15] Content-informed refinement [46] Schema direction corrector [25] Calibrated abstention [6] Trained specialists [50, 66]

✓ – ✓ ✓ ✓ ✓ –

– – ✓ ✓ – – –

– ✓ ✓ ✓ – – –

n/a – – – n/a n/a n/a

CypherGuard

✓

✓

✓

✓

by the schema, such as an invalid relationship type. The Execution Loop (Section 3.4) runs the query and reacts when the query raises an error or returns nothing. To this end, when the result is empty the loop first tries reversing relationship arrow and keeps the reversal only if it returns data. Otherwise it asks the LLM to rewrite, which replaces the failing query. Algorithm 1 presents the pseudocode of the pipeline. Retrieve gathers the few-shot and shape exemplars. Draft then generates the candidate query based on the question, the schema, the rule library, and the exemplars. FixRelTypes, AlignDirections, and RedirectSelfLoops apply the Schema Fixes in sequence. RepairLoop then runs the Execution Loop and returns the final query.

3.2

Transferable Error Taxonomy and Rule Library

Recurring errors in Cypher draft generation can be identified and summarized in advance to assist the Draft and Execution Loop. This section introduces three artifacts: a taxonomy, a rule library, and a set of exemplars. A taxonomy categorizes recurring fault families and guides the Execution Loop’s correction prompt. A mined rule library reformulates these faults as instructions in the Draft prompt to guide query generation. Retrieved exemplars show the model what a correct query for a similar question looks like. The taxonomy. Taxonomy-driven correction is first established in text-to-SQL [4, 15], but certain Cypher faults cannot be captured by the SQL error taxonomy. For example, a Cypher might use a label or relationship type that the schema never declares. This Cypher can still be parsed and silently returns no data. Hence, CypherBench [12] annotates ten classes over sampled failures and GQLBench [52] adapts that scheme to thirteen classes for NL2GQL.

While both benchmarks diagnose where models fail, neither uses these failure patterns to correct queries. We therefore distil observed text-to-Cypher failures into a graph-native taxonomy of eight families. The taxonomy includes: syntax, direction, schema, entity, pattern, aggregation, filter, and return. It spans 32 fine-grained codes (Table 2). Those codes steer Cypher rewrite rather than just name the fault. The tier-2 correction prompt of the Execution Loop lists all 32 codes and asks the model to name a code, state a root cause, and then write the corrected query (Section 3.4). The last column of Table 2 names the mechanism. A mined, dataset-agnostic rule library. The taxonomy only helps once a query has already been drafted. The rule library acts earlier. A rule is a short instruction that tells the model how to avoid a common query error. These rules are added to the draft prompt to guide the LLM to avoid errors during query generation. We mine rules from observed failures, rather than hand-write them. To allow one agent session to cover all failure types, the mining protocol first subsamples the training set. We group questions by the shape of their MATCH clause, the kind of answer that their RETURN clause produces, and the filter, sort, or aggregate operators that the query uses. We keep at most three questions per group as a reduced set, so that failures from one common combination do not dominate the set. Within each group, we greedily select three questions by two ranking priorities. First, we prioritize questions from training graphs not yet included in the group. Second, we select the question that covers the most previously unseen relationship types, labels, and properties. A specific label, relationship type, property, or literal might appears only once across the entire training set. For example, names containing quotes or non-ASCII characters. If the grouping step discards a query, the pattern miner misses any associated failure modes. The miner then never sees a failure involving that rare label, type, property, or literal. Thus, the miner cannot summarize a rule for that failure. We therefore check which of these elements the reduced set misses, and add back questions until that failue pattern is covered. The backbone then drafts a query for each question in this reduced set. We execute every draft, score each result against the gold answer, and keep every failed draft. A generated draft query fails in one of three ways: it triggers an execution error, returns empty results while the gold query returns non-empty rows, or yields a different result multiset. We package each failed draft with diagnostic context: the question, the gold query, the execution outcome, node/relationship labels, and up to three sample result rows from both the draft and the gold query. This context enables the rule miner to inspect error mechanisms directly without querying the database. To mine rules, we dispatch a single session of an LLM agent, claude-opus-4-8 in our experiments, to process the failure set under a fixed prompt(Figure 3). The prompt directs the agent to read every failure, cluster the failures, write one preventive rule per recurring pattern, and sort the rules into the three tiers of Table 3. Each rule identifies the situation in which a mistake arises, explains why the naive query is wrong, and prescribes the corrective pattern. An independent validator checks that every rule follows the runtime’s rule grammar and clears a generality bar. The validator scans each rule for every node label, relationship type, property, and gold entity name of the graphs. In this way, every surviving

Zebin Chen, Dong Wen, Makbule Gulcin Ozsoy, and Wenjie Zhang

Storage-reciprocity statistics · once per graph reciprocity note

GENERATE

Question + 3 few-shot + matched shapes

CORRECT

Draft

1

LLM ×1

rule library · shape bank built before any question

2

Schema Fixes

no LLM

3

Execution Loop

Score LLM ≤3

wrong type → declared type arrow against schema → flipped reciprocal self-loop → directed

tier 1 reverse every arrow literal-grounding probes tier 2 taxonomy rewrite

replaces a pattern that matches no stored edge

keep iff ∅ → rows

live Neo4j EX

88.50

+25.08 vs zero-shot

Figure 2: The three-stage CypherGuard pipeline. Stage 1 (amber), the Draft, receives the full rule library in its prompt. Each of Stages 2–3 (teal) rewrites the query when the deterministic test printed on its dashed arc passes. Family

Failure mode

✗ draft ⇒ ✓ fix

Primarily guarded by

Syntax

unparsable Cypher

taxonomy fix

Direction Schema Entity Pattern Aggregation

edge traversed backwards label/type absent from schema literal ≠ stored value wrong path shape; a hop is missing misuse inflates rows

Filter Return

wrong predicate or operator spurious projection /order / limit

(p:Person] ⇒ (p:Person) -[:directedBy]-> ⇒ <-[:directedBy](:Film) ⇒ (:Movie) ’lincoln’ ⇒ ’Lincoln’ (m)–(m2) ⇒ (m)–(:Person)–(m2) count(p) ⇒ count(DISTINCT p) p.mass_kg>100 ⇒ p.mass_kg>=100 RETURN p ⇒ RETURN p.name

self-loop gate; exec reversal Schema Fixes literal grounding rule library rule library rule library rule library

Table 2: The eight families of CypherGuard’s transferable Cypher error taxonomy. Each row gives a minimal drafted slip (✗), its committed repair (✓), and the guard that primarily catches it, over the running movie and NBA graphs. The full 32 fine-grained codes ship with the release artifact.

rule is written only in generic placeholders. Mining and validation together produce the rule library. One example shows how a failure becomes a rule. Cypher returns one row per complete match of a pattern. Matching a central node against multiple one-to-many relationships in a single MATCH clause creates a Cartesian product of its neighbors. Consequently, each unique pair of neighbors duplicates the central node in the intermediate results. A count(entity) over those rows then tallies path combinations, not entities, silently inflating an answer. The miner reads such failures, finds that they share this one cause, and turns the fix into a rule. The mined rule enforces a three-step pattern: identify the target entity, isolate unique instances using an intermediate WITH DISTINCT, and then perform the aggregation. This ensures the final count() measures unique entities rather than duplicated rows. The library holds rules in three tiers. Universal rules apply whatever the question asks. Schema-conditioned rules apply when the schema declares the feature. Question-shape rules apply when the question’s own wording shows the trigger. Table 3 lists all fourteen rules mined from CypherBench and the fault that each one prevents. Note that a mined rule is not a syntax tip. It states a decision procedure together with the boundary condition that stops the model from over-applying the procedure, and two more rules show what a decision procedure with a boundary condition looks like. C6 in Table 3 covers questions such as “which entities share a trait with 𝑋 ”, where both hops must meet at the same node. A common draft instead writes them as two patterns, (x)–(s1) and (a)–(s2).

Nothing forces s1 and s2 to match and the query returns every a with any neighbor of that kind. The rule reuses one variable across both hops, (x)–(s)–(a), with a boundary condition that keeps 𝑋 in the answer unless the question says “other” or “besides.” C2 covers superlatives. A draft fails silently in two ways: it guesses the sort direction fresh on every question, or it applies an unconditional LIMIT 1. A fresh guess is unreliable, since nothing stops the model from picking the opposite direction the next time a question uses the same word. An unconditional LIMIT 1 then keeps one of the entities that share this extreme value and drops the rest. The rule fixes one direction for each superlative word. A question therefore no longer depends on a guess. The rule’s boundary condition then checks every entity against the computed extreme. If the question asks for all tied results, the query return every entity matching that value. Few-shot and shape exemplars. The rule tells what to avoid. Exemplars show what a good query looks like. We supply two types of exemplars, both injected into the Draft prompt alongside the rules. First, few-shot exemplars carry content. A retriever returns the three train-split questions nearest to the input by embedding similarity [14, 59], each paired with its gold Cypher. The exemplar’s schema never matches the test graph’s. The exemplar’s specific content therefore cannot transfer. However, its clause idioms and pattern shapes can. Second, shape exemplars carry structure alone. They are a small curated bank of twelve idiomatic Cypher skeletons, such as group-by-count and two-hop chain, written in generic

CypherGuard

Table 3: The mined rule library. Rule Universal discipline, in force whatever the question asks A1 Return the columns asked for, and no others A2 Match named things by whole-value equality A3 Deduplicate the answer entity, then project or aggregate A4 Do not filter out null property values A5 Use only declared elements, in minimal patterns

The fault it prevents an extra or missing column, most often a sort key that is also returned substring and paraphrase matching, which pulls in unrelated nodes counts inflated by an entity matching several relationships dropped answer rows, and an empty result when no entity has the value invented syntax, undeclared labels, and unbound relationship variables

Schema-conditioned, applying when the schema declares the feature B1 Follow the schema’s relationship directions a traversal against the stored direction, which matches nothing B2 Unwind list-valued properties nested arrays returned where a flat answer is expected B3 Read membership from relationship time bounds comparing against today’s date, or reading a null end as never existed Question-shape, applying when the wording shows the trigger C1 Counting questions C2 Superlative and top-one questions C3 Either/or across two matches C4 Comparing two named entities C5 Count within each group C6 Shared-neighbor and same-as questions

counting matched rows rather than distinct entities a guessed sort direction, and LIMIT 1 discarding tied entities an OR over null tests where a UNION is needed, which miscounts an extra column leaked by sorting the pair instead of returning a verdict a per-group count taken at the wrong scope, and zero-count groups vanishing two node variables that never meet at the shared node

Rule-mining prompt (condensed)

Draft prompt (stage 1)

TASK. Build an error-prevention rule library for a natural-language-to-Cypher system, by mining the real failures of a bare zero-shot baseline. You work alone, from data. This prompt is your complete specification.

Translate the question to Cypher query based on the schema of a Neo4j knowledge graph.

METHOD. Read every error, not a sample. Cluster by failure mechanism, not by graph or by template id. A mechanism is the property of the prediction that made it wrong and that an instruction could have prevented. Quantify each cluster. Write one rule per mechanism family, merging two mechanisms when a single instruction prevents both, and dropping one-off accidents unless the failure is catastrophic and cheap to prevent. Assign each rule a tier by frequency, harm, and detectability. Use the universal tier for near-universal disciplines whose violation silently corrupts a result, the schema tier when the graph schema determines whether a rule applies, and the question-shape tier when a recognizable surface condition of the question identifies the risk. GENERALITY (hard). Never mention a node label, relationship type, or property name of the training graphs, and never quote an entity name from them. Write examples in placeholder identifiers, labels A/B, relationship REL, property prop. Do not mention the benchmark, the graphs, the baseline model, or file names. A rule must read as a timeless instruction about writing Cypher from natural language. BUDGET. 12–22 rules in total, of which 4–7 are universal, and at most about 200 words per rule body. QUALITY BAR. Optimize for coverage of the observed failures weighted by frequency, for precision, stating each rule’s boundary conditions so that the model does not over-apply it, and for prompt economy. Prefer a rule that states a decision procedure over one that states only a prohibition.

Figure 3: The rule-mining prompt, condensed from the released brief. Tier names follow Table 3.

placeholders such as NodeLabel and relType, and selected by keyword overlap with the question. Figure 4 outlines how the Draft prompt is assembled..

• Output the Cypher query in a single line, without any additional output or explanation. Do not wrap the query with any formatting like ```. • Perform graph pattern matching in the MATCH clause where possible. • Avoid listing the same entity twice. If distinct entities share a name, repeat the name as separate entries. • Do not return node objects. Instead, return entity names or properties. Graph Schema: ⟨ schema ⟩ Question: ⟨ question ⟩ Cypher:

Figure 4: The stage-1 Draft prompt. The quoted instruction is verbatim from the released code, and the labels name the assembled message blocks of Section 3.2.

3.3

Schema Fixes and redirect Self-loop

The rules of Section 3.2 steer the Draft. However, a draft query can still use a relationship type that the schema never declares, and the correct form can be derived from the schema. The Schema Fix rewrite the draft in three steps applied in the order of Algorithm 1. FixRelTypes replaces the undeclared relationship type. AlignDirections reverses the arrow that the schema declares only in the other direction. RedirectSelfLoops makes the undirected self-loop pattern directed when the relationship is stored in both directions. FixRelTypes repairs the wrong relationship type. The schema declares the full set of types. A type outside this set therefore matches no edge in the graph. The algorithm reads the two endpoint labels written around the undeclared type, and replaces the type with the first one that the schema declares between those two labels. Example 3.1. A draft may join Movie to Genre with the type inGenre, which the movie schema never declares. The schema declares type hasGenre between those two labels. The edge is therefore rewritten to it. □

Zebin Chen, Dong Wen, Makbule Gulcin Ozsoy, and Wenjie Zhang

AlignDirections repairs the direction of an edge whose two endpoint labels differ. For each relationship type, the schema records the source label and the target label of its edges. When a path traverses a type from B to A but the schema declares it only from A to B, AlignDirections reverses the drafted arrow. Example 3.2. The movie schema declares directedBy only from Movie to Person. A draft that traverses it from a Person node to a Movie node therefore has its arrow rewritten from -[:directedBy]-> to <-[:directedBy]-. □ RedirectSelfLoops repairs self-loop relationships. A self-loop relationship connects nodes of the same label, such as hasSpouse between two Person entities. A married couple is often stored as two edges. For example, (Alice)-[:hasSpouse]->(Bob) and (Bob)-[:hasSpouse]->(Alice). An undirected drafted pattern over hasSpouse matches both edges for the same couple. A query that counts a person’s spouses therefore returns two rows for the one true spouse. The fault here is a double count. Matching such a relationship with an undirected pattern traverses each edge pair twice and doubles the resulting count. The schema checking module does not distinguishes between source and target labels. Here, we call a relationship is reciprocal when nearly all of its edges exist bi-directionally in the graph. The storage-reciprocity gate rewrites an undirected drafted pattern over a reciprocal relationship into a directed one. Once per graph at initialization, it measures, for each self-loop relationship, the fraction of edges that are also stored in the reverse direction. A relationship counts as reciprocal once that fraction reaches a certain threshold. Example 3.3. The politics graph stores a diplomatic relation as two edges, one in each direction, and the probe finds a matching reverse edge for 95.2% of that type’s edges. An undirected pattern over it reaches each partner twice, doubling a country’s partner count, as in Figure 1. □ A misclassified relationship produces a wrong answer, and since the rewritten query still returns data rather than error messages, the Execution Loop never catches this kind of fault. To our knowledge, the storage-reciprocity gate is the first text-to-Cypher repair where a measured database statistic can be used to decide a rewrite. Prior systems leave that decision to the model (Table 1).

3.4

The Execution Loop

The Schema Fix acts when the schema can be used to determine the answer. The Execution Loop covers the faults that the schema cannot resolve. This module rewrites the draft query when the query returns nothing or raises an error. Algorithm 2 describes the Execution Loop in three parts. Lines 1–9 and line 12 are the two-tier loop. Line 10 is literal grounding. Lines 13–20 are the stopping rules. The two-tier loop. A failed draft query enters a loop at most three iterations. A draft fails when it raises an error or returns no rows. The first tier reverses arrow in the query at once, re-executes, and keeps the flip only if data appear. Tier 1 targets the direction faults that the Schema Fixes above did not already resolve, since re-execution is the only check available for those faults. Tier 1 triggers exclusively on empty results. Drafts raising execution errors bypass the direction flip and proceed directly to Tier 2, as reversing

Algorithm 2 The Execution Loop Require: question 𝑞, query 𝑐, graph 𝐺, budget 𝐿=3 1: seen ← {𝑐}; prev ← none; notes ← ∅ 2: for 𝑖 ← 1 to 𝐿 do 3: (rows, err) ← Execute(𝑐, 𝐺) 4: if rows ≠ ∅ and no err then return 𝑐 5: end if 6: if rows = ∅ and no err then 7: 𝑐 flip ← ReverseAllDirections(𝑐) ⊲ tier 1 8: if Execute(𝑐 flip, 𝐺) ≠ ∅ then return 𝑐 flip 9: end if 10: notes ← ProbeLiterals(𝑐, 𝐺) ⊲ bounded point lookups 11: end if 12: (code, 𝑐 ′ ) ← TaxonomyCorrect(𝑞, 𝑐, err, notes) ⊲ tier 2 13: if 𝑐 ′ is empty or 𝑐 ′ = 𝑐 or 𝑐 ′ ∈ seen then return 𝑐 ⊲ no-change and ping-pong stopping rules 14: end if 15: add 𝑐 ′ to seen 16: if code ≠ none and code = prev then return 𝑐 ′ ⊲ repeated diagnosis, keep newest 17: end if 18: prev ← code; 𝑐 ← 𝑐 ′ 19: end for 20: return 𝑐 Table 4: The eight families of the correction taxonomy. The tier-2 prompt asks the model to name a code from these families before it emits a rewrite. Each family heads several of the 32 fine-grained codes, whose full list ships with the artifact. Code

Family

What it covers

SYN DIR SCH

Syntax Direction Schema

Cypher the engine rejects. Edge traversed against its stored direction. Label, type, or property not in the schema.

ENT PAT AGG FIL RET

Entity Pattern Aggregation Filter Return

Literal matching no stored value. Traversal shape wrong for the question. Wrong grouping, count, or DISTINCT. Over- or under-restrictive predicate. Wrong projection, ordering, or limit.

relationship arrows cannot resolve runtime errors. The second tier calls the model only when the re-execution yields nothing or the draft raises a runtime error, sending it the correction prompt (Figure 5). The model call includes the input question, the failed query, and the execution error. For empty-result failures, the prompt additionally incorporates the literal-grounding notes described below. The prompt requires the model to name a code from the error taxonomy (Table 4), state the cause in one sentence, and then write the corrected query. The named code is kept across iterations and feeds the stopping rules below. Literal grounding. A literal in the query can differ from the stored value, such as a truncated title or a re-cased name does. The query

CypherGuard

Taxonomy-correction prompt (stage 3, tier 2) The call sends two system messages. The first carries the graph schema and, on self-loop graphs, the storage-reciprocity note. The second is an expert-debugger instruction carrying the full 32-code taxonomy (Table 4), for example [DIR.1] reversed direction, [SCH.2] wrong relationship type, [ENT.2] case error, [AGG.3] missing DISTINCT, and [RET.3] wrong ORDER BY/LIMIT. It asks the model to name the primary code, state the root cause in one sentence, and emit the corrected query, in the fixed ERROR: / CAUSE: / FIX: format. Family-specific reminders attach to the instruction, such as checking [DIR.1] against the schema’s relationship list, using only schema names for [SCH.*], and verifying types and directions on any empty result. User message. The question, the failed query, and an error signal: the database error message or, for an empty result, a fixed message that asks the model to re-check relationship types, directions, string-literal case, and property names, followed by the literal-grounding notes described below. On the empty-result branch, the literal-grounding notes described below are appended to that error signal.

Figure 5: The stage-4 tier-2 correction prompt.

takes the word ’United’ and finds the stored ’United States of America’. The note reports ’United States’ as absent, lists the stored ’United States of America’, and asks the correction step to copy it exactly. □ Loop. The rewritten query is re-executed on the next iteration. Three stopping rules end the loop early (Algorithm 2): an empty or unchanged rewrite, a repeated query, or the same error code twice. The first two return the query that the loop currently holds, because the rewrite that they reject is either absent or already tried. The third returns the newest rewritten query, because that rewrite is new and only the model’s diagnosis has repeated.

3.5

4 then matches nothing, and an empty result does not show the model how the value is actually spelled. To solve this problem, CypherGuard grounds query literals against the database. This acts as the Cypher counterpart to text-to-SQL value linking [53]. We ground query literals by extracting literal bindings. A literal binding is a triple (label, property, value) that states which value the query expects on which property of which node type. For example, (:Movie {name:’Lincoln’}) yields the binding (Movie, name, ’Lincoln’). The extraction follows two steps: First, we locate the property and value from inline maps (a property filter written directly inside the node pattern, e.g., {name:’Lincoln’} in (:Movie {name:’Lincoln’})), equality checks, case-insensitive comparisons, or IN lists. Second, we resolve the node label. Inline maps supply their own label, while other filters inherit it from the variable’s declaration (e.g., reading Person from (p:Person) for p.name). If a variable has no declared label, we probe all labels in the database. For each query, we evaluate up to three variable bindings, running at most two verification queries per binding. The first query tests whether any node matches the candidate value exactly on the given property. If this check returns no results, we execute a second query for fuzzy candidates and generate a diagnostic note. This fallback query extracts the longest token from the failed literal and retrieves up to three distinct stored values containing that token as a substring. If candidate values are found, the note presents them and instructs the model to select an exact match. Otherwise, the note reports that no similar values exist, directing the model to reconsider the property key or node label. These diagnostic notes are appended to the repair prompt alongside the failed query. While text-to-SQL systems often maintain precomputed value indices for entity linking, we leave such offline indexing to future work. Example 3.4. A question about films from the United States drafts the filter {name: ’United States’}. Because no country carries that value, the query returns nothing. The second query

Cost budget

The preparation cost is paid once. We mine the rule library and the exemplar corpus from the training split, embed the exemplars for retrieval, and measure the storage-reciprocity statistics on each graph. Answering a question then costs one embedding lookup, one Draft call, and at most 𝐿=3 repair calls. The database work per question is also a small constant. Each loop iteration runs at most two executions, and each repair call adds at most six point probes, two for each of at most three literal bindings.

EXPERIMENTAL SETUP

We evaluate CypherGuard on two execution-scored text-to-Cypher datasets, CypherBench [12] and the Neo4j Text2Cypher dataset [37]. CypherBench. The released test set holds 𝑛=2,348 questions over the seven graphs of Table 5, with train and test graphs disjoint. Neo4j Text2Cypher. We audit the released test split before use and remove three kinds of questions. A gold may fail to execute, may return nothing, or may belong to a set of golds that answer the same question differently. We drop the entire set because none of its members can be verified as correct. We keep 1,003 questions over 11 databases. The few-shot corpus and rule library. The few-shot corpus and the rule library both come only from the train split of the dataset under evaluation. On CypherBench, the corpus holds 8,534 pairs from the four train graphs, and the library is mined from gpt-5.4-mini’s execution failures on those graphs. Exemplars are retrieved from the corpus by cosine similarity over text-embedding-3-small embeddings (Section 3.2). The mining protocol is part of the method (Section 3.2). We run the same protocol on the Neo4j Text2Cypher training split. This produces 13 rules and a case base used to retrieve exemplars. Backbones and runs. Every configuration runs on a fixed backbone, gpt-5.4-mini and claude-sonnet-4.6. The zero-shot baseline sends the official CypherBench zero-shot prompt (schema and question only) to the same model. CypherGuard executes queries on a live Neo4j instance of the graph under test. Every draft’s execution feedback during repair and every reported score therefore come from database execution.

5

MAIN RESULTS

Our evaluation asks four questions: whether the layer beats the same backbone that it wraps, whether each component contributes, whether the few-shot corpus and the rule library, mined from train graphs alone (Section 4), transfer across CypherBench’s seven

Zebin Chen, Dong Wen, Makbule Gulcin Ozsoy, and Wenjie Zhang

Table 5: Results on the released CypherBench test set (𝑛=2,348, seven graphs)

Test graph

𝑛

mini zero-shot

ours

Δ

270 189 385 347 366 401 390

64.44 71.96 51.95 65.99 63.39 69.08 61.79

95.93 98.41 79.48 87.90 91.26 89.78 84.10

+31.49 +26.45 +27.53 +21.91 +27.87 +20.70 +22.31

2,348

63.42

88.50

+25.08

Table 6: Executable rate and PSJS on CypherBench for gpt-5.4-mini, zero-shot and with CypherGuard. Executable % Test graph

nba flight_accident fictional_character company geography movie politics Overall

Published references on the same test set (as reported) gpt-4o-mini, zero-shot [12] 31.43 qwen2.5-72b, zero-shot [12] 41.87 gpt-4o, zero-shot [12] 60.18 claude-3.5-sonnet, zero-shot [12] 61.58 Cypher-RI, 7B RL fine-tuned [50] 69.59 CypherSmith, data-aug. fine-tuned [66] 74.80

ours

zero-shot

ours

270 189 385 347 366 401 390

92.22 93.12 96.36 90.78 95.08 94.26 92.05

100.00 100.00 100.00 99.71 99.73 99.75 99.74

0.809 0.814 0.660 0.772 0.804 0.802 0.793

0.983 0.993 0.901 0.923 0.938 0.935 0.905

2,348

93.52

99.83

0.775

0.933

Test graph nba flight_accident fictional_character company geography movie politics

CypherBench

CypherGuard reaches 88.50% overall EXCB over all 𝑛=2,348 CypherBench test questions, a gain of +25.08% over the same-backbone gpt-5.4-mini zero-shot floor (63.42%) on the identical questions (Table 5). An inference-only layer beats its own backbone by a wide margin on every graph. Section 6 orders the components’ contributions. EXCB are improved on every one of the seven test graphs (Table 5). The per-graph lift ranges from +20.70% on movie to +31.49% on nba. The +25.08% overall gain reflects consistent improvements across graphs rather than an outlier from one graph. Two graphs flight_accident and nba exceed 95%, with 98.41% and 95.93% respectively. fictional_character is the hardest graph for both the zero-shot baseline and CypherGuard. Table 6 reports two metrics per graph for the final query that each system returns: the executable rate (the share of queries that run without a runtime error) and PSJS, the Jaccard similarity between the subgraphs matched by the predicted and by the gold query The zero-shot baseline already executes 93.52% of its queries successfully. Consequently, most of its failures stem from queries that run cleanly but return incorrect results, which aligns with its low PSJS score 0.775. CypherGuard raises the executable rate to 99.83% and PSJS to 0.933, and both gains hold on every graph. Most of the remaining errors are queries that run and return wrong rows (Section 6.4). We also evaluate raw claude-sonnet-4.6 (without CypherGuard), which outperforms standalone gpt-5.4-mini. This comparison tests whether equipping gpt-5.4-mini with CypherGuard allows it to surpass a stronger backbone. Zero-shot sonnet-4.6 reaches 71.76%, which is 16.74% below gpt-5.4-mini with CypherGuard. With CypherGuard, sonnet-4.6’s performance rises to 94.68%—a gain of +22.92%.

zero-shot

Table 7: Comparison on claude-sonnet-4.6.

vocabulary-disjoint evaluation graphs, and what the layer costs per question, in model calls and database work (Section 6.3).

5.1

𝑛

nba flight_accident fictional_character company geography movie politics Overall

PSJS

Overall

𝑛

sonnet zero-shot

ours

Δ

270 189 385 347 366 401 390

73.70 76.19 68.83 73.49 68.58 73.82 70.51

98.15 99.47 94.29 94.52 95.90 95.76 88.21

+24.45 +23.28 +25.46 +21.03 +27.32 +21.94 +17.70

2,348

71.76

94.68

+22.92

Table 8: EX (%) on the Text2Cypher dataset [37]. Backbone gpt-5.4-mini claude-sonnet-4.6

𝑛

zero-shot

ours

Δ

1,003 1,003

47.36 56.63

56.33 62.51

+8.97 +5.88

Table 5 also lists published results on the CypherBench test graphs. The best zero-shot model in the benchmark paper, sonnet-3.5, reaches 61.58% [12]. Cypher-RI, a 7B model fine-tuned with reinforcement learning, reaches 69.59% [50]. CypherSmith, a model fine-tuned on synthesized data, reaches 74.8% [66]. CypherGuard with gpt-5.4-mini exceeds these three results by about 27%, 19%, and 14%, respectively.

5.2

Neo4j Text2Cypher

The same layer runs on the audited Neo4j Text2Cypher test set of Section 4, with the few-shot corpus and the rule library both rebuilt from this dataset’s own train split (Section 4). The layer lifts gpt-5.4-mini from 47.36% to 56.33% and claude-sonnet-4.6 from 56.63% to 62.51% (Table 8). CypherGuard beats the backbone that it wraps in all four dataset-backbone pairs.

6

ABLATIONS AND ANALYSIS

The results of Section 5 establish that the layer works on both datasets. This section asks whether each component contributes, whether the few-shot corpus and the rule library still help on graphs they were never mined from, and whether the gain is just more

CypherGuard

compute, then closes on what still fails. Experiments below were run on CypherBench. Every ablation removes one component and re-runs questions. Each number is therefore the accuracy that component contributes on top of everything else (Table 9).

6.1

Removing a component costs accuracy

Each of the five components corresponds to a row. -exec-loop skips repairing empty or errored drafts. -rules clears all mined rules without altering other components. -few-shot sets 𝑘=0, stripping every train-graph exemplar while the rule library stays active, and -shape removes only the shape exemplars. -literal disables the literal-grounding probes (Section 3.4). Its probes run inside the Execution Loop, and -exec-loop therefore removes them as well. Execution feedback contributes the most. Removing any single component lowers EX. Among them, removing the Execution Loop (-exec-loop) causes the largest drop (10.78%). The remaining ablations demonstrate consistent positive contributions: few-shot exemplars (-few-shot, 6.60%), the rule library (-rules, 4.39%), literal grounding (-literal, 2.34%), and shape exemplars (-shape, 1.24%). This is consistent with text-toSQL self-correction, where execution feedback is a central correction signal [53, 55, 62], or a training reward [64]. By removing one component at a time while keeping the rest intact, we isolate individual stage contributions. We quantify prevention and repair independently rather than confounding their effects. Among the two kinds of exemplars, few-shot exemplars matter far more. Removing them costs more than five times as much as removing shape exemplars. Retrieved gold Cypher supplies complete relational idioms that the rule library lacks, whereas shape exemplars provide only query skeletons, which the rule library might already covers in part.

6.2

The few-shot corpus and rule library transfer

Both the few-shot corpus and the rule library are sourced only from the train graphs (Section 4). Our transfer claim applies only to the few-shot corpus and the rule library. The evidence bears the transfer claim out in every measurement. EXCB improves over the zero-shot floor on all seven graphs (Table 5), and removing the Execution Loop or the few-shot exemplars lowers it on every one of them (Table 9). The Execution Loop and the few-shot exemplars help different graphs. The overall average masks substantial per-graph differences between the two components. The Execution Loop primarily benefits the hardest graphs. It achieves its largest gain on the lowestscoring graph, fictional_character (+20.00%), followed by the third-lowest, company (+12.97%). Only movie (+10.97%) breaks this trend by outgaining the lower-scoring politics (+6.67%). In contrast, few-shot exemplars yield the largest gains on nba (+12.59%) and movie (+10.72%). The rule library transfer across backbones. The rule library is mined from the train graphs. It transfers to new graphs. Removing the rule library lowers EXCB on six of the seven evaluation graphs. It transfers to a larger backbone. We mined the library only from gpt-5.4-mini’s failures. Applied unchanged to sonnet-4.6,

it raises accuracy from 71.76% to 94.68% on all seven graphs (Table 7). The library can therefore be mined once with a smaller model and reused with larger ones.

6.3

Is the gain just more compute?

Pipeline gains are often questioned as merely spending more compute. The call budget is bounded by design. The offline rule mining stage runs only once because mining the rule library requires a single agent session on the baseline’s failures, and the resulting rule library can be reused for subsequent nl2cypher tasks. Each question requires one initial Draft call and at most three repair calls. In contrast, self-consistency voting and multi-path candidate generation scale the number of calls with a configured sampling budget [27, 39, 57].

6.4

Error Analysis at 88.50%

On CypherBench, the complete system fails on 270 out of the 2,348 questions. These residual errors are concentrated unevenly across domains. Over half (52.2%) reside in the two most challenging graphs: fictional_character (79 errors) and politics (62 errors). Non-empty results act as weak verifiers. While an empty result indicates a flawed query, a non-empty result does not guarantee correctness. Our guards trigger only on explicit signals: execution errors, empty outputs, or schema-statistic mismatches. Therefore, a query that executes successfully and returns plausible but incorrect data bypasses all checks. Empty-result triggering is common in text-to-SQL correctors [53, 55], and verifiers designed for executingyet-incorrect queries exist, for example SQLens [15].

7

RELATED WORK

CypherGuard draws on five threads of related work. Natural-language interfaces to data systems. Querying data in natural language predates large language models, through grammarand ontology-driven systems [28, 47] and trainable pipelines [58], with a graph-side lineage in question answering over knowledge graphs [2, 54]. LLMs moved the field to prompting and made text-toSQL a standing subject at data-management venues [24, 26, 30, 59]. Reliability itself has entered that agenda. Adaptive abstention makes text-to-SQL dependable by learning when not to answer, abstaining under a calibrated test and handing those questions back [6]. On the graph database side, whose language surface has just standardized [10, 20], only partial counterparts exist so far, such as schema-based direction correction [25]. Self-correction and execution feedback. A second thread repairs a draft after it is written, from the iterate-with-self-feedback and execution-feedback recipes [7, 33] to text-to-SQL correctors using retry budgets, semantic error taxonomies, trained selection judges, test-driven loops, and critique- or detection-based edits [4, 15, 16, 39, 44, 55, 56, 60, 62]. A persistent finding is that unconditional refinement can introduce new errors. Execution-triggered rewriting is a standard SQL corrector design. Ported to Cypher, its emptyresult trigger does catch one dominant graph fault, a traversal against a schema-directed edge, because that draft matches nothing. It does not catch the fault our motivating example opens with, a

Zebin Chen, Dong Wen, Makbule Gulcin Ozsoy, and Wenjie Zhang

Table 9: Drop-one ablation on the CypherBench (gpt-5.4-mini). Each row removes one component and reports what it contributes. Positive means the component helps that graph. The gain is over the zero-shot floor. nba

flight

fiction

company

geo

movie

politics

Wtd.

the whole layer (zero-shot baseline)

+31.49

+26.45

+27.53

+21.91

+27.87

+20.70

+22.31

+25.08

exec-loop rule library few-shot exemplars shape exemplars -literal‡

+4.81 +0.00 +12.59 +0.37 +0.37

+6.35 +3.17 +2.65 +1.06 +2.65

+20.00 +3.38 +2.34 +0.78 +4.94

+12.97 +5.19 +6.34 +1.44 +2.31

+9.84 +6.83 +4.37 +2.73 +3.83

+10.97 +5.24 +10.72 +3.74 +2.00

+6.67 +5.13 +6.67 −1.79 +0.00

+10.78 +4.39 +6.60 +1.24 +2.34

Component removed

reciprocal relationship matched undirected, whose draft returns rows. Neo4j’s LangChain integration ships a schema-based direction corrector [25]. The loop’s blanket reversal instead covers the orientations the schema leaves open and commits only on a non-empty re-execution. Guiding correction with a structured error catalogue is established in text-to-SQL, as a formal taxonomy [4] and as a database-signal catalogue [15]. Closest to our use of database-side signals, REDSQL refines drafted SQL by consulting the content of the stored database itself [46]. A preventive alternative constrains decoding itself, masking grammar- or schema-invalid tokens during generation [48] or enforcing query templates mined from recurring historical questions [22]. Prompting and skill conditioning. A third thread reshapes the prompt through staged modules with per-difficulty branching, systematic example selection, adaptive agent coordination, and dynamic few-shot selection [14, 40, 53, 59]. A complementary direction conditions on reusable procedural priors, namely MCTS over reasoning trajectories [27] and skill libraries, human-curated or self-evolved [21, 61, 65], Unlike static decomposition prompts, heavyweight per-question agents [3], or skills self-generated from task descriptions, CypherGuard conditions on a small, dataset-agnostic rule library mined by an LLM agent from execution-verified failures on held-out train graphs. A related industrial thread mines reusable knowledge from an agent’s interaction history for one stable enterprise database [8]. Our library is instead mined once from execution failures, applied untuned across seven unseen graphs. Per-item LLM selection of which knowledge to inject is itself established, from reflectiontoken gating in retrieval [1] to skill-retrieval selectors [29, 51] and question-conditioned prompting [60]. Training the generator. A fourth thread trains the generator directly, through execution-based RL rewards or supervised, distillation, and synthetic-data routes [9, 19, 32, 38, 41–43, 45, 49, 63, 64]. The route is reaching Cypher, through synthetic fine-tuning data [66, 67] and an RL-trained 7B specialist [50], but it presupposes supervision that Cypher offers mainly inside benchmark train splits, and the strongest of these trained systems still trails our untrained layer as reported (Table 5). CypherGuard is fully inference-only and treats the generator as fixed. The text-to-Cypher landscape. Cypher is a widely adopted propertygraph language [13], and graph-backed retrieval over knowledge graphs has proven effective for global sensemaking [11]. CypherBench shows even strong proprietary models plateau below saturation while small models collapse [12]. The Text2Cypher baseline

runs a direct generate-and-run pipeline, optionally with schema filtering [34, 37]. R3-NL2GQL coordinates fine-tuned sub-models with knowledge-graph alignment on nGQL [68]. SpCQL and Mind-theQuery build Cypher datasets [5, 17], and SyntheT2C is a syntheticdata framework that ships a smaller medical set [67]. Text2GQLBench adds cross-dialect evaluation [31]. Prior Cypher and GQL work reports error categories without acting on them [12, 52], R3NL2GQL stages generation across fine-tuned sub-models and a large-model refiner [68], and the shipped direction corrector lacks an execution-commit gate [25].

8

CONCLUSION

We presented CypherGuard, a layer that sits between an LLM and a graph database and checks the Cypher queries. The layer first fixes the errors that can be detected from the schema alone. It then runs every query and asks the LLM to rewrite only when the query fails or returns nothing. A repair is accepted only when database verification yields a valid, non-empty result. Both the rule library for query generation and the error taxonomy for repair are derived from the execution failures on training graphs. Across CypherBench test questions, the layer improves gpt-5.4-mini execution accuracy from 63.42% to 88.50% and sonnet-4.6 from 71.76% to 94.68%. Both backbones achieve consistent gains on Neo4j Text2Cypher dataset as well. Our framework currently targets Neo4j Cypher. Remaining errors primarily involve queries that execute without runtime failure but return incorrect rows. Future work includes semantic result validation (beyond non-empty checks) and extending our approach to ISO-GQL.

REFERENCES [1] Akari Asai, Zeqiu Wu, Yizhong Wang, Avirup Sil, and Hannaneh Hajishirzi. 2024. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. In International Conference on Learning Representations (ICLR). [2] Jonathan Berant, Andrew Chou, Roy Frostig, and Percy Liang. 2013. Semantic Parsing on Freebase from Question-Answer Pairs. In Proceedings of the 2013 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics, 1533–1544. [3] Bowen Cao, Weibin Liao, Yushi Sun, Dong Fang, Haitao Li, and Wai Lam. 2026. APEX-SQL: Talking to the data via Agentic Exploration for Text-to-SQL. In Proceedings of the 32nd ACM SIGKDD Conference on Knowledge Discovery and Data Mining V.2 (KDD ’26). Association for Computing Machinery, 234–244. https://doi.org/10.1145/3770855.3818075 arXiv:2602.16720 [4] Saumya Chaturvedi, Aman Chadha, and Laurent Bindschaedler. 2025. SQL-ofThought: Multi-agentic Text-to-SQL with Guided Error Correction. In NeurIPS 2025 DL4C Workshop. arXiv:2509.00581 [5] Vashu Chauhan, Shobhit Raj, Shashank Mujumdar, Avirup Saha, and Anannay Jain. 2025. Mind the Query: A Benchmark Dataset towards Text2Cypher Task. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: Industry Track (EMNLP).

CypherGuard

[6] Kaiwen Chen, Yueting Chen, Nick Koudas, and Xiaohui Yu. 2025. Reliable Textto-SQL with Adaptive Abstention. Proceedings of the ACM on Management of Data 3, 1 (2025), 69:1–69:30. https://doi.org/10.1145/3709719 [7] Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. 2024. Teaching Large Language Models to Self-Debug. In International Conference on Learning Representations (ICLR). arXiv:2304.05128 [8] Zui Chen, Han Li, Xinhao Zhang, Xiaoyu Chen, Chunyin Dong, Yifeng Wang, Xin Cai, Su Zhang, Ziqi Li, Chi Ding, Jinxu Li, Shuai Wang, Dousheng Zhao, Sanhai Gao, and Guangyi Liu. 2025. RUBIKSQL: Lifelong Learning Agentic Knowledge Base as an Industrial NL2SQL System. arXiv:2508.17590 [9] Yaxun Dai, Wenxuan Xie, Xialie Zhuang, Tianyu Yang, Ziyi Liu, Haiqin Yang, Yiying Yang, Yuhang Zhao, Pingfu Chao, and Wenhao Jiang. 2026. ReEx-SQL: Reasoning with Execution-Aware Reinforcement Learning for Text-to-SQL. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, San Diego, California, United States, 824–847. https://doi.org/10.18653/v1/2026. acl-long.35 [10] Alin Deutsch, Nadime Francis, Alastair Green, Keith Hare, Bei Li, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Wim Martens, Jan Michels, Filip Murlak, Stefan Plantikow, Petra Selmer, Oskar van Rest, Hannes Voigt, Domagoj Vrgoč, Mingxi Wu, and Fred Zemke. 2022. Graph Pattern Matching in GQL and SQL/PGQ. In Proceedings of the 2022 International Conference on Management of Data. 2246–2258. https://doi.org/10.1145/3514221.3526057 [11] Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness, and Jonathan Larson. 2024. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. https://doi.org/10.48550/arXiv.2404.16130 arXiv:2404.16130 [cs.CL] [12] Yanlin Feng, Simone Papicchio, and Sajjadur Rahman. 2025. CypherBench: Towards Precise Retrieval over Full-scale Modern Knowledge Graphs in the LLM Era. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (ACL). https://doi.org/10.18653/v1/2025.acl-long.438 [13] Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor. 2018. Cypher: An Evolving Query Language for Property Graphs. In Proceedings of the 2018 International Conference on Management of Data (SIGMOD ’18). Association for Computing Machinery, 1433–1445. https: //doi.org/10.1145/3183713.3190657 [14] Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, and Jingren Zhou. 2024. Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation. Proceedings of the VLDB Endowment (PVLDB) 17, 5 (2024), 1132–1145. https://doi.org/10.14778/3641204.3641221 [15] Yue Gong, Chuan Lei, Xiao Qin, Kapil Vaidya, Balakrishnan Narayanaswamy, and Tim Kraska. 2025. SQLens: An End-to-End Framework for Error Detection and Correction in Text-to-SQL. In Advances in Neural Information Processing Systems (NeurIPS). arXiv:2506.04494 [16] Satya Krishna Gorti, Ilan Gofman, Zhaoyan Liu, Jiapeng Wu, Noël Vouitsis, Guangwei Yu, Jesse C. Cresswell, and Rasa Hosseinzadeh. 2025. MSc-SQL: MultiSample Critiquing Small Language Models For Text-To-SQL Translation. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics (NAACL). arXiv:2410.12916 [17] Aibo Guo, Xinyi Li, Guanchen Xiao, Zhen Tan, and Xiang Zhao. 2022. SpCQL: A Semantic Parsing Dataset for Converting Natural Language into Cypher. In Proceedings of the 31st ACM International Conference on Information and Knowledge Management. 3973–3977. https://doi.org/10.1145/3511808.3557703 [18] Anton Gusarov, Anastasia Volkova, Valentin Khrulkov, Andrey Kuznetsov, Evgenii Maslov, and Ivan Oseledets. 2025. Multi-Agent GraphRAG: A Text-toCypher Framework for Labeled Property Graphs. arXiv:2511.08274 [19] Cong Duy Vu Hoang, Gioacchino Tangari, Clemence Lanfranchi, Dalu Guo, Paul Cayet, Steve Siu, Don Dharmasiri, Yuan-Fang Li, Long Duong, Damien Hilloulin, Rhicheek Patra, Sungpack Hong, and Hassan Chafi. 2025. Distill-C: Enhanced NL2SQL via Distilled Customization with LLMs. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (NAACL), Industry Track. arXiv:2504.00048 [20] ISO/IEC JTC 1/SC 32. 2024. ISO/IEC 39075:2024 Information technology — Database languages — GQL. International Organization for Standardization. https://www.iso.org/standard/76120.html [21] Yanna Jiang, Delong Li, Haiyu Deng, Baihe Ma, Xu Wang, Qin Wang, and Guangsheng Yu. 2026. SoK: Agentic Skills — Beyond Tool Use in LLM Agents. arXiv:2602.20867 [22] Smit Jivani, Sarvam Maheshwari, and Sunita Sarawagi. 2025. Reliable Answers for Recurring Questions: Boosting Text-to-SQL Accuracy with Template Constrained Decoding. Proceedings of the ACM on Management of Data 3, 6, Article 357 (Dec. 2025), 26 pages. https://doi.org/10.1145/3769822 [23] Minseok Jung, Abhas Ricky, and Muhammad Rameez Chatni. 2026. RAS: Reflection-Augmented Scaling with In-Context Learning for Executable Cypher Query Generation. arXiv:2605.22937

[24] George Katsogiannis-Meimarakis and Georgia Koutrika. 2023. A Survey on Deep Learning Approaches for Text-to-SQL. The VLDB Journal 32, 4 (2023), 905–936. https://doi.org/10.1007/s00778-022-00776-8 [25] LangChain AI and Neo4j. 2026. CypherQueryCorrector, in the langchain-neo4j integration package. https://github.com/langchain-ai/langchain-neo4j. Schemabased relationship-direction correction for generated Cypher; v0.10.0, accessed 2026-07-12. [26] Boyan Li, Yuyu Luo, Chengliang Chai, Guoliang Li, and Nan Tang. 2024. The Dawn of Natural Language to SQL: Are We Fully Ready? Proceedings of the VLDB Endowment 17, 11 (2024), 3318–3331. https://doi.org/10.14778/3681954.3682003 [27] Boyan Li, Jiayi Zhang, Ju Fan, Yanwei Xu, Chong Chen, Nan Tang, and Yuyu Luo. 2025. Alpha-SQL: Zero-Shot Text-to-SQL using Monte Carlo Tree Search. In Proceedings of the International Conference on Machine Learning (ICML). arXiv:2502.17248 [28] Fei Li and H. V. Jagadish. 2014. Constructing an Interactive Natural Language Interface for Relational Databases. Proceedings of the VLDB Endowment 8, 1 (2014), 73–84. https://doi.org/10.14778/2735461.2735468 [29] Fangzhou Li, Pagkratios Tagkopoulos, and Ilias Tagkopoulos. 2026. SkillFlow: Scalable and Efficient Agent Skill Retrieval System. In Conference on Language Modeling (COLM). arXiv:2504.06188 [30] Haoyang Li, Jing Zhang, Hanbing Liu, Ju Fan, Xiaokang Zhang, Jun Zhu, Renjie Wei, Hongyan Pan, Cuiping Li, and Hong Chen. 2024. CodeS: Towards Building Open-source Language Models for Text-to-SQL. Proceedings of the ACM on Management of Data 2, 3 (2024), 127:1–127:28. https://doi.org/10.1145/3654930 [31] Songlin Lyu, Lujie Ban, Zihang Wu, Tianqi Luo, Jirong Liu, Chenhao Ma, Yuyu Luo, Nan Tang, Shipeng Qi, Heng Lin, Yongchao Liu, and Chuntao Hong. 2026. Text2GQL-Bench: A Text to Graph Query Language Benchmark [Experiment, Analysis & Benchmark]. arXiv preprint. arXiv:2602.11745 [32] Peixian Ma, Xialie Zhuang, Chengjin Xu, Xuhui Jiang, Ran Chen, and Jian Guo. 2025. SQL-R1: Training Natural Language to SQL Reasoning Model By Reinforcement Learning. In Advances in Neural Information Processing Systems (NeurIPS). arXiv:2504.08600 [33] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, and Peter Clark. 2023. Self-Refine: Iterative Refinement with Self-Feedback. In Advances in Neural Information Processing Systems 36 (NeurIPS 2023). [34] Makbule Gulcin Ozsoy. 2025. Enhancing Text2Cypher with Schema Filtering. In Proceedings of the LLM-TEXT2KG Workshop at the Extended Semantic Web Conference (ESWC). arXiv:2505.05118 [35] Makbule Gulcin Ozsoy. 2025. Explore Iterative Refinement for Text2Cypher. Neo4j Developer Blog. Retrieved October 11, 2026 from https://neo4j.com/blog/ developer/iterative-refinement-for-text2cypher/ Published October 3, 2025. [36] Makbule Gulcin Ozsoy. 2026. Extending Confidence-Based Text2Cypher with Grammar and Schema Aware Filtering. arXiv:2605.10318 [37] Makbule Gulcin Ozsoy, Leila Messallem, Jon Besga, and Gianandrea Minneci. 2025. Text2Cypher: Bridging Natural Language and Graph Databases. In Proceedings of the Workshop on Generative AI and Knowledge Graphs (GenAIK). International Committee on Computational Linguistics, Abu Dhabi, UAE, 100–108. arXiv:2412.10064 https://aclanthology.org/2025.genaik-1.11/ [38] Simone Papicchio, Simone Rossi, Luca Cagliero, and Paolo Papotti. 2026. Think2SQL: Blueprinting Reward Density and Advantage Scaling for Effective Text-to-SQL Reasoning. Transactions on Machine Learning Research (2026). https://openreview.net/forum?id=NxU1KWnpOG [39] Mohammadreza Pourreza, Hailong Li, Ruoxi Sun, Yeounoh Chung, Shayan Talaei, Gaurav Tarlok Kakkar, Yu Gan, Amin Saberi, Fatma Ozcan, and Sercan O. Arik. 2025. CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL. In International Conference on Learning Representations (ICLR). arXiv:2410.01943 [40] Mohammadreza Pourreza and Davood Rafiei. 2023. DIN-SQL: Decomposed InContext Learning of Text-to-SQL with Self-Correction. In Advances in Neural Information Processing Systems (NeurIPS). arXiv:2304.11015 [41] Mohammadreza Pourreza and Davood Rafiei. 2024. DTS-SQL: Decomposed Text-to-SQL with Small Large Language Models. In Findings of the Association for Computational Linguistics: EMNLP 2024. arXiv:2402.01117 [42] Mohammadreza Pourreza, Shayan Talaei, Ruoxi Sun, Xingchen Wan, Hailong Li, Azalia Mirhoseini, Amin Saberi, and Sercan Ö. Arık. 2025. Reasoning-SQL: Reinforcement Learning with SQL Tailored Partial Rewards for Reasoning-Enhanced Text-to-SQL. In Conference on Language Modeling (COLM). arXiv:2503.23157 [43] Yang Qin, Chao Chen, Zhihang Fu, Ze Chen, Dezhong Peng, Peng Hu, and Jieping Ye. 2025. ROUTE: Robust Multitask Tuning and Collaboration for Text-to-SQL. In International Conference on Learning Representations (ICLR). arXiv:2412.10138 [44] Ge Qu, Jinyang Li, Bowen Qin, Xiaolong Li, Nan Huo, Chenhao Ma, and Reynold Cheng. 2025. SHARE: An SLM-based Hierarchical Action CorREction Assistant for Text-to-SQL. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (ACL). arXiv:2506.00391

Zebin Chen, Dong Wen, Makbule Gulcin Ozsoy, and Wenjie Zhang

[45] Alicja Rączkowska, Riccardo Belluzzo, Piotr Zieliński, Joanna Baran, and Paweł Olszewski. 2026. RetrySQL: Text-to-SQL Training with Retry Data for SelfCorrecting Query Generation. In Proceedings of the AAAI Conference on Artificial Intelligence (AAAI). [46] Tonghui Ren, Chen Ke, Yuankai Fan, Yinan Jing, Zhenying He, Kai Zhang, and X. Sean Wang. 2025. The Power of Constraints in Natural Language to SQL Translation. Proceedings of the VLDB Endowment 18, 7 (2025), 2097–2111. https: //doi.org/10.14778/3734839.3734847 [47] Diptikalyan Saha, Avrilia Floratou, Karthik Sankaranarayanan, Umar Farooq Minhas, Ashish R. Mittal, and Fatma Özcan. 2016. ATHENA: An OntologyDriven System for Natural Language Querying over Relational Data Stores. Proceedings of the VLDB Endowment 9, 12 (2016), 1209–1220. https://doi.org/10. 14778/2994509.2994536 [48] Torsten Scholak, Nathan Schucher, and Dzmitry Bahdanau. 2021. PICARD: Parsing Incrementally for Constrained Auto-Regressive Decoding from Language Models. In Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics, 9895–9901. https://doi.org/10.18653/v1/2021.emnlp-main.779 [49] Lei Sheng and Shuai-Shuai Xu. 2025. CSC-SQL: Corrective Self-Consistency in Text-to-SQL via Reinforcement Learning. In Findings of the Association for Computational Linguistics: IJCNLP-AACL 2025. arXiv:2505.13271 [50] Hanchen Su, Xuyuan Li, Yan Zhou, Zhuoyi Lu, Ziwei Chai, Haozheng Wang, Chen Zhang, and Yang Yang. 2025. Cypher-RI: Reinforcement Learning for Integrating Schema Selection into Cypher Generation. In Advances in Neural Information Processing Systems (NeurIPS). [51] Weihang Su, Jianming Long, Qingyao Ai, Qiaozhi He, Yichen Tang, Changyue Wang, Yiteng Tu, Yingbo Wang, and Yiqun Liu. 2026. Skill Retrieval Augmentation for Agentic AI. arXiv:2604.24594 [52] Yanning Su, Yuhang Zhou, Yang Fang, Sen Liu, Guangnan Ye, and Hongfeng Chai. 2026. GQLBench: A Large-Scale Cross-Domain, Cross-Dialect Benchmark for NL2GQL. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (ACL). [53] Shayan Talaei, Mohammadreza Pourreza, Yu-Chen Chang, Azalia Mirhoseini, and Amin Saberi. 2024. CHESS: Contextual Harnessing for Efficient SQL Synthesis. arXiv preprint arXiv:2405.16755 (2024). [54] Christina Unger, Lorenz Bühmann, Jens Lehmann, Axel-Cyrille Ngonga Ngomo, Daniel Gerber, and Philipp Cimiano. 2012. Template-based Question Answering over RDF Data. In Proceedings of the 21st International Conference on World Wide Web (WWW). ACM, 639–648. https://doi.org/10.1145/2187836.2187923 [55] Bing Wang, Changyu Ren, Jian Yang, Xinnian Liang, Jiaqi Bai, Linzheng Chai, Zhao Yan, Qian-Wen Zhang, Di Yin, Xing Sun, and Zhoujun Li. 2025. MACSQL: A Multi-Agent Collaborative Framework for Text-to-SQL. In Proceedings of the 31st International Conference on Computational Linguistics (COLING). arXiv:2312.11242 [56] Dingzirui Wang, Longxu Dou, Xuanliang Zhang, Qingfu Zhu, and Wanxiang Che. 2025. DAC: Decomposed Automation Correction for Text-to-SQL. In Findings of the Association for Computational Linguistics: EMNLP 2025. arXiv:2408.08779 [57] Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc Le, Ed H. Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. 2023. Self-Consistency Improves Chain of Thought Reasoning in Language Models. In The Eleventh International Conference on Learning Representations (ICLR). arXiv:2203.11171. [58] Nathaniel Weir, Prasetya Ajie Utama, Alex Galakatos, Andrew Crotty, Amir Ilkhechi, Shekar Ramaswamy, Rohin Bhushan, Nadja Geisler, Benjamin Hättasch, Steffen Eger, Ugur Çetintemel, and Carsten Binnig. 2020. DBPal: A Fully Pluggable NL2SQL Training Pipeline. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. 2347–2361. https: //doi.org/10.1145/3318464.3380589 [59] Xiangjin Xie, Guangwei Xu, LingYan Zhao, and Ruijie Guo. 2025. OpenSearchSQL: Enhancing Text-to-SQL with Dynamic Few-shot and Consistency Alignment. In Proceedings of the ACM on Management of Data (SIGMOD). https: //doi.org/10.1145/3725331 [60] Yuanzhen Xie, Xinzhou Jin, Tao Xie, Mingxiong Lin, Liang Chen, Chenyun Yu, Lei Cheng, Chengxiang Zhuo, Bo Hu, and Zang Li. 2024. Decomposition for Enhancing Attention: Improving LLM-based Text-to-SQL through Workflow Paradigm. In Findings of the Association for Computational Linguistics: ACL 2024. arXiv:2402.10671 [61] Renjun Xu and Yang Yan. 2026. Agent Skills for Large Language Models: Architecture, Acquisition, Security, and the Path Forward. arXiv:2602.12430 [62] Wenbo Xu, Haifeng Zhu, Liang Yan, Chuanyi Liu, Peiyi Han, Shaoming Duan, and Jeff Z. Pan. 2025. TS-SQL: Test-driven Self-refinement for Text-to-SQL. In Findings of the Association for Computational Linguistics: EMNLP 2025. [63] Zhewei Yao, Guoheng Sun, Łukasz Borchmann, Zheyu Shen, Minghang Deng, Bohan Zhai, Hao Zhang, Ang Li, and Yuxiong He. 2026. Arctic-Text2SQLR1: Simple Rewards, Strong Reasoning in Text-to-SQL. In Findings of the Association for Computational Linguistics: ACL 2026. Association for Computational Linguistics, San Diego, California, United States, 26966–26995. https: //doi.org/10.18653/v1/2026.findings-acl.1345

[64] Bohan Zhai, Canwen Xu, Yuxiong He, and Zhewei Yao. 2025. Optimizing Reasoning for Text-to-SQL with Execution Feedback. In Findings of the Association for Computational Linguistics: ACL 2025. arXiv:2503.19988 [65] Hanrong Zhang, Shicheng Fan, Henry Peng Zou, Yankai Chen, Zhenting Wang, Jiayu Zhou, Chengze Li, Wei-Chieh Huang, Yifei Yao, Kening Zheng, Xue Liu, Xiaoxiao Li, and Philip S. Yu. 2026. CoEvoSkills: Self-Evolving Agent Skills via Co-Evolutionary Verification. In Conference on Language Modeling (COLM). arXiv:2604.01687 [66] Zeyu Zhang, Kexuan Sun, Zheng Tang, Jens Voeckler, Thien Huu Nguyen, and Thuy Vu. 2026. CypherSmith: Transforming Text-to-Cypher Generation for LLMs with Synthetic Data. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (ACL). [67] Zijie Zhong, Linqing Zhong, Zhaoze Sun, Qingyun Jin, Zengchang Qin, and Xiaofan Zhang. 2025. SyntheT2C: Generating Synthetic Data for Fine-Tuning Large Language Models on the Text2Cypher Task. In Proceedings of the 31st International Conference on Computational Linguistics (COLING). Association for Computational Linguistics, Abu Dhabi, UAE, 672–692. arXiv:2406.10710 https://aclanthology.org/2025.coling-main.46/ [68] Yuhang Zhou, Yu He, Siyu Tian, Yuchen Ni, Zhangyue Yin, Xiang Liu, Chuanjun Ji, Sen Liu, Xipeng Qiu, Guangnan Ye, and Hongfeng Chai. 2024. R3NL2GQL: A Model Coordination and Knowledge Graph Alignment Approach for NL2GQL. In Findings of the Association for Computational Linguistics: EMNLP 2024. arXiv:2311.01862

Related documents

• CypherGuard: Database-Grounded Correction for Reliable Text-to-Cypher#1535077
• Approximate querying for the Property Graph Language Cypher#444561
• SPARQL-LLM in the TEXT2SPARQL 2026 Challenge#1298144
• Addressing the Reasoning Gap: Mechanistic Circuit-Based Knowledge Editing in Large Language Models#677553
• Addressing the Reasoning Gap: Mechanistic Circuit-Based Knowledge Editing in Large Language Models#674354