Enhancing Accuracy and Maintainability in Nuclear Plant Data Retrieval: A Function-Calling LLM Approach Over NL-to-SQL

Dave Mercier; Issam Hammad; Mark Randall; Mishca de Costa; Muhammad Anwar

REVIEW 4 major objections 4 minor 2 cited by

Enhancing Accuracy and Maintainability in Nuclear Plant Data Retrieval: A Function-Calling LLM Approach Over NL-to-SQL

T0 review · 4 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Function-calling LLMs that select pre-approved SQL functions beat direct natural-language-to-SQL generation for nuclear plant queries.

desk verdict A sensible applied pattern with honest engineering detail, but the evaluation is too sparse to back the accuracy claim and the maintainability claim is unmeasured. read the letter →

arxiv 2506.08757 v1 pith:G5FDFY23 submitted 2025-06-10 cs.CL cs.LG

Mishca de Costa , Muhammad Anwar , Dave Mercier , Mark Randall , Issam Hammad This is my paper

classification cs.CLcs.LG

keywords function-callingLLMNL-to-SQLnuclearplantdataretrievallegacydatabasesmulti-agentworkflowSQLvalidationretrieval-augmentedgenerationmaintainability

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that natural-language-to-SQL generation is the wrong interface for critical nuclear plant data retrieval because users cannot validate the generated SQL and the legacy databases are complex. It proposes instead a function-calling system in which an LLM routes a user's question to predefined, expert-validated functions that encapsulate the only SQL queries allowed. The authors report that human-scored correctness is notably higher for this function-calling method than for a comparable system that generates SQL directly, while LLM-computed relevance and faithfulness scores are nearly identical. If the finding holds, organizations with safety-critical legacy databases can get the flexibility of natural-language querying without surrendering control of the underlying SQL. The trade-off is an upfront and ongoing cost of building and maintaining the function library.

What carries the argument

The load-bearing object is the function library: a set of pre-approved, purpose-specific functions, each encapsulating reviewed and optimized SQL for a common request type such as work orders or stock levels. Around it sits a multi-agent workflow in which a main agent decides whether a query needs data retrieval, routes it to the appropriate sub-agent, and the sub-agent selects and executes one of its functions, with typed schema validation on every parameter, constrained decoding for structured outputs, automatic retries when the wrong function or agent is chosen, and full logging of each step. The comparison baseline replaces this library with a retrieval-augmented generator that extracts intent, retrieves example queries, validates table and field names against a schema store, and generates new SQL when no example matches. The key contrast is that the function-calling method moves all SQL authoring out of generation time and into expert review time.

What would settle it

Ask plant operators who never saw the function library to write a fresh set of queries, including some request types the library was not designed for, and have SMEs score both systems blind; if the function-calling system no longer outperforms the NL-to-SQL baseline on human-evaluated correctness, the reported advantage is an artifact of overlapping test questions and functions.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central discovery is that the reliability bottleneck in NL-to-SQL over legacy plant databases is not the LLM's language understanding but the unrestricted generation of SQL, and that replacing that step with function selection removes most of the failure modes. In the evaluated system, the function-calling workflow routes queries through domain-specific sub-agents that can only invoke pre-approved functions; the non-function-calling baseline uses intent extraction, retrieval of example queries, and schema validation to build SQL from scratch. Human experts scored the function-calling outputs substantially higher, and question-by-question results show the baseline frequently produced entirely incorrect answers while the function-calling method was consistently correct or partially correct. The paper presents this as evidence that constraining SQL to validated functions improves accuracy and maintainability, at the cost of building the function library, and notes that NL-to-SQL tools can help generate initial function code for experts to validate.

Load-bearing premise

The evaluation set is assumed to resemble real operator queries and not to be drawn mainly from the same pre-approved function library that the function-calling system was built around.

Editorial extensions

If this is right

