In the previous article, I walked through several papers on tool-using LLMs and agentic orchestration. The main argument was that an AI-native financial data foundation should not rely on an LLM as a standalone answer generator. The LLM should act as an orchestrator over governed semantic capabilities: concept resolution, field discovery, product decomposition, readiness checking, validation, lineage tracing, and mapping explanation. That article focused mainly on the tool-use side of the Agentic Semantic Layer.

In this article, I want to focus on the other side:

How should the agent reason over knowledge and evidence?

This is where graph-grounded reasoning becomes important. Financial data is not just a collection of text fragments, tables, or field names. Financial meaning is relational. A source field maps to a semantic concept. A semantic concept aligns with a canonical concept. A canonical concept belongs to a product component. A product component is required by a use case. A use case depends on validation rules. A validation result may require lineage evidence. In other words, many financial data questions are graph-shaped questions.

This article reviews four papers that are especially useful for thinking about this problem:

• Think-on-Graph: Deep and Responsible Reasoning of Large Language Model on Knowledge Graph
• Search-on-Graph: Iterative Informed Navigation for Large Language Model Reasoning on Knowledge Graphs
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
• Corrective Retrieval-Augmented Generation

As before, I am not trying to summarise every detail of the papers. I am interested in the architectural lessons that are relevant to the Agentic Semantic Layer of my AI-native financial data foundation.

The key question will be:

How can an AI agent use a financial semantic graph and evidence-checking mechanisms to produce grounded, traceable, and governable answers?

Why graph grounding matters for financial data

A traditional RAG system usually retrieves text chunks. That is useful, but it is not enough for many financial data questions.

Consider a user asking: Can this IRS feed support valuation?

This question cannot be answered reliably by retrieving a few relevant paragraphs. The system needs to understand the relationships between product structure, required concepts, mapped source fields, missing fields, validation rules, and source-system ownership.

Or consider another question: What does this field called rate mean?

A vector search may find several relevant concepts. But the correct answer depends on the graph context. Is the product an interest rate swap, a repo, a bond, or an FX forward? Is the field near notional and fixed coupon? Is it linked to a payout component? Is it used in valuation or settlement? Does it align with a fixed rate, floating spread, repo rate, discount rate, or haircut?

The answer is not only about semantic similarity. It is about relational context. That is why a financial data agent needs graph-grounded reasoning. The graph provides a structured representation of meaning, dependency, ownership, use-case relevance, validation, and lineage.

However, graph grounding alone is still not enough. The agent also needs to know whether the retrieved evidence is sufficient. It needs to decide when to retrieve, what to retrieve, whether the retrieved result supports the answer, and whether a corrective step is needed. This is where evidence checking becomes important.

Paper 1: Think-on-Graph — reasoning over knowledge graph paths

The first paper is Think-on-Graph: Deep and Responsible Reasoning of Large Language Model on Knowledge Graph.

This paper starts from a familiar problem: LLMs can be powerful, but they can hallucinate or fail when a task requires deep, traceable reasoning over factual knowledge. To address this, the authors propose a paradigm where the LLM interacts with a knowledge graph, explores entities and relations, retrieves reasoning paths, and then reasons based on the retrieved knowledge.

The important idea is that the LLM does not only receive retrieved text. It actively explores the graph. This is different from ordinary RAG. In a normal RAG setup, the system retrieves chunks of text and places them into the prompt. In Think-on-Graph, the system starts from entities, expands through graph relations, evaluates candidate paths, and gradually builds a reasoning path that can support the final answer.

The mechanism can be simplified as:

question → identify topic entity → explore relations → explore neighbouring entities → keep promising paths → decide whether enough evidence exists → answer

There are several important points in this pattern.

• First, the graph search needs an entry point. The system identifies topic entities from the question and uses them as the starting points for reasoning.
• Second, the graph is explored step by step. From the current entity, the system looks at candidate relations and neighbouring entities. This is not a blind traversal of the whole graph; the LLM helps select the relations and entities most relevant to the question.
• Third, the system keeps multiple promising reasoning paths instead of committing too early to a single path.
• Finally, the system checks whether the current paths contain enough evidence to answer the question. If not, the exploration continues.

