As I have always emphasised, the semantic foundation is the core of my AI-Native Financial Data Foundation initiative and where much of its real value lies. As this series has shown, I have spent a great deal of time and effort thinking through how that foundation should be structured, governed, and made operational.

However, building the semantic foundation is not enough. For the knowledge it contains to be useful, it must also be queried and interpreted correctly.

That introduces another set of critical engineering tasks: understanding natural-language questions, resolving business terms to the right semantic elements, and turning the result into a valid query the system can execute.

This is not a minor technical detail around the edges of the semantic layer. It is an important engineering problem in its own right and needs to be designed properly.

I therefore plan to write a few blog posts exploring this topic in more depth. This post provides a high-level overview of the overall problem and the main areas involved.

A Simple Question That Hides a Complex Process

Consider a business user asking:

What is the fixed leg in this interest rate swap?

To the user, this is a simple question. They expect the AI to understand it, find the relevant information, and provide the answer.

However, the system cannot simply search for the words fixed leg.

The user may use a business term that does not appear directly in the semantic model. They may write fix leg, use an internal abbreviation, or ask the same question in a different way, such as:

Which side are we paying fixed on?

The system must first understand what the user means. It must then connect that meaning to the correct elements in the semantic layer and determine how to retrieve the answer.

At a high level, this involves three connected areas:

1. Query Understanding
2. Entity Resolution
3. Semantic Query Planning

Query Understanding

The first area is query understanding: working out what the user is actually asking.

The system needs to do more than interpret the words literally. It may need to correct obvious spelling errors, recognise different ways of expressing the same idea, identify the important business terms, and use the surrounding context.

For example, the questions below may all refer to the same thing:

• What is the fixed leg in this interest rate swap?
• What is the fix leg in this swap?
• Which side are we paying fixed on?

Several standard tasks are involved.

Normalisation reduces superficial variation in the input. It may correct fix leg to fixed leg, expand an abbreviation such as IRS, or standardise common business terminology.

Intent classification identifies what the user wants the system to do. They may be asking for a definition, a value, a relationship, a mapping, or a comparison. In this example, the user is probably asking for a component or value from a particular trade.

Mention extraction identifies the important phrases in the question. Here, fixed leg is the main business mention, while interest rate swap provides the product context.

Context interpretation uses information that may not be fully stated in the question. The word this may refer to the trade currently displayed in an application or to an entity mentioned earlier in the conversation.

The system may also identify the expected entity type. In this case, fixed leg is likely to refer to a product component or payout rather than a party, event, or individual attribute.

The output of query understanding is therefore a structured interpretation such as:

Intent: component lookup
Business mention: fixed leg
Product context: interest rate swap
Object context: current trade
Expected entity type: product component

This is not yet the final semantic query. It provides the information needed for the next stage.

Entity Resolution

The second area is entity resolution: connecting the user’s language to the correct governed elements in the semantic layer.

This is often harder than it first appears because business terminology does not always match semantic-model terminology directly.

The user may say fixed leg, but the semantic model may not contain an entity literally called FixedLeg. It may represent the concept as an InterestRatePayout with a fixed-rate specification.

The system therefore needs to generate a set of possible matches. This process is called candidate generation.

Candidate generation may combine several retrieval methods:

• exact-name search;
• alias search;
• BM25 keyword search;
• vector search;
• fuzzy matching;
• glossary lookup;
• relationship-based retrieval.

Each method serves a different purpose. Exact search works well when the user uses the governed name. Alias search helps when approved business terminology differs from the model. Fuzzy matching helps with spelling mistakes. Vector search helps retrieve semantically related concepts when the wording is different.

However, none of these methods should automatically determine the answer.

For fixed leg, candidate generation might return:

InterestRatePayout
FixedRateSpecification
RateSchedule
Payout
Cashflow

All of these are related to the question, but they do not represent the same thing. The system must therefore apply contextual reranking.