Operators can ask natural-language questions while the system only executes SQL that experts have already reviewed, reducing the risk of hallucinated or unsafe queries.
The upfront function-library cost can be partly offset by using NL-to-SQL tools to draft initial function code, with experts concentrating on validation rather than creation.
Systems with fewer than 70-billion-parameter models will struggle to combine conversation and function calling, so deployments should budget for larger models or specialized ones.
Retrieval-based filtering of the available functions should improve selection accuracy, since performance degrades when the LLM is offered too many tools.
Handling chained queries that require multiple function calls in sequence is not supported in the current version and is planned as future work with reasoning models.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A reader might infer that the accuracy gap would shrink on queries whose intent lies outside the existing function library, because the baseline can generate new SQL while the function-calling system is limited to pre-approved capabilities.
The maintainability claim carries a hidden cost: if real operator questions invent new patterns faster than experts can add functions, library upkeep could outweigh the savings in validation effort.
The paper's evidence that function-selection accuracy drops as tool count grows suggests a concrete test: measure selection accuracy on the same plant queries with and without retrieval-based filtering of the function library.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

Here's my read on arXiv:2506.08757. It's an applied systems paper from Ontario Power Generation comparing two ways to let plant staff query legacy nuclear databases in natural language: direct NL-to-SQL with RAG, and a function-calling approach where the LLM selects among pre-approved, expert-validated functions that wrap SQL. The core idea is sound and not new in general—function calling is established—but the application to this regulated setting with a curated function library is a reasonable contribution.

What the paper does well: the architecture is described clearly, the authors deliberately used the same GPT-4o model for both systems to isolate the method, and they are candid about limitations—smaller models struggle with function calling, tool overload degrades selection, chained queries aren't supported yet. The human-evaluated correctness scores by SMEs give some independent signal that the function-calling system produces more acceptable answers; that is the strongest piece of evidence.

The soft spots are real and concentrated in the evaluation. There is no test set size, no description of how the evaluation queries were selected, no sample of queries shown, no error bars or statistical tests. The maintainability claim in the conclusion is asserted but never measured; no function library size, no update-cost comparison. The LLM-computed metrics are similar for both systems and those are produced by the same model family, so they don't discriminate. The circularity concern is legitimate: if the test questions were drawn from the use cases the function library was built to cover, the comparison is partly baked in. The paper never tells us. I don't think the human SME scores are worthless—they do favor the function-calling system—but without knowing the test distribution, the magnitude of the claimed improvement is uninterpretable.

Who gets value from this paper: practitioners designing LLM front-ends for legacy databases in safety-constrained industries. It's a useful case study of what breaks in practice (jargon, retries, agent routing). It is not a rigorous research contribution; the evaluation would need serious strengthening to support the stated claims.

I'd send it to peer review because the systems design is coherent and the domain is under-served, but I would make the authors disclose the test set, sample size, selection procedure, and add at least one objective maintainability measure. As is, I'd treat the accuracy claim as plausible but unproven, and the maintainability claim as a proposal.

Recommendation: engage with it if you're working on enterprise NL-to-SQL with legacy schemas; otherwise a skim suffices.

Referee Report

4 major / 4 minor

Summary. The paper proposes a function-calling LLM architecture for retrieving operational data from nuclear plant databases, as an alternative to direct NL-to-SQL generation. The system routes user queries to sub-agents that select among pre-approved, expert-validated functions, each encapsulating fixed SQL logic. The authors compare this approach with a non-function-calling NL-to-SQL system using LLM-computed metrics (Answer Relevance, Relevance, Faithfulness) and human SME-evaluated correctness, reporting higher correctness for the function-calling approach. The conclusion claims improvements in both accuracy and maintainability.

Significance. If the reported results are robust, the function-calling paradigm is a practically valuable contribution to data retrieval in safety-critical domains: it reduces the risk of unvalidated SQL generation, enables expert oversight, and is architecturally transparent. A clear strength is that the same LLM (GPT-4o) is used in both systems, which isolates the effect of the function-calling wrapper. The human SME evaluation is also a step in the right direction, as it provides a non-LLM ground truth for correctness. However, the significance is presently limited by severe under-specification of the evaluation, and the maintainability claim has no supporting measurement at all.

major comments (4)