This is highly relevant to financial data because a financial data question often requires a path, not just a document. For example:

SourceField → SemanticConcept → CDMConcept → ProductComponent → ProductType → UseCase → ValidationRule

This path is meaningful because each edge explains part of the answer. If a source field maps to FixedRate, and FixedRate aligns with a rate specification used by an InterestRatePayout, and that payout is part of an InterestRateSwap, then the agent can explain not only what the field means, but why it matters for a particular product or use case.

This kind of answer is very different from ordinary retrieval.

It is not:

“I found a paragraph mentioning fixed rate.”

It is:

“This field maps to a semantic concept that belongs to a product component required for this use case, and this graph path supports the answer.”

That is the value of graph-grounded reasoning.

For the Agentic Semantic Layer, the most important lesson is traceability. In financial data, an answer is not enough. The system also needs to explain what evidence supports the answer. If the agent says that a feed is partially ready for valuation, the user should be able to ask which concepts are present, which concepts are missing, which concepts require review, which graph paths support the conclusion, which validation rules were considered, and which source systems were checked.

Think-on-Graph supports the idea that graph paths can become reasoning evidence.

For my AI-native financial data foundation (now named as Finsight AI-Foundry), the design principle is clear:

The agent should not only retrieve facts. It should retrieve and expose semantic paths.

This matters because financial data governance depends on explainability. A user should not only see the final answer; they should also see the path that led to the answer. In the Finsight AI-Foundry design, the semantic graph should not be treated only as a storage structure. It should become part of the reasoning process itself.d answer can show the chain of meaning behind the conclusion.

Paper 2: Search-on-Graph — observe before navigating

The second paper is Search-on-Graph: Iterative Informed Navigation for Large Language Model Reasoning on Knowledge Graphs.

This paper is useful because it proposes a simpler and more controlled approach to knowledge graph reasoning.

Many knowledge graph question-answering approaches face a practical trade-off. If the model is asked to generate a complete graph query upfront, the query may be brittle because the model may not know which relations actually exist in the graph. If the system retrieves a large subgraph, the result may contain too much noise. If the agent explores too many paths in parallel, the search space can grow quickly.

Search-on-Graph takes a different approach. Instead of pre-planning the full path or retrieving a large noisy subgraph, the agent navigates the graph iteratively. At each step, it observes the available relations from the current entity and then decides the next hop.

The simplified principle is:

observe available relations → choose next hop → observe again → continue

The model does not need to know the full path at the beginning. It only needs to make a grounded decision at the current step, based on the relationships that actually exist in the graph.

This is especially relevant to financial semantic graphs. In a complex financial graph, the agent may not know the full path upfront. It may start from a source field, observe that the field maps to a semantic concept, then observe that the concept aligns with a CDM concept, then observe that the CDM concept belongs to a product component, then observe that the product component is required by a use case, and finally observe which validation rules apply.

A possible path may look like this:

SourceField → SemanticConcept → CDMConcept → ProductComponent → UseCase → ValidationRule

This is more realistic than asking the agent to generate a perfect multi-hop graph query from the beginning.

Financial semantic graphs can be large, product-specific, and institution-specific. The available relationships may vary by product, source system, dataset, use case, and governance status. A controlled observe-then-navigate pattern is therefore attractive because each step is grounded in actual graph structure.

This also helps reduce noise. More context is not always better. If the system retrieves too much, the LLM may be distracted by irrelevant concepts, fields, products, or relationships. If it retrieves too little, the answer may be incomplete. If it asks the LLM to generate a complex graph query directly, the query may be wrong or too fragile.

A stepwise traversal pattern gives the agent more control. For example, when the user asks:

Why is this source field required for valuation?

the agent may not need every document about the source feed or every field in the product model. It needs to navigate the semantic graph along the relevant path:

source field → semantic concept → product component → valuation use case → validation rule

At each step, the graph determines what relationships actually exist. The agent chooses the next direction based on the user’s question and the available relations.

For the Agentic Semantic Layer, the design principle is clear:

The agent should observe the graph before deciding how to navigate it.

