In the previous articles, I discussed query normalisation, query enrichment, and intent classification. These methods help a system clean up the user’s language, generate alternative query forms, and determine what the user is broadly trying to do. However, identifying the intent is not enough.

Consider the following question:

Where does the floating rate index map to?

The system may correctly classify this as a mapping question. But it still needs to determine:

• which part of the sentence represents the concept to search for;
• what “floating rate index” means in this particular context;
• whether the user expects a source field, CDM attribute, mapping function, model type, or complete mapping path;
• which semantic relationships should be searched.

These tasks are closely related and are best considered together.

A practical query-understanding process should include three connected steps:

1. mention extraction;
2. context interpretation;
3. expected entity-type identification.

Together, they transform a natural-language question into a more structured and constrained semantic query.

Why Intent Classification Is Not Enough

Intent classification is capable to identify the operation the user wants the system to perform. However, queries with the same intent may still require very different searches.

For example,What is InterestRatePayout? and What is rateSpecification? may both be reference-model questions.

But the first query is probably asking about a model type, while the second is probably asking about an attribute.

Similarly, What does MapSwapPayout do? and Where does floatingRateIndex map to? are both related to mapping, but the first expects an explanation of a function, while the second may expect a target attribute, a function chain, or a complete mapping path.

Intent classification therefore provides only the first layer of query understanding.

The system must still identify the important expressions in the query, interpret their meaning in context, and predict the types of semantic entities that are likely to answer the question.

1. Mention Extraction

Mention extraction identifies the parts of the user’s question that may refer to meaningful business or technical concepts.

Consider:

What is the day count fraction used by the fixed leg?

Possible mentions include:

• day count fraction;
• fixed leg.

The remaining words express the question and the relationship between those concepts.

Mention extraction is similar to named-entity recognition, but semantic queries are usually not focused on conventional entities such as people, locations, and organisations.

Instead, the mentions may represent:

• business concepts;
• financial products;
• model types;
• attributes;
• enumeration values;
• functions;
• source fields;
• identifiers;
• standards terminology;
• mappings;
• events;
• informal business expressions.

The objective is not yet to determine the exact governed entity. It is first to identify which parts of the user’s language should be resolved against the semantic foundation.

Why Mention Extraction Matters

Without mention extraction, a system may attempt to search the whole question as a single string:

what is the day count fraction used by the fixed leg

This exact expression is unlikely to exist as an entity name, label, or synonym in the semantic layer.

After mention extraction, the system can search separately for:

day count fraction
fixed leg

This makes retrieval more focused.

It also allows the system to reason about the relationship between the two mentions. For example, the user may be asking for a day-count-fraction attribute associated with a fixed-rate payout.

Mention extraction therefore provides the units that later stages can normalise, resolve, connect, and rank.

Dictionary-Based Mention Extraction

A straightforward approach is to match the query against governed terminology.

The dictionary may include:

• canonical entity names;
• display labels;
• approved synonyms;
• abbreviations;
• business aliases;
• source-system terminology;
• technical identifiers.

For example, the phrase:

floating rate index

may be associated with terms such as:

FloatingRateIndex
floatingRateIndexr>rate indexr>reference rate index

Dictionary-based extraction is attractive because it is predictable and explainable.

When a mention is identified, the system can show exactly which governed term or alias produced the match.

However, dictionary matching has an important limitation: users often express concepts in ways that have not been explicitly registered.

For example:

the index used for the floating side

may refer to floatingRateIndex, even though the wording is not present in the terminology catalogue.

Dictionary matching is therefore useful, but it is rarely sufficient on its own.

Pattern-Based Mention Extraction

Many technical expressions follow recognisable patterns. These can often be extracted deterministically.

Examples include:

MapSwapPayout
floatingRateIndex
cdm.product.asset.InterestRatePayout
trade.product.payout
CDM 6.0

Patterns can identify:

• camelCase attribute names;
• PascalCase type or function names;
• qualified model names;
• object paths;
• version numbers;
• source-column references;
• technical identifiers.

This is particularly useful in systems such as a CDM assistant, where users may mix natural language with exact model terminology.

For example:

How does floatingRateIndex reach InterestRatePayout?

The two technical expressions can be extracted with high confidence before any model-based interpretation is applied.

Deterministic pattern handling should usually take precedence over more speculative language-model inference when the expression closely resembles a known identifier.

Statistical and Transformer-Based Extraction

A trained language model can identify domain-specific mentions based on their linguistic context. This makes it possible to recognise expressions that do not exactly match the governed terminology.

For example, Which index is used to calculate the floating interest payments?

A model may identify:

• index;
• floating interest payments.

These expressions can then be resolved against likely semantic entities such as:

• floatingRateIndex;
• InterestRatePayout;
• floating-rate specifications.

Transformer-based extraction can be more flexible than fixed rules or dictionary matching.