[4.5] The evaluation section provides no test set size, no query-selection procedure, and no error bars or statistical tests. Figures 3–5 report only average scores and a qualitative per-question comparison. Without knowing the number of queries, how they were chosen, and whether they overlap with the function library's design examples, the human-evaluated correctness advantage reported in Section 4.5.2 cannot be interpreted as evidence of general superiority. Please report the number of queries, the selection/construction process, and the per-query results with a paired significance test or confidence intervals.
[5] The central claim of improved system maintainability is not supported by any measurement in the manuscript. No function-library size, update-cost comparison, maintenance metric, or qualitative maintenance-log analysis is reported. Either add a quantitative or well-defined qualitative maintainability evaluation (for example, time and effort required to add a new query type, or the frequency of function updates) or explicitly frame maintainability as a design hypothesis rather than an evaluated result.
[4.5.1] The LLM-computed metrics (Answer Relevance, Relevance, Faithfulness) are not described with respect to which model computed them, the prompt design, or any validation against human judgments. Since the system under test is the same model family (GPT-4o), these metrics are likely to reflect the LLM's own response-generation bias rather than an independent quality assessment. The manuscript should state the metric model, provide evidence that the metric prompts are reliable, and ideally calibrate the LLM metrics against a human-annotated subset.
[4.5 and 3.1] The potential circularity of the evaluation is not addressed. The function library is built by the authors to cover known use cases (Section 3.1), and the test queries are not disclosed. If the evaluation questions were drawn from the same use cases used to design the function library, the function-calling approach would trivially outperform NL-to-SQL, which must generalize from the schema alone. Please disclose the relationship between the test set and the function-library design, and ideally include held-out query types that are not directly supported by an existing function.

minor comments (4)

[Abstract] The abstract contains a typographical artifact: "dat a" appears with an extra space in the phrase "Retrieving operational data from nuclear power plants." Please correct it.
[2.1] The text says "A comprehensive and quantitative assessment of function-calling performance is documented in the literature review section below," but the literature review appears in the Introduction (Section 1), not below Section 2.1. Please fix the cross-reference.
[4.5.2] Figure 5 is described as showing "detailed scores per question," but the manuscript does not include the per-question data in a machine-readable table or appendix. Adding the per-question scores, or at least the number of questions and the distribution of scores, would allow readers to verify the reported advantage.
[References] The reference formatting is inconsistent: some entries include author lists, some include only a title and URL, and the access-date style varies. Please unify the reference style according to the conference template.

Circularity Check

0 steps flagged · score 0.0 of 10

No demonstrated circularity; the empirical comparison rests on SME scoring and external benchmarks, though the undisclosed test set is an evidence-quality concern, not a circular reduction.

full rationale

The paper's chain of evidence is an empirical comparison between a function-calling architecture and an NL-to-SQL baseline, both using GPT-4o. The central claim of improved accuracy and maintainability is supported by human SME correctness scores in Section 4.5.2 and by the architecture's design of pre-validated functions. No step reduces by construction to its own inputs: the function library is defined from common use cases, the SME judges score answers against a human-curated ground truth using the scale in Table 1, and the same LLM is used for both systems, isolating the method comparison. The cited references are external function-calling benchmarks (BFCL, Gorilla, AgentBench) and are not used to define the paper's own result. The main weakness is evidentiary, not circular: Section 4.5 reports average scores and per-question details but does not state how evaluation queries were selected, their sample size, or whether they represent real operational use, and no maintainability metric is reported in Section 5. If the test questions were drawn from the function library's own use cases, the comparison would be biased, but the paper does not state this, so a specific circular reduction cannot be exhibited without speculation. Under the hard rule requiring quoted evidence of a reduction, the honest finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The central claim depends on the validity and coverage of the curated function library, on the LLM's function-selection reliability, and on the representativeness of an unspecified evaluation set. No numeric free parameters are fitted.

assumptions (5)