This means the Agentic Semantic Layer should support iterative graph traversal, not only one-shot retrieval. This is particularly important for financial data because meaning often emerges through context and dependency paths. A field does not become meaningful simply because it has a name. It becomes meaningful because of where it sits in the graph: which concept it maps to, which product component it supports, which use case requires it, which validation rule applies, and which evidence path supports the conclusion.

Search-on-Graph therefore gives Finsight AI-Foundry a practical graph-reasoning pattern:

do not retrieve everything upfront; let the agent navigate financial meaning step by step.

Paper 3: Self-RAG — retrieve, generate, and critique

The third paper is Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection.

Self-RAG addresses an important limitation of conventional RAG. Many RAG systems retrieve a fixed number of passages and then generate an answer from them. But retrieval is not always necessary, and retrieved passages are not always relevant. If poor evidence is retrieved, the generated answer may still sound confident.

Self-RAG introduces a framework where the model can retrieve on demand and reflect on both the retrieved evidence and its own generation. The exact training method is not my main focus here. The useful idea is the control pattern:

decide whether retrieval is needed → retrieve → evaluate evidence → generate → critique

This pattern matters because it changes retrieval from a fixed preprocessing step into an adaptive reasoning decision. In a conventional RAG system, retrieval often happens automatically before generation. In Self-RAG, retrieval becomes conditional. The model can decide whether external evidence is needed, assess whether the retrieved evidence is relevant, and judge whether the generated answer is sufficiently supported. The paper implements this idea through special reflection tokens, which allow the model to control and critique its retrieval and generation behaviour.

This is directly relevant to the Agentic Semantic Layer. A financial data agent should not blindly retrieve everything. It should retrieve when needed, assess whether the retrieved evidence is sufficient, and be able to stop, continue, or add caveats.

For example, if the user asks: What is the notional amount in this feed?

the agent may only need a direct field mapping.

But if the user asks: Can this feed support valuation?

the agent needs more extensive evidence: required concepts, present fields, missing fields, ambiguous fields, validation rules, and possibly alternative source systems.

The retrieval strategy should depend on the task. This is especially important because financial evidence is use-case dependent. What is sufficient for data discovery may not be sufficient for valuation, reporting, settlement, or regulatory use.

Suppose the agent finds that FixedRate is present in the feed. That is useful, but it is not enough to conclude that the feed supports valuation. The agent also needs to check notional, currency, effective date, termination date, floating index, reset schedule, payment schedule, day count, and other required concepts.

Similarly, if the agent finds a field that looks like rate, it should not immediately conclude that it is FixedRate. It should check product context, field description, sample values, neighbouring fields, existing mappings, and possibly SME review status.

For Finsight AI-Foundry, the design principle is clear:

The Agentic Semantic Layer should not treat retrieved evidence as automatically sufficient. It should evaluate whether the evidence supports the answer.

This means the agent should be able to ask:

Do I need retrieval for this task?
Is the retrieved evidence relevant?
Is the evidence sufficient for this use case?
Does the evidence support the answer?
Should I continue searching, add a caveat, or require SME review?

For financial data, the question is not simply whether something was retrieved. The question is whether the retrieved evidence is strong enough to support the decision the agent is about to make.

Paper 4: Corrective Retrieval-Augmented Generation — correcting weak retrieval

The fourth paper is Corrective Retrieval-Augmented Generation, often referred to as CRAG.

CRAG focuses on a practical weakness of RAG systems: generation quality depends heavily on retrieval quality. If retrieval goes wrong, the final answer may also go wrong. A generated answer can still sound confident even when the retrieved evidence is incomplete, irrelevant, or unreliable.

The important idea is simple:

retrieve → evaluate retrieval quality → correct if needed → generate

CRAG introduces a retrieval evaluator that assesses whether the retrieved information is good enough for the user query. If the evidence is sufficient, the system can proceed to generation. If the evidence is weak, ambiguous, or incorrect, the system can take corrective action before generating the final answer.

In a basic RAG system, retrieved context is often treated as useful by default. CRAG makes retrieval quality itself something to be checked. The corrective behaviour may involve retrieving additional information, searching an external source, filtering irrelevant content, or refining the retrieved knowledge so that the generator uses better evidence.