Contextual reranking evaluates candidates using the wider meaning of the request, not only textual similarity. It may consider:

• the detected intent;
• the expected entity type;
• the current product;
• relationships in the semantic model;
• the current trade data;
• previously resolved entities.

Because the user is asking about a component of an interest rate swap, InterestRatePayout is likely to be a stronger candidate than a general Cashflow.

The system may resolve the business term as:

Entity: InterestRatePayout
Constraint: rate specification is fixed

This is more accurate than trying to find a single model element whose name exactly matches fixed leg.

The system also needs ambiguity detection.

Suppose the user asks: Show me the fixed rate. They may mean the rate value, the rate schedule, the rate specification, or the fixed payout itself.

A system that always selects the highest-scoring candidate may return a plausible but incorrect answer. A more reliable system should recognise when several interpretations remain possible and either use additional context or ask a targeted clarification question.

This matters because a wrongly resolved semantic element can still produce a technically valid query. The system may retrieve correct data from the wrong part of the model.

Semantic Query Planning

Once the relevant semantic elements have been resolved, the system still needs to determine how to retrieve the answer. This is the role of semantic query planning.

Entity resolution tells the system what the user means. Semantic query planning determines what operations need to be performed.

For the fixed-leg example, the system may need to:

1. start from the current trade;
2. locate its economic product;
3. retrieve the interest-rate payouts;
4. identify the payout with a fixed-rate specification;
5. return the relevant details.

Those details may include the payer, receiver, currency, fixed rate, or calculation schedule.

Rather than generating SQL, a graph query, or an API request directly from the original wording, the system can first create an intermediate representation.

For example:

intent: COMPONENT_LOOKUP
root: current_trade
target: InterestRatePayout
constraints:
  - rateSpecification.type = FixedRateSpecification
return:
  - payer
  - receiver
  - currency
  - fixedRate

The exact syntax is not the important part. The purpose of the intermediate representation is to make the intended meaning explicit before execution.

This can then become a typed query plan.

A typed query plan defines which entities, relationships, filters, and result types are valid according to the semantic model. It reduces the risk that the AI invents a relationship, requests a field that does not exist, or applies a filter to the wrong type.

Conceptually, the plan may look like this:

Current Trade
    → Economic Product
    → Interest Rate Payouts
    → Filter by Fixed Rate Specification
    → Return fixed-leg details

Before execution, the system can perform plan validation.

Validation may confirm that:

• the selected entities exist;
• the relationships are valid;
• the constraints apply to the selected types;
• the requested result can be returned;
• the underlying data is available;
• the user is authorised to access it.

Only after validation should the plan be translated into SQL, a graph traversal, an API request, or another semantic-runtime operation.

This creates a governed boundary between natural-language interpretation and execution.

Semantic Search Is Only One Part

It is tempting to describe the whole problem as semantic search, but semantic search addresses only part of it.

Semantic search can help retrieve model elements related to fixed leg, especially when the user’s wording differs from the terminology used in the semantic layer.

However, it does not determine:

• what the user wants to do;
• which entity type they expect;
• which candidate is correct in the current context;
• whether the request is ambiguous;
• which relationships should be traversed;
• how the request should be executed.

Semantic search asks:

Which elements may be relevant?

Semantic query understanding asks:

What does the user mean, and what should the system do?

That distinction is important.

A list of related semantic elements is not yet a semantic query. The system still needs to resolve the intended meaning and form a valid execution plan.

The Overall Flow

The complete process can be summarised as:

For the original question:

What is the fixed leg in this interest rate swap?

the final answer might be:

The fixed leg is paid by Party A in GBP at a fixed rate of 4.25%.

To the user, the interaction feels simple.

Behind it, the system has interpreted imperfect business language, resolved the correct semantic meaning, created a valid query plan, and executed it against governed enterprise knowledge and data.

This is the engineering work required to turn natural language into semantic queries.

• *AI-Native Financial Data Foundation