However, it requires suitable training or evaluation data. A general-purpose model may not reliably understand organisation-specific business language, internal abbreviations, source-field names, or model conventions.

It should therefore be combined with governed semantic evidence rather than treated as the final authority.

LLM-Based Mention Extraction

An LLM can also be asked to extract mentions using a structured response contract.

For example:

{
  "mentions": [
    {
      "text": "floating rate index",
      "start": 15,
      "end": 34,
      "possible_role": "business_or_model_concept"
    }
  ]
}

This can work well for longer or more conversational questions.

For example:

I am trying to understand which part of the CDM structure represents the benchmark used to calculate the floating payments.

An LLM may extract:

• CDM structure;
• benchmark;
• floating payments.

These are useful search inputs even though none of them may exactly match a model element.

However, the LLM should not be allowed to silently convert these mentions into confirmed semantic entities.

The system should preserve the distinction between:

• the text written by the user;
• the normalised form;
• the model’s interpretation;
• the governed entity eventually selected.

This separation is important for explainability and debugging.

Mention Boundaries

Correct mention boundaries matter.

Consider:

fixed interest rate leg

The system might extract only:

interest rate

But the more useful complete mention may be:

fixed interest rate leg

The longer expression carries more information. It suggests not only the domain, but also a fixed-rate role and a payout-like component.

In some cases, nested mentions should be preserved:

mentions:
  - text: fixed interest rate leg
    nested_mentions:
      - fixed rate
      - interest rate
      - leg

The complete expression may be resolved as one business concept, while the smaller components can provide additional retrieval evidence.

This is particularly useful when the semantic layer does not contain an exact equivalent for the full user expression.

For example, the system may not have an entity named FixedInterestRateLeg, but it may connect the expression to:

• InterestRatePayout;
• FixedRateSpecification;
• a fixed-rate payer or receiver role.

The mention should therefore not be discarded merely because it does not directly match a single model element.

Overlapping Mentions

Mentions may also overlap.

Consider:

floating rate index mapping function

Possible mentions include:

• floating rate index;
• mapping function;
• floating rate index mapping function.

The longest expression is not always the correct one.

The system may need to retain several hypotheses and allow context interpretation to determine their roles.

A practical mention representation may therefore include:

mentions:
  - text: floating rate index
    possible_roles:
      - BUSINESS_CONCEPT
      - ATTRIBUTE
      - SOURCE_FIELD
  - text: mapping function
    possible_roles:
      - FUNCTION_TYPE
      - REQUESTED_ENTITY_HINT

Mention extraction should identify the relevant language without prematurely forcing every expression into one semantic category.

2. Context Interpretation

Mention extraction identifies which words matter. Context interpretation determines what those words are likely to mean in the current question. This is necessary because the same expression may refer to different semantic objects in different contexts.

Consider:

What is payment?

The word payment could refer to:

• a general business concept;
• a CDM type;
• an attribute;
• a cashflow;
• a settlement event;
• a mapping target;
• a function that constructs a payment;
• a source field named payment.

The mention alone is insufficient. The surrounding language, previous conversation, business domain, requested relationship, and available semantic evidence must all be considered.

Local Linguistic Context

The words around a mention often provide strong signals.

Consider:

Which attribute stores the payment date?

The word attribute suggests that the user expects a model field or path.

Which function creates the payment?

The word function suggests a transformation, construction, or calculation function.

Where does payment map from?

The phrase map from suggests a source-to-target mapping relationship.

What changed in payment between CDM 5 and CDM 6?

The version references indicate that the user is asking for a model difference rather than a general definition.

These signals can constrain both retrieval and ranking. For example, when the user explicitly asks for an attribute, model types and functions should normally receive less weight.

They may still be retained as supporting candidates, but they should not dominate the result merely because their names are lexically similar.

Relationship Context

Many queries are not simply asking what a concept is. They are asking how concepts are related.

Examples include:

Which payout contains floatingRateIndex?

This expresses a containment relationship.

What does floatingRateIndex map to?

This expresses a mapping relationship.

Which function calls ResolveRateIndex?

This expresses a function-dependency relationship.

What changed in rateSpecification between two CDM versions?

This expresses a version-difference relationship.

Which product uses InterestRatePayout?

This may express a composition or usage relationship.

The same mention can therefore require different semantic searches depending on the relationship expressed by the query.

A lexical search for floatingRateIndex may retrieve the correct attribute, but that alone does not answer:

Which function maps floatingRateIndex?

The system must search relationships involving the attribute, such as:

• referenced by function;
• populated by function;
• maps from source field;
• contained in payout;
• reachable through function call path.

Relationship interpretation is therefore a critical part of semantic query construction.

Domain Context

The meaning of a term may vary between business domains.

For example, leg may refer to:

• an interest-rate payout;
• one side of a credit transaction;
• an option-strategy component;
• a settlement component;
• a source-system trade-leg record.

If the user has already mentioned an interest-rate swap, candidates related to rates should normally receive greater weight.

For example:

In a fixed-float swap, where is the floating leg represented?

The product context suggests that the answer is likely related to InterestRatePayout, rather than an unrelated use of the word leg.

Domain context may come from:

• the current query;
• previous conversation turns;
• the selected dataset;
• the active model or standard;
• the user’s application context;
• an earlier resolved entity.

However, context should usually guide ranking rather than immediately eliminate alternatives. A system should only apply a hard filter when the context is explicit enough to justify it.

Model and Standard Context

Enterprise systems may contain multiple standards, models, and source systems.

A term such as tradeDate may exist in:

• FINOS CDM;
• an FpML message;
• an internal canonical model;
• a source trading platform;
• a database table.

The query may provide an explicit model hint:

What is tradeDate in CDM?

Or the model may be implied by the active conversation:

How does it map from FpML?

The system should represent this context explicitly.

For example:

context:
  target_standard: FINOS_CDM
  source_standard: FPML

This prevents the same lexical expression from being resolved against the wrong semantic catalogue.

It is particularly important when source and target models use similar names.

Context as Structured Constraints

Context interpretation should not remain only inside an opaque model representation. Where possible, it should be converted into explicit constraints.

For example:

intent: MAPPING_LOOKUP
mentions:
  - text: floating rate index
    normalized_form: floating rate index
context:
  requested_relationship: MAPS_TO
  source_or_target: unknown
  domain_hint: interest_rates
  target_standard: FINOS_CDM
  expected_answer_form: mapping_explanation

These constraints can then be used by:

• lexical retrieval;
• vector retrieval;
• graph traversal;
• entity filtering;
• candidate ranking;
• answer construction.

Structured context also makes it easier to understand why a particular candidate was selected.

3. Expected Entity Types

Expected entity-type identification predicts what kind of semantic object is likely to answer the query.

This is different from intent classification. Intent describes the operation. Expected entity type describes the object, or combination of objects, that should be retrieved.

Consider:

What is InterestRatePayout?

The expected entity type is likely:

TYPE

Now consider:

What is rateSpecification?

The expected entity type is likely:

ATTRIBUTE

Both questions may have the same broad intent, but they should search different parts of the semantic foundation.

Other examples include:

What does MapSwapPayout do?

Expected type:

FUNCTION

What values can settlementType contain?

Expected type:

ENUMERATION

Where does floatingRateIndex map to?

Expected types may include:

TARGET_ATTRIBUTE
MAPPING_RULE
FUNCTION
MAPPING_PATH

Expected entity types therefore provide an important constraint between intent classification and candidate retrieval.

Explicit Type Words

The clearest expected-type signals are explicit words in the query.

Examples include:

• type;
• class;
• attribute;
• field;
• property;
• path;
• function;
• rule;
• mapping;
• enumeration;
• product;
• event;
• payout;
• source column;
• target field.

For example:

Which function maps the fixed leg?

strongly suggests:

expected_entity_types:
  primary:
    - FUNCTION
  supporting:
    - MAPPING_RULE
    - SOURCE_FIELD
    - TARGET_ATTRIBUTE

Similarly:

Which attribute represents the payment date?

suggests:

expected_entity_types:
  primary:
    - ATTRIBUTE
    - ATTRIBUTE_PATH

Explicit type words should usually be treated as high-confidence evidence.

Intent-Derived Expected Types

The system can also define default entity types for each intent.

For example:

REFERENCE_MODEL_QUESTION:
  primary:
    - TYPE
    - ATTRIBUTE
    - ENUMERATION
MAPPING_LOOKUP:
  primary:
    - MAPPING_RULE
    - SOURCE_FIELD
    - TARGET_ATTRIBUTE
    - MAPPING_PATH
MAPPING_LOGIC_QUESTION:
  primary:
    - FUNCTION
    - FUNCTION_PATH
    - MAPPING_PATH
VERSION_DIFF:
  primary:
    - TYPE
    - ATTRIBUTE
    - FUNCTION
    - ENUMERATION
FUNCTION_QUESTION:
  primary:
    - FUNCTION

These are defaults, not absolute rules. The actual query may narrow or extend them.

For example, a version-difference question may ask specifically about a function:

How did MapSwapPayout change between the two versions?

In that case, FUNCTION should receive much greater weight than other model elements.

Mention Form and Naming Conventions

The surface form of the mention can also provide type evidence.

For example:

• MapSwapPayout resembles a function name.
• floatingRateIndex resembles an attribute or source field.
• cdm.product.asset.InterestRatePayout resembles a qualified model type.
• FloatingRateIndexEnum resembles an enumeration.

These conventions are not universally reliable, but they are useful signals in technical domains.

A practical resolver may assign type priors based on naming patterns:

mention_type_hints:
  - mention: MapSwapPayout
    likely_types:
      FUNCTION: 0.95
      TYPE: 0.10
  - mention: floatingRateIndex
    likely_types:
      ATTRIBUTE: 0.75
      SOURCE_FIELD: 0.65
      FUNCTION_PARAMETER: 0.30

These priors can be combined with intent and context evidence.

Semantic-Layer Evidence

The semantic repository itself should provide typed candidates.

Suppose floatingRateIndex appears as:

• a CDM attribute;
• an FpML element;
• a function input;
• part of several attribute paths;
• a term in mapping descriptions.

The system should preserve those candidate types instead of flattening them into one untyped search result.

For example:

candidates:
  - id: cdm.attribute.floatingRateIndex
    entity_type: ATTRIBUTE
  - id: fpml.element.floatingRateIndex
    entity_type: SOURCE_FIELD
  - id: mapping.path.floatingRateIndex
    entity_type: MAPPING_PATH

The expected entity types can then influence ranking.

This is more reliable than asking a language model to guess the final entity without consulting the actual semantic foundation.

Primary and Supporting Entity Types

Many questions require more than one kind of entity.

Consider:

How does floatingRateIndex reach InterestRatePayout?

A useful answer may need:

• the source field;
• the initial mapping function;
• intermediate helper functions;
• the target attribute;
• the containing CDM type.

The query may therefore be represented as:

expected_entity_types:
  primary:
    - MAPPING_PATH
  supporting:
    - SOURCE_FIELD
    - FUNCTION
    - ATTRIBUTE
    - TYPE

The primary type represents the main answer object. The supporting types provide the evidence and explanation needed to construct the answer.

This distinction is more useful than forcing every query into one entity class.

Expected Answer Form

Expected entity types are related to, but different from, the expected answer form. For example, the user may ask:

How does floatingRateIndex reach InterestRatePayout?

The primary semantic object may be a MAPPING_PATH.

But the expected answer form may be:

expected_answer_form:
  - STEP_BY_STEP_EXPLANATION
  - FUNCTION_CHAIN
  - SOURCE_TO_TARGET_TRACE

Similarly:

What is InterestRatePayout?

may expect a TYPE, but the answer form may include:

• definition;
• important attributes;
• containing namespace;
• related payout concepts.

Separating entity type from answer form helps keep retrieval and presentation concerns distinct.

How the Three Steps Work Together

Mention extraction, context interpretation, and expected entity-type identification should operate as a connected pipeline.

Consider:

Which function maps the floating rate index into the CDM payout?

The system may process this as follows.

Step 1: Extract Mentions

mentions:
  - text: floating rate index
    normalized_form: floating rate index
  - text: CDM payout
    normalized_form: payout

The phrase function may also be captured as an expected-type signal rather than a domain entity mention.

Step 2: Interpret Context

context:
  requested_relationship: MAPS_INTO
  domain_hint: interest_rates
  target_standard: FINOS_CDM
  target_scope: PAYOUT

The phrase maps ... into indicates a mapping relationship. The mention floating rate index suggests the interest-rate domain. The phrase CDM payout identifies the target model and a broad target scope.

Step 3: Identify Expected Entity Types

expected_entity_types:
  primary:
    - FUNCTION
  supporting:
    - SOURCE_FIELD
    - TARGET_ATTRIBUTE
    - TYPE
    - MAPPING_PATH

The word function gives a strong primary expectation. However, supporting entities are also required to explain what the function maps from and where the value ends up.

A complete intermediate representation may look like this:

{
  "intent": "MAPPING_LOGIC_QUESTION",
  "mentions": [
    {
      "text": "floating rate index",
      "normalized_form": "floating rate index",
      "possible_types": [
        "SOURCE_FIELD",
        "ATTRIBUTE",
        "BUSINESS_CONCEPT"
      ]
    },
    {
      "text": "CDM payout",
      "normalized_form": "payout",
      "possible_types": [
        "TYPE",
        "COMPONENT",
        "BUSINESS_CONCEPT"
      ]
    }
  ],
  "context": {
    "domain": "interest_rates",
    "target_standard": "FINOS_CDM",
    "requested_relationship": "MAPS_INTO"
  },
  "expected_entity_types": {
    "primary": [
      "FUNCTION"
    ],
    "supporting": [
      "SOURCE_FIELD",
      "ATTRIBUTE",
      "TYPE",
      "MAPPING_PATH"
    ]
  },
  "expected_answer_form": [
    "FUNCTION_EXPLANATION",
    "SOURCE_TO_TARGET_TRACE"
  ]
}

This result is much more useful than an intent label alone.

It can directly guide candidate generation, semantic search, graph traversal, function inspection, and answer construction.

• *AI-Native Financial Data Foundation