After several articles on tool-using LLMs, graph-grounded reasoning, and evidence-aware generation, I now want to move one level deeper and examine the technical building blocks required to support an Agentic Semantic Layer.

The first technical question is simple:

How should financial semantic meaning be modelled, stored, and exposed so that it can be queried and used by an AI agent?

This article studies Neo4j from that perspective. The focus is not Neo4j as a general-purpose graph database, but Neo4j as a potential semantic store for a financial knowledge graph: a place where financial concepts, product structures, business rules, data mappings, lineage, evidence, and controls can be represented in a form that both humans and AI agents can query.

From Knowledge Graph to Neo4j

Before looking at Neo4j, it is useful to clarify the kind of graph I am interested in.

The goal is not simply to store connected records. The goal is to model connected meaning. In this context, a knowledge graph is a conceptual structure for representing domain concepts and the relationships between them. For financial data, this may include source fields, business terms, semantic concepts, canonical concepts, product components, use cases, validation rules, lineage records, and source systems.

To keep the discussion concrete, I will use a small hypothetical example rather than describe a full semantic graph design. Assume we receive a broker feed with a field called fixed_rate. On its own, this field name is not enough. We want to represent that this physical source field maps to a business concept, that the concept belongs to a product component, that the component is used by a product type, and that the concept may be required by a valuation-readiness use case.

A simplified semantic path may look like this:

BrokerFeed.fixed_rate
→ FixedRate
→ InterestRatePayout
→ InterestRateSwap
→ ValuationReadiness
→ FixedRateMustBePresent

This path is valuable because it explains meaning. It helps answer questions such as:

What does this field mean? Which product component does it belong to? Which product type uses it? Which use case requires it? Which validation rule applies? What evidence supports the answer?

This kind of meaning is difficult to represent cleanly in a flat table. A relational model can store the entities, but the meaning often becomes scattered across many join tables. A document model can store nested structures, but it may hide the relationships that need to be traversed. A data catalogue can describe datasets and columns, but it may not naturally represent multi-hop semantic paths.

A graph model starts from a different assumption: relationships are first-class citizens.

This is where Neo4j becomes relevant. Neo4j is attractive because it combines several capabilities that are useful for a financial semantic knowledge graph.

It provides an intuitive labelled property graph model, where nodes, relationships, labels, and properties map naturally to semantic modelling. It provides Cypher, a readable graph query language for traversing relationships. It has mature tooling for graph modelling, querying, indexing, and visual exploration. It also supports full-text search, vector search, and GraphRAG-style applications, which are relevant when graph structure needs to support AI retrieval and evidence construction.

There are, of course, other graph technologies. Amazon Neptune may be attractive for AWS-native managed graph workloads. TigerGraph may be relevant for large-scale graph analytics and high-performance connected-data processing. RDF / SPARQL-based platforms may be suitable when formal ontology modelling, semantic-web standards, and reasoning are the main priorities.

For this investigation, however, Neo4j is useful because it covers the main capabilities I want to study: graph modelling, relationship traversal, semantic search, graph-based retrieval, visual exploration, and a path toward knowledge-graph-enabled AI applications.

So the point is not simply that Neo4j is a well-known graph database. The point is that Neo4j provides a practical way to make financial semantic relationships queryable, traversable, and later usable as evidence paths for AI agents.

Neo4j capability map

Neo4j is based on the labelled property graph model. Instead of representing everything as rows and columns, Neo4j represents data as nodes, relationships, labels, relationship types, and properties.

For this article, the most relevant Neo4j concepts are:

The most relevant point is not simply that Neo4j stores data as a graph. The important point is that it makes relationships queryable. A semantic model is not only a list of terms. It is a network of meanings.

Modelling the example in Neo4j

Using the fixed_rate scenario, we can describe the graph model in Neo4j terms.

The objects in the path can be represented as nodes:

(:SourceField {name: "fixed_rate"})
(:SemanticConcept {name: "FixedRate"})
(:ProductComponent {name: "InterestRatePayout"})
(:ProductType {name: "InterestRateSwap"})
(:UseCase {name: "ValuationReadiness"})
(:ValidationRule {name: "FixedRateMustBePresent"})

The meaning comes from the relationships between those nodes:

(:SourceField)-[:MAPS_TO]->(:SemanticConcept)
(:SemanticConcept)-[:BELONGS_TO_COMPONENT]->(:ProductComponent)
(:ProductComponent)-[:PART_OF_PRODUCT]->(:ProductType)
(:SemanticConcept)-[:REQUIRED_BY_USE_CASE]->(:UseCase)
(:SemanticConcept)-[:VALIDATED_BY]->(:ValidationRule)

This small example is enough to explain the core Neo4j modelling ideas:

nodes represent semantic objects
labels classify node roles
relationships connect objects
relationship types explain the meaning of each connection
properties store descriptive and governance metadata
Cypher queries can retrieve the path

The example is intentionally small. It is not a full semantic graph design. It is only a technical walkthrough for understanding how Neo4j can represent connected financial meaning.

Nodes and labels

A node represents an entity in the graph.

In the example, fixed_rate can be represented as a source field node:

(:SourceField {name: "fixed_rate"})

FixedRate can be represented as a semantic concept node:

(:SemanticConcept {name: "FixedRate"})

InterestRatePayout can be represented as a product component node:

(:ProductComponent {name: "InterestRatePayout"})

The label tells us what kind of object the node is. SourceField, SemanticConcept, and ProductComponent are labels.

A useful modelling rule is:

If something needs to be connected, reused, governed, searched, or reasoned over, model it as a node.

For example, FixedRate should not only be a string property on a field. It should be a node if other objects may connect to it. In this example, FixedRate may be connected to:

a source field
a product component
a product type
a use case
a validation rule
a synonym
a canonical concept

Once FixedRate becomes a node, the graph can reason around it. It becomes a reusable semantic object rather than a passive text value. This is one of the main benefits of graph modelling.

Relationships and relationship types

Relationships connect nodes. In the example, the source field maps to the semantic concept:

(:SourceField {name: "fixed_rate"})
  -[:MAPS_TO]->
(:SemanticConcept {name: "FixedRate"})

The relationship type MAPS_TO explains the meaning of the connection.

The semantic concept can then be connected to a product component:

(:SemanticConcept {name: "FixedRate"})
  -[:BELONGS_TO_COMPONENT]->
(:ProductComponent {name: "InterestRatePayout"})

The product component can be connected to a product type:

(:ProductComponent {name: "InterestRatePayout"})
  -[:PART_OF_PRODUCT]->
(:ProductType {name: "InterestRateSwap"})

The semantic concept can also be required by a use case:

(:SemanticConcept {name: "FixedRate"})
  -[:REQUIRED_BY_USE_CASE]->
(:UseCase {name: "ValuationReadiness"})

And it can be validated by a rule:

(:SemanticConcept {name: "FixedRate"})
  -[:VALIDATED_BY]->
(:ValidationRule {name: "FixedRateMustBePresent"})

The relationship type should be expressive enough to explain the business meaning of the connection.

A weak graph would only say:

field A is related to concept B

A better graph says:

field A MAPS_TO concept B
concept B BELONGS_TO_COMPONENT component C
concept B REQUIRED_BY_USE_CASE use case D
concept B VALIDATED_BY rule E

This is important because the relationship is not only a technical edge. It is part of the evidence model.

Properties and governance metadata

Properties store attributes on nodes or relationships.

A source field node may have properties such as:

field_id
name
data_type
description
sample_value
dataset_name

For example:

(:SourceField {
  field_id: "broker_irs_fixed_rate",
  name: "fixed_rate",
  data_type: "decimal",
  description: "Fixed coupon rate from broker IRS feed"
})