domain assumption Pre-approved functions correctly encapsulate the valid SQL logic for the covered use cases.
The system's safety argument rests on the expert review of these functions; the paper does not describe how the function library was validated or how complete it is. Invoked throughout Section 3.1.
domain assumption The LLM will select the correct function and fill parameters correctly when given the system prompts.
The evaluation relies on this; Section 2.4 describes retries when the model misroutes, implying selection is not guaranteed. Section 4.5.2 reports partial correctness.
domain assumption The evaluation test set is representative of real operational queries and not biased toward the curated functions.
No test set details are given in Section 4.5; this is the load-bearing premise for the comparison.
domain assumption LLM-computed quality metrics are valid proxies for answer quality.
Section 4.5.1 uses GPT-4o to score relevance and faithfulness without validating the judge.
domain assumption Using the same underlying model (GPT-4o) in both systems isolates the effect of the function-calling architecture.
Section 3.3 states this, but model-specific biases could still affect both systems differently.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Enhancing Accuracy and Maintainability in Nuclear Plant Data Retrieval: A Function-Calling LLM Approach Over NL-to-SQL." pith.science (2026). https://pith.science/paper/G5FDFY23

@misc{pith2026250608757,
  author       = {Pith},
  title        = {Pith review of: Enhancing Accuracy and Maintainability in Nuclear Plant Data Retrieval: A Function-Calling LLM Approach Over NL-to-SQL},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/G5FDFY23}},
  note         = {Machine review of arXiv:2506.08757}
}

read the original abstract

Retrieving operational data from nuclear power plants requires exceptional accuracy and transparency due to the criticality of the decisions it supports. Traditionally, natural language to SQL (NL-to-SQL) approaches have been explored for querying such data. While NL-to-SQL promises ease of use, it poses significant risks: end-users cannot easily validate generated SQL queries, and legacy nuclear plant databases -- often complex and poorly structured -- complicate query generation due to decades of incremental modifications. These challenges increase the likelihood of inaccuracies and reduce trust in the approach. In this work, we propose an alternative paradigm: leveraging function-calling large language models (LLMs) to address these challenges. Instead of directly generating SQL queries, we define a set of pre-approved, purpose-specific functions representing common use cases. Queries are processed by invoking these functions, which encapsulate validated SQL logic. This hybrid approach mitigates the risks associated with direct NL-to-SQL translations by ensuring that SQL queries are reviewed and optimized by experts before deployment. While this strategy introduces the upfront cost of developing and maintaining the function library, we demonstrate how NL-to-SQL tools can assist in the initial generation of function code, allowing experts to focus on validation rather than creation. Our study includes a performance comparison between direct NL-to-SQL generation and the proposed function-based approach, highlighting improvements in accuracy and maintainability. This work underscores the importance of balancing user accessibility with operational safety and provides a novel, actionable framework for robust data retrieval in critical systems.

Figures

Figures reproduced from arXiv: 2506.08757 by the authors.

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

AI-Assisted Knowledge Access for Legacy Enterprise Asset Management in Energy Operations: A Practical Retrieval System
cs.IR 2026-06 conditional novelty 4.0 of 10

A semantic-enrichment-based retrieval assistant improved retrieval quality and cut median task time from 14.2 to 8.3 minutes for legacy asset-management knowledge tasks in an energy utility pilot.
From Naive RAG to Deep Agentic Retrieval: An Evolving Context Engineering Pipeline for Regulatory Compliance
cs.IR 2026-06 conditional novelty 3.0 of 10

OPG's production RAG system evolved into a cost-aware multi-agent retrieval pipeline (PEA-CAE), which the authors argue is a better investment than fine-tuning for evolving regulatory corpora.

Reference graph

Works this paper leans on

21 extracted references · 16 canonical work pages · cited by 2 Pith papers

[1]

Traditional NL-to-SQL methods, while user-friendly, introduce risks when handling complex legacy databases

Introduction Operational data retrieval in nuclear power plants demands unparalleled accuracy and transparency due to its critical impact on decision-making. Traditional NL-to-SQL methods, while user-friendly, introduce risks when handling complex legacy databases. This paper introduces a function-calling LLM approach that leverages pre -approved, purpose...

work page 2024
[2]

What day is it today?

Challenges We faced several technical challenges that influenced our methodology. This section discusses these challenges, and the approaches considered to solve them. 2.1 Agentic/Autonomous Behaviour The objective of our function -calling structured SQL method is to minimize autonomous behavior by providing explicit instructions to agents on the necessar...

work page 2025
[3]

main agent

Final Methodology In this paper we discuss the methodology used for a function calling SQL retrieval agentic workflow. This system is not fully agentic as the agents are not given full autonomy to make decisions, this is a workflow process where each agent is guided by spec ific rules and structure in terms of when they get called and in what order. 5 44t...

