In the previous article, I looked at Neo4j as a candidate technology for modelling semantic relationships as a graph.
The key idea was simple: a financial semantic model is not only a list of terms. It is a network of connected meaning. A source field may map to a semantic concept. The concept may belong to a product component. The concept may be required by a use case. A validation rule may apply. A mapping may have confidence, review status, and supporting evidence.
That is why a graph model is useful. But storing the graph is only the first step. The next question is more operational:
Can we query the graph clearly?
This is where Cypher matters. Cypher is Neo4j’s graph query language. It allows us to describe graph patterns and retrieve nodes, relationships, and paths from the graph.
For a financial semantic graph, this is important because we do not only want to retrieve isolated metadata. We want to retrieve semantic paths that explain whether a dataset is useful, what it can support, what is missing, and which mappings still require review.
This article is a technical reveiw note. It is not a full semantic graph design. I will use a small but realistic onboarding scenario to show how Cypher can query financial meaning.
Scenario: broker IRS filled-trade onboarding
To make the Cypher examples meaningful, I will use a small broker IRS filled-trade onboarding scenario.
Assume a broker sends a daily filled-trades CSV for interest rate swaps. The file contains fields such as trade_id, product_type, notional, ccy, fixed_rate, float_index, effective_date, maturity_date, pay_freq, reset_freq, counterparty, and trade_status.
On the surface, this is just a CSV file. For an AI-native financial data foundation, however, the important question is not only whether these columns exist. The real question is whether the feed provides the semantic concepts required by a particular use case.
In this example, the use case is IRS Valuation Readiness. It requires concepts such as TradeIdentifier, ProductType, NotionalAmount, Currency, FixedRate, FloatingRateIndex, EffectiveDate, MaturityDate, PaymentFrequency, ResetFrequency, Counterparty, DayCountConvention, and BusinessDayConvention.
The demo graph deliberately creates a mixed situation.
The broker feed provides many required concepts. For example, trade_id maps to TradeIdentifier, notional maps to NotionalAmount, ccy maps to Currency, fixed_rate maps to FixedRate, and float_index maps to FloatingRateIndex.
However, some required concepts are missing from the broker feed. For example, DayCountConvention and BusinessDayConvention are required for valuation readiness, but are not provided by the broker dataset.
The graph also stores mapping quality. Some mappings are approved, while others, such as fixed_rate → FixedRate, float_index → FloatingRateIndex, pay_freq → PaymentFrequency, and reset_freq → ResetFrequency, still require SME review.
The demo graph also contains a few validation rules, such as NotionalMustBePositive, FixedRateMustBePresent, EffectiveDateBeforeMaturity, FloatingIndexMustBeValid, and PaymentFrequencyMustBeValid.
Finally, the graph contains one alternative internal dataset, IRS Terms Master, which can provide at least one concept missing from the broker feed: day_count_convention → DayCountConvention.
This small graph is enough to support meaningful Cypher queries:
- What semantic concepts does the broker feed provide?
- Which valuation-required concepts are present?
- Which required concepts are missing?
- Which mappings still require SME review?
- Which validation rules apply?
- Can an alternative dataset provide a missing concept?
- Can this broker feed support IRS valuation readiness?
Here is the graph I created in my dev neo4j docker container. This will be used for exploring the queries below.
Query 1: semantic inventory of the broker feed
The first useful query is a semantic inventory. Instead of asking which columns exist in the CSV, we ask:
Which semantic concepts does this broker feed provide?
MATCH (dataset:Dataset {name: "Broker A IRS Filled Trades"}) -[:HAS_FIELD]-> (field:SourceField) -[m:MAPS_TO]-> (concept:SemanticConcept)RETURN dataset.name AS dataset, field.name AS source_field, concept.name AS semantic_concept, m.confidence AS confidence, m.review_status AS review_statusORDER BY semantic_concept;
MATCH tells Cypher to find graph patterns that fit the shape described in the query. This query matches a graph path from a dataset to its source fields and then to the semantic concepts those fields map to.
(dataset:Dataset {name: "Broker A IRS Filled Trades"}) finds the dataset node.
-[:HAS_FIELD]->(field:SourceField) follows the HAS_FIELD relationship to each source field.
-[m:MAPS_TO]->(concept:SemanticConcept) follows the MAPS_TO relationship to each semantic concept. The relationship is named m so its properties can be returned.
RETURN selects the output columns, and ORDER BY semantic_concept sorts the result.
This query turns a physical dataset into a semantic inventory.
Query 2: valuation readiness check
The next query compares what the use case requires with what the dataset provides.
MATCH (usecase:UseCase {name: "IRS Valuation Readiness"})MATCH (required:SemanticConcept)-[:REQUIRED_BY_USE_CASE]->(usecase)OPTIONAL MATCH (dataset:Dataset {name: "Broker A IRS Filled Trades"}) -[:HAS_FIELD]-> (field:SourceField) -[m:MAPS_TO]-> (provided:SemanticConcept {concept_id: required.concept_id})RETURN required.name AS required_concept, field.name AS source_field, CASE WHEN provided IS NULL THEN "missing" WHEN m.review_status = "requires_sme_review" THEN "requires_review" ELSE "present" END AS readiness_status, m.confidence AS confidence, m.review_status AS review_statusORDER BY readiness_status, required_concept;
The unique logic is that the query compares each required concept with what the dataset actually provides, using (provided:SemanticConcept {concept_id: required.concept_id}); OPTIONAL MATCH keeps required concepts even when no field maps to them, so they can be marked as "missing"; and the CASE block converts the graph result into a business readiness status: missing, requires review, or present.
This is the first query that starts to feel like a real demo.
It answers: Can this broker feed support IRS valuation readiness?
The result does not only say present or missing. It can distinguish between:
presentrequires_reviewmissing
That distinction matters. A field may exist, but if its semantic mapping still requires SME review, the dataset should not be treated as fully ready. This is the kind of governance-aware evidence an AI agent needs.
Query 3: find missing concepts
The readiness query can be narrowed to missing concepts only.
MATCH (usecase:UseCase {name: "IRS Valuation Readiness"})MATCH (required:SemanticConcept)-[:REQUIRED_BY_USE_CASE]->(usecase)OPTIONAL MATCH (dataset:Dataset {name: "Broker A IRS Filled Trades"}) -[:HAS_FIELD]-> (:SourceField) -[:MAPS_TO]-> (provided:SemanticConcept {concept_id: required.concept_id})WHERE provided IS NULLRETURN required.name AS missing_conceptORDER BY missing_concept;
This query is simple, but useful. The answer is no longer hidden in spreadsheet inspection or manual SME review. The graph can explicitly show which required semantic concepts are not provided by the broker feed.
Query 4: find alternative sources for missing concepts
A better system should not stop at:
This concept is missing.
It should ask:
Can I get this concept from somewhere else?
That is where graph traversal becomes useful.
MATCH (usecase:UseCase {name: "IRS Valuation Readiness"})MATCH (required:SemanticConcept)-[:REQUIRED_BY_USE_CASE]->(usecase)OPTIONAL MATCH (broker:Dataset {name: "Broker A IRS Filled Trades"}) -[:HAS_FIELD]-> (:SourceField) -[:MAPS_TO]-> (provided:SemanticConcept {concept_id: required.concept_id})WITH required, providedWHERE provided IS NULLOPTIONAL MATCH (alt_dataset:Dataset) -[:HAS_FIELD]-> (alt_field:SourceField) -[:MAPS_TO]-> (required)OPTIONAL MATCH (alt_system:SourceSystem)-[:PROVIDES]->(alt_dataset)RETURN required.name AS missing_concept, alt_system.name AS alternative_source_system, alt_dataset.name AS alternative_dataset, alt_field.name AS alternative_fieldORDER BY missing_concept;
This query does two things in one flow: first, it finds all semantic concepts required by the IRS Valuation Readiness use case and checks whether each one is provided by the Broker A IRS Filled Trades dataset; then it keeps only the concepts that are missing from the broker feed using WHERE provided IS NULL. After that, it tries to find whether those missing concepts are available from another dataset and source system. In short, the query asks: which required valuation concepts are missing from the broker feed, and where else might we source them from?
For example, the broker feed may not provide DayCountConvention, but the internal terms master may provide it. That turns the graph into a semantic discovery tool. It does not only say what is missing. It can suggest where to look next.
Query 5: find high-impact mappings that require review
Some mappings may require review, but not all review tasks have the same business impact. A mapping that is required by valuation readiness is more urgent than a mapping that is not currently used by any important use case. This query finds mappings that require SME review and are required by the valuation-readiness use case.
MATCH (dataset:Dataset {name: "Broker A IRS Filled Trades"}) -[:HAS_FIELD]-> (field:SourceField) -[m:MAPS_TO]-> (concept:SemanticConcept) -[:REQUIRED_BY_USE_CASE]-> (usecase:UseCase {name: "IRS Valuation Readiness"})WHERE m.review_status = "requires_sme_review"RETURN field.name AS source_field, concept.name AS semantic_concept, usecase.name AS impacted_use_case, m.confidence AS confidence, m.review_status AS review_statusORDER BY m.confidence DESC;
Query 6: explain why a field matters
A common user question may be:
Why does fixed_rate matter?
A normal data dictionary might answer:
fixed_rate is a decimal field.
That is not enough. A semantic graph can explain the field in context.
MATCH (dataset:Dataset {name: "Broker A IRS Filled Trades"}) -[:HAS_FIELD]-> (field:SourceField {name: "fixed_rate"}) -[m:MAPS_TO]-> (concept:SemanticConcept)OPTIONAL MATCH (concept)-[:REQUIRED_BY_USE_CASE]->(usecase:UseCase)OPTIONAL MATCH (concept)-[:VALIDATED_BY]->(rule:ValidationRule)RETURN field.name AS source_field, concept.name AS semantic_concept, m.confidence AS confidence, m.review_status AS review_status, collect(DISTINCT usecase.name) AS required_by_use_cases, collect(DISTINCT rule.name) AS validation_rules;
This query retrieves evidence for an explanation. An AI agent can turn the result into an answer such as:
The field fixed_rate maps to the semantic concept FixedRate. FixedRate is required by the IRS Valuation Readiness use case and is checked by the FixedRateMustBePresent validation rule. The mapping confidence is 0.88, but the mapping still requires SME review.
This is a much stronger answer than a generic LLM explanation. The answer is grounded in graph evidence.
Query 7: retrieve the full evidence path
Sometimes the agent should retrieve the full path rather than only a table of fields.
MATCH path = (:Dataset {name: "Broker A IRS Filled Trades"}) -[:HAS_FIELD]-> (:SourceField {name: "fixed_rate"}) -[:MAPS_TO]-> (:SemanticConcept) -[:REQUIRED_BY_USE_CASE]-> (:UseCase {name: "IRS Valuation Readiness"})RETURN path;
This is useful when the graph path itself is the evidence. This is the kind of output that can be passed to an LLM as structured evidence. The LLM should not invent the semantic explanation. It should explain the evidence returned by the graph.
Query 8: dataset readiness summary
A demo usually needs a summary view.
Instead of listing every concept, we may want to count how many required concepts are present, missing, or requiring review.
MATCH (usecase:UseCase {name: "IRS Valuation Readiness"})MATCH (required:SemanticConcept)-[:REQUIRED_BY_USE_CASE]->(usecase)OPTIONAL MATCH (dataset:Dataset {name: "Broker A IRS Filled Trades"}) -[:HAS_FIELD]-> (field:SourceField) -[m:MAPS_TO]-> (provided:SemanticConcept {concept_id: required.concept_id})WITH required, CASE WHEN provided IS NULL THEN "missing" WHEN m.review_status = "requires_sme_review" THEN "requires_review" ELSE "present" END AS readiness_statusRETURN readiness_status, count(*) AS concept_countORDER BY readiness_status;
This query produces a simple readiness summary.
That is the kind of result a user can immediately understand. It also gives an AI agent a concise basis for a higher-level answer:
The broker feed is partially ready for IRS valuation.Most required concepts are present, but several mappings require SME review, and some required concepts are missing.
Query 9: concepts provided by multiple datasets
If multiple datasets provide the same concept, the graph can show overlap and possible redundancy.
MATCH (dataset:Dataset) -[:HAS_FIELD]-> (field:SourceField) -[m:MAPS_TO]-> (concept:SemanticConcept)WITH concept, collect(DISTINCT { dataset: dataset.name, field: field.name, review_status: m.review_status, confidence: m.confidence }) AS providersWHERE size(providers) > 1RETURN concept.name AS semantic_concept, providersORDER BY semantic_concept;
This kind of query can support source selection. If a concept is available from multiple datasets, the next question becomes:
Which source is authoritative?Which mapping is approved?Which field has higher confidence?Which source should be used for this use case?
Query 10: search before traversal
So far, the queries assume that we know the exact dataset, field, or concept name.
In reality, users often do not use canonical names.
A user may ask:
Do we have the fixed coupon?Can this feed support IRS valuation?Where can I find the swap rate?
These phrases may need to be resolved to candidate graph nodes before traversal.
One approach is to use full-text search over field names, concept names, descriptions, and synonyms.
The exact index design depends on the implementation, but the conceptual pattern is:
CALL db.index.fulltext.queryNodes("semantic_term_index", "fixed coupon")YIELD node, scoreRETURN labels(node) AS labels, node.name AS name, scoreORDER BY score DESCLIMIT 10;
After finding a candidate concept, the system can continue graph traversal:
MATCH (concept:SemanticConcept {name: "FixedRate"})OPTIONAL MATCH (field:SourceField)-[:MAPS_TO]->(concept)OPTIONAL MATCH (concept)-[:REQUIRED_BY_USE_CASE]->(usecase:UseCase)OPTIONAL MATCH (concept)-[:VALIDATED_BY]->(rule:ValidationRule)RETURN concept.name AS semantic_concept, collect(DISTINCT field.name) AS source_fields, collect(DISTINCT usecase.name) AS use_cases, collect(DISTINCT rule.name) AS validation_rules;
This creates a useful retrieval pattern:
user phrase→ search candidate node→ traverse graph→ return evidence path→ generate answer
This is the bridge from semantic search to graph-grounded reasoning.
What Cypher gives the Agentic Semantic Layer
These examples show that Cypher is not just a database query language in this context. It becomes a way to retrieve structured semantic evidence.
For an Agentic Semantic Layer, Cypher can support operations such as:
resolve source fields to semantic conceptsturn a physical dataset into a semantic inventorycompare required concepts with provided conceptsclassify concepts as present, missing, or requiring reviewfind missing conceptsfind alternative source systemsfind high-impact mappings requiring SME reviewretrieve evidence paths for AI answerssummarise dataset readiness
This matters because the LLM should not own the truth. The LLM should orchestrate tools that query governed semantic structures. Cypher can provide the evidence. The LLM can explain the evidence.
Conclusion
This article only uses a small illustrative scenario. It does not cover the full semantic graph design. It does not cover production ingestion. It does not cover large-scale performance tuning. It does not cover Neo4j GraphRAG in depth. It also does not cover how an agent should decide which query to run.
Those are separate questions. The goal here is simply to test whether useful financial semantic questions can be expressed clearly as graph queries. The answer seems to be yes. Cypher can express the kinds of traversals that an Agentic Semantic Layer needs.
A user may not ask using the exact field name or semantic concept name. They may ask questions such as:
Do we have the fixed coupon needed for valuation?Can this broker feed support IRS valuation?Where can I find the day count convention?Which mappings block valuation readiness?Why is this field required?
In this article, I only used a simple full-text search example to find a candidate graph node before continuing the traversal. That is useful, but it is still a basic retrieval pattern.
The harder question is what should happen when the user phrase is ambiguous, incomplete, or business-oriented. For example, “fixed coupon” may refer to FixedRate; “day count” may refer to DayCountConvention; “valuation readiness” may require multiple concepts, mappings, validation rules, and review statuses.
That requires more than a single Cypher query. It may require a combination of:
full-text searchvector searchcandidate rankinggraph traversalpath retrievalevidence scoringanswer generation
So Cypher makes the semantic graph queryable. The next step is to investigate how graph search and GraphRAG can make the graph retrievable for AI agents.
Data Ninjago (Financial Data Architecture) 