A semantic concept node may have properties such as:

concept_id
name
display_name
description
domain
status
version

For example:

(:SemanticConcept {
  concept_id: "FixedRate",
  name: "FixedRate",
  display_name: "Fixed Rate",
  domain: "InterestRateDerivatives",
  status: "active"
})

Relationship properties are especially important. A mapping is not always simply true or false. It may be inferred, proposed, reviewed, approved, rejected, or ambiguous. This means the MAPS_TO relationship may need its own metadata.

For example:

(:SourceField)-[:MAPS_TO {
  confidence: 0.86,
  mapping_status: "proposed",
  review_status: "requires_sme_review",
  evidence_source: "field_name_and_description"
}]->(:SemanticConcept)

This allows the graph to represent both the semantic connection and the confidence behind it.

For an AI agent, this matters a lot. The agent should not treat every relationship as equally authoritative. A reviewed mapping and an inferred mapping should not carry the same weight. A mapping that requires SME review should be exposed differently from a fully approved mapping.

This is why relationship properties are not just technical metadata. They are part of semantic governance.

Constraints, indexes, and search

A semantic graph also needs data discipline. Constraints and indexes are not just performance features. They help make graph traversal reliable. For the small example, useful uniqueness constraints might include:

SemanticConcept.concept_id is unique
SourceField.field_id is unique
ProductComponent.component_id is unique
ProductType.product_type_id is unique
UseCase.use_case_id is unique
ValidationRule.rule_id is unique

Useful indexes might include:

SourceField.name
SemanticConcept.name
ProductComponent.name
ProductType.name
UseCase.name
ValidationRule.name

This matters because agentic retrieval depends on reliable entry points. If concept IDs are duplicated, graph traversal becomes unsafe. If field names are not indexed, lookup becomes slow. If mappings are inconsistent, the agent may generate misleading evidence. The graph should therefore not be treated as a loose metadata dump. It should be a governed semantic structure.

Search is also important because users rarely ask questions using perfect canonical names. A user may ask about “coupon”, “fixed coupon”, “swap fixed rate”, or simply “rate”. The graph needs a way to resolve the user’s phrase into a candidate graph node.

A practical pattern may be:

user phrase
→ full-text or vector search
→ candidate SourceField / BusinessTerm / SemanticConcept
→ graph traversal
→ evidence path

For example:

"swap fixed coupon"
→ SemanticConcept: FixedRate
→ ProductComponent: InterestRatePayout
→ ProductType: InterestRateSwap
→ UseCase: ValuationReadiness

This is where full-text search, vector search, and GraphRAG-style retrieval become relevant. They help connect fuzzy user language to structured graph evidence.

This article focuses on graph modelling. The next step is to test how these paths can be queried.

What Neo4j does not decide

Neo4j provides the graph structure, but it does not design the financial semantic model.

It does not decide:

which financial concepts are needed
which fields map to which concepts
which concepts align with a canonical model
which source system is authoritative
which use case requires which concept
which validation rule should apply
which mapping requires SME review

Those decisions still require domain modelling and governance. A poor semantic model stored in Neo4j is still a poor semantic model. Neo4j provides the structure. The domain model provides the meaning. The governance process provides the trust.

Next

This article is only the first step. The next question is whether useful semantic questions can be expressed clearly and efficiently in Cypher. Using the small fixed_rate example, I want to test questions such as:

Given a source field, which semantic concept does it map to?
Given a semantic concept, which product component does it belong to?
Given a semantic concept, which use cases require it?
Given a semantic concept, which validation rules apply?
Given a mapping, what confidence and review status does it have?
Given a fuzzy phrase, which graph node should be used as the starting point?

That leads naturally to the next article:

Cypher by Example: Querying a Financial Semantic Graph

If Neo4j is the graph store, Cypher is the language that makes the semantic graph operational.

• *AI-Native Financial Data Foundation