In financial data systems, weak evidence should not silently flow into a confident answer. If a readiness check returns incomplete coverage, the agent should not pretend the feed is ready. If a concept is ambiguous, the agent should not force a single interpretation without flagging uncertainty. If a source system does not provide a missing concept, the agent should say so rather than hallucinating an alternative source. If lineage is incomplete, the agent should report incomplete lineage rather than inventing a path.

For the Agentic Semantic Layer, CRAG suggests a practical control pattern:

evaluate evidence before producing the final answer.

In a financial data foundation, corrective behaviour can take several forms. The agent may retrieve additional graph paths, ask a more specific semantic query, classify a concept as ambiguous, mark a concept as requiring SME review, downgrade the readiness status from ready to partial, produce a caveat, or refuse to generate transformation logic until required mappings are confirmed.

This is very different from generic chatbot behaviour. The goal is not to always answer. The goal is to answer only to the level supported by evidence.

For example, suppose the user asks: Can this IRS feed support valuation?

The agent may first retrieve evidence from the semantic graph and readiness rules. If the retrieved evidence shows that notional, currency, fixed rate, and termination date are present, but reset schedule and day count convention are missing, the answer should not be “ready”. It should be “partially ready”, with missing concepts clearly listed.

If the evidence is ambiguous, the agent should not hide the ambiguity. It should explain what is unclear, what additional evidence is needed, and whether SME review is required.

For Finsight AI-Foundry, the design principle is:

The Agentic Semantic Layer should include evidence evaluation and correction, not just retrieval and generation.

In financial data, retrieval is only the beginning. The agent must also decide whether the retrieved evidence is strong enough, whether correction is needed, and what level of answer can be responsibly produced.

The emerging pattern: graph-grounded and evidence-aware

Taken together, these four papers suggest a clear pattern for the Agentic Semantic Layer.

Think-on-Graph shows that an LLM can use a knowledge graph as a reasoning substrate and produce traceable reasoning paths. Search-on-Graph suggests a controlled way to navigate the graph step by step, observing available relations before choosing the next hop. Self-RAG argues that retrieval should be adaptive and reflective, rather than blindly retrieving a fixed amount of context. CRAG adds that retrieved evidence should be evaluated and corrected when it is weak, incomplete, or unreliable.

For an AI-native financial data foundation, the resulting architecture is not:

retrieve text → generate answer

but instead:

interpret intent → traverse semantic graph → retrieve evidence → evaluate evidence → correct or continue → generate grounded answer

This is the graph-grounded and evidence-aware side of the Agentic Semantic Layer.

For Finsight AI-Foundry, the implication is clear: the financial semantic graph should not be treated merely as a passive metadata store. It should provide the reasoning substrate for AI agents. The graph should expose relationships between source fields, semantic concepts, CDM-aligned concepts, product components, use cases, validation rules, lineage records, and source systems.

The agent should not rely only on semantic similarity. It should be able to traverse relationships. It should not retrieve a large static context every time. It should navigate the graph based on the task. It should not assume that retrieved evidence is sufficient. It should evaluate whether the evidence supports the answer. And it should not force a confident conclusion when the evidence only supports ambiguity, partial readiness, missing data, or SME review.

This gives the Agentic Semantic Layer a more precise role. It is not only a tool orchestration layer. It is also an evidence-control layer. It controls how the agent moves through financial meaning, what evidence is collected, how that evidence is assessed, and how much confidence the final answer deserves.

Consider the question:

Can this IRS feed support valuation?

A graph-grounded and evidence-aware agent should not answer directly. It should identify the product and use case, traverse from the use case to required valuation concepts, compare those concepts with mapped source fields, identify present, missing, and ambiguous concepts, check whether missing concepts are available from other source systems, and then decide whether the evidence supports a ready, partially ready, or not-ready conclusion.

A weak answer would say:

The feed is probably ready for valuation.

A stronger AI-native answer would say:

The feed is partially ready for valuation. Notional, currency, effective date, termination date, and fixed rate are present. Reset schedule and payment schedule are missing. Day count convention requires SME review. Missing concepts may need to be sourced from the trade booking system or valuation configuration. Therefore, the feed is not fully valuation-ready without additional enrichment.

The second answer is better not because it is longer, but because it is evidence-aware.

• *AI-Native Financial Data Foundation