work page 2025
[4]

Show me all the work requests entered in by John Smith

Receive User Query: The program starts by taking a user’s natural language question (for example, “Show me all the work requests entered in by John Smith")

work page
[5]

Extract Query Intent: The application calls an intent extraction agent that analyzes the query to determine the user’s intent and key entities (like tables, fields, conditions, and work areas)

work page
[6]

7 44th Annual CNS Conference and the 49th Annual CNS/CNA Student Conference Westin Harbour Castle Hotel, Toronto, ON, Canada, June 8-11, 2025 a

Retrieve Example Queries: Using the extracted intent as context, the system retrieves similar or relevant example queries from a vector-based search index. 7 44th Annual CNS Conference and the 49th Annual CNS/CNA Student Conference Westin Harbour Castle Hotel, Toronto, ON, Canada, June 8-11, 2025 a. Decision Point: If one of the examples closely matches t...

work page 2025
[7]

This query also comes with an explanation of how it was built

Generate Initial SQL Query: Based on the chosen path, an initial SQL query is constructed. This query also comes with an explanation of how it was built

work page
[8]

Any discrepancies are corrected so that the query conforms to the expected format and contains only valid tables and fields

Validate SQL Query: The initial SQL query is then passed to a validation agent that cross-checks the table and field names against the system’s schema (stored in a vector database). Any discrepancies are corrected so that the query conforms to the expected format and contains only valid tables and fields

work page

Show all 21 references

[9]

Execute SQL Query: The system then executes the validated SQL query , and results are retrieved and converted to JSON for further processing
[10]

Figure 2 – Non-Function Calling Approach Flowdiagram 3.3 Model Selection For this project we used OpenAI’s GPT-4o model

Generate User-Friendly Answer: Finally, an agent uses the query results to generate a concise, clear answer that directly addresses the original question. Figure 2 – Non-Function Calling Approach Flowdiagram 3.3 Model Selection For this project we used OpenAI’s GPT-4o model. A...
[11]

Evaluation In order to evaluate the performance of our proposed function calling methodology, we evaluate the outputs of our two models against various factors. 8 44th Annual CNS Conference and the 49th Annual CNS/CNA Student Conference Westin Harbour Castle Hotel, Toronto, ON...

2025
[12]

By constraining SQL generation through validated functions and structured agent workflows, the fr amework minimizes risks and bolsters operational safety

Conclusion and Future Work The proposed function -calling methodology demonstrates clear improvements in accuracy and system maintainability compared to traditional NL-to-SQL approaches. By constraining SQL generation through validated functions and structured agent workflows,...

2025
[13]

Acknowledgments This research paper was supported by Ontario Power Generation (OPG) and by The Natural Sciences and Engineering Research Council of Canada (NSERC) and The Canadian Nuclear Safety Commission (CNSC) grant number ALLRP 580442-2022

2022
[14]

Model Cards and Prompt Formats: Llama3_1,

Llama, “Model Cards and Prompt Formats: Llama3_1,” Llama Documentation, [Online]. Available: https://www.llama.com/docs/model-cards-and-prompt-formats/llama3_1/. [Accessed: Feb. 26, 2025]

2025
[15]

Introducing Structured Outputs in the API

OpenAI, “Introducing Structured Outputs in the API”, [Online]. Available: https://openai.com/index/introducing-structured-outputs-in-the-api/. [Accessed: Feb. 26, 2025]

2025
[16]

Berkeley Function-Calling Leaderboard V3

F. Yan, H. Mao, C.C.-J. Ji, T. Zhang, S.G. Patil, I. Stoica, and J.E. Gonzalez, Gorilla LLM, “Berkeley Function-Calling Leaderboard V3”, [Online]. Available: https://gorilla.cs.berkeley.edu/blogs/8_berkeley_function_calling_leaderboard.html. [Accessed: Feb. 27, 2025]

2025
[17]

ToolACE: Winning the Points of LLM Function Calling,

W. Liu, X. Huang, X. Zeng, et al., “ToolACE: Winning the Points of LLM Function Calling,” in Proc. Int. Conf. Learn. Representations (ICLR), 2025 (poster). [Online]. Available: https://arxiv.org/abs/2409.00920. [Accessed: Feb. 27, 2025]

2025 arXiv
[18]

HammerBench: Fine-Grained Function-Calling Evaluation in Real Mobile Device Scenarios,

J. Wang, J. Zhou, M. Wen, et al., “HammerBench: Fine-Grained Function-Calling Evaluation in Real Mobile Device Scenarios,” arXiv preprint arXiv:2412.16516, Feb. 2025. [Online]. Available: https://arxiv.org/abs/2412.16516. [Accessed: Feb. 27, 2025]

2025
[19]

AgentBench: Evaluating LLMs as Agents,

X. Liu, H. Yu, H. Zhang, et al., “AgentBench: Evaluating LLMs as Agents,” arXiv preprint arXiv:2308.03688, Oct. 2023. [Online]. Available: https://arxiv.org/abs/2308.03688. [Accessed: Feb. 27, 2025]

2023 arXiv
[20]

Less is More: Optimizing Function Calling for LLM Execution on Edge Devices,

V. Paramanayakam, A. Karatzas, et al., “Less is More: Optimizing Function Calling for LLM Execution on Edge Devices,” arXiv, 2024. [Online]. Available: https://arxiv.org/abs/2411.15399. [Accessed: Feb. 27, 2025]

2024 arXiv
[21]

Gorilla: Large Language Model Connected with Massive APIs,

S. Patil, T. Zhang, et al., “Gorilla: Large Language Model Connected with Massive APIs,” arXiv, 2023. [Online]. Available: https://arxiv.org/abs/2305.15334. [Accessed: Feb. 27, 2025]

2023 arXiv

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Traditional NL-to-SQL methods, while user-friendly, introduce risks when handling complex legacy databases

Introduction Operational data retrieval in nuclear power plants demands unparalleled accuracy and transparency due to its critical impact on decision-making. Traditional NL-to-SQL methods, while user-friendly, introduce risks when handling complex legacy databases. This paper introduces a function-calling LLM approach that leverages pre -approved, purpose...

work page 2024

[2] [2]

What day is it today?

Challenges We faced several technical challenges that influenced our methodology. This section discusses these challenges, and the approaches considered to solve them. 2.1 Agentic/Autonomous Behaviour The objective of our function -calling structured SQL method is to minimize autonomous behavior by providing explicit instructions to agents on the necessar...

work page 2025

[3] [3]

main agent

Final Methodology In this paper we discuss the methodology used for a function calling SQL retrieval agentic workflow. This system is not fully agentic as the agents are not given full autonomy to make decisions, this is a workflow process where each agent is guided by spec ific rules and structure in terms of when they get called and in what order. 5 44t...

work page 2025

[4] [4]

Show me all the work requests entered in by John Smith

Receive User Query: The program starts by taking a user’s natural language question (for example, “Show me all the work requests entered in by John Smith")

work page

[5] [5]

Extract Query Intent: The application calls an intent extraction agent that analyzes the query to determine the user’s intent and key entities (like tables, fields, conditions, and work areas)

work page

[6] [6]

7 44th Annual CNS Conference and the 49th Annual CNS/CNA Student Conference Westin Harbour Castle Hotel, Toronto, ON, Canada, June 8-11, 2025 a

Retrieve Example Queries: Using the extracted intent as context, the system retrieves similar or relevant example queries from a vector-based search index. 7 44th Annual CNS Conference and the 49th Annual CNS/CNA Student Conference Westin Harbour Castle Hotel, Toronto, ON, Canada, June 8-11, 2025 a. Decision Point: If one of the examples closely matches t...

work page 2025

[7] [7]

This query also comes with an explanation of how it was built

Generate Initial SQL Query: Based on the chosen path, an initial SQL query is constructed. This query also comes with an explanation of how it was built

work page

[8] [8]

Any discrepancies are corrected so that the query conforms to the expected format and contains only valid tables and fields

Validate SQL Query: The initial SQL query is then passed to a validation agent that cross-checks the table and field names against the system’s schema (stored in a vector database). Any discrepancies are corrected so that the query conforms to the expected format and contains only valid tables and fields

work page