After writing the previous article, What is a Financial Product at all?, I originally planned to move directly into a concrete overview example of ISDA CDM. However, while researching the semantic layer of QuantFlow, I came across an article about ontology modelling and AI-native applications.

Although the article is not specifically about finance, I found it highly relevant to the direction I am exploring in this series. It helped me clarify why an AI-native financial data foundation should not be understood merely as a better data model, a metadata layer, or an LLM interface on top of financial data.

So before moving into the IRS example, I want to jump the queue and insert this literature review. This is a practitioner literature review rather than an academic paper review. My goal is not to summarise every detail of the original article. Instead, I want to extract the ideas that are most relevant to my work on AI-native financial data foundations and explain how I interpret them in the context of QuantFlow.

The original article, From Ontology to Ontology Modelling, and from Ontology Modelling to AI-Native Applications, was published on Tencent Cloud Developer Community. It is a long-form essay that connects philosophy, abstract modelling, Palantir, Object–Behaviour–Rule modelling, event-driven systems, reasoning paradigms, and ontology-driven AI-native applications. (This article is in Chinese, and you might need to translate)

The parts I found most relevant are:

• Object–Behaviour–Rule modelling
• Ontology as the semantic source of truth
• Hybrid reasoning between LLMs, graphs, rules, and deterministic tools
• Open questions around reliability, evaluation, and semantic drift

These ideas are relevant to the question I am trying to answer:

What kind of financial data foundation is needed when the future users may not only be humans, but also AI agents?

OBR: Object, Behaviour, Rule

One of the core ideas from the article is the author’s Object–Behaviour–Rule framework, or OBR.

In traditional data modelling, we usually focus on objects, attributes, and relationships. We define entities such as trade, product, party, cashflow, schedule, and settlement. We describe their fields and how they are connected. This is useful, but incomplete.

A data model mainly answers one question:

What exists?

But a business domain also needs to answer two other questions:

What can happen?

What must hold?

This is where behaviour and rule become important.

In the author’s framework:

Object modelling answers:
What exists?

Behaviour modelling answers:
What can this object do, or what can happen to it?

Rule modelling answers:
What constraints, validations, or conditions must hold?

In traditional software systems, behaviours and rules are often buried inside application code, object methods, APIs, stored procedures, workflow engines, vendor systems, or human operational knowledge. This design made sense in the Software Era. Applications owned the behaviour. Databases stored the state.

However, in the AI Era, this becomes a problem. AI agents are not traditional applications with every behaviour hard-coded in advance. They need to understand business concepts, reason over data, call tools, generate explanations, and sometimes propose actions. If behaviours and rules remain hidden inside implementation logic, AI agents have no reliable place to obtain the business logic they need.

This is why the author’s argument matters: behaviours and rules should become visible. They should not be treated as invisible implementation details. They should become first-class semantic objects.

For financial data, this idea is especially important. A financial product is not only a data structure. It is also a set of possible behaviours and rule constraints. For example, an interest rate swap should not be represented only as:

product_type = IRS

A richer representation would describe:

Objects:
Trade, product, fixed-rate payout, floating-rate payout, party, observable, schedule, cashflow, settlement

Behaviours:
Book trade, amend trade, fix floating rate, generate cashflow, settle payment, terminate trade

Rules:
Day-count rule, business-day adjustment rule, fixing rule, product qualification rule, settlement rule, validation rule

This gives AI a much more meaningful representation of the financial product. An IRS is not just a label. It is a composition of financial objects. These objects expose behaviours. Those behaviours invoke rules. The rules constrain state changes.

For example:

A floating-rate payout references a floating-rate index.
A fixing event determines the floating rate.
A calculation rule converts rate and notional into a cashflow.
A settlement rule turns the cashflow into a payment obligation.
A lifecycle event may amend, cancel, novate, or terminate the trade.

This is much closer to how an AI-native financial data foundation should represent financial products.

Ontology as the Semantic Source of Truth

Another idea in the article is that ontology models can become the foundation for AI-native applications.

The author argues that traditional software development suffers from translation loss. Business experts describe requirements in natural language. Developers translate those requirements into code. During this process, meaning is often lost, requirements are misunderstood, and the implementation may drift away from the original business intent.

The author suggests a different architecture: use an ontology model as an intermediate language between business meaning and executable software. In this architecture, the ontology model plays three roles.

First, it is the business modelling medium. Business experts and technical teams use it as a shared language to describe objects, behaviours, rules, scenarios, and processes.

Second, it is the generation foundation. Database schemas, APIs, permission policies, tool schemas, and application skeletons can be generated from the ontology model.

Third, it is the AI reasoning context. At run-time, the AI agent uses the ontology to understand user intent, identify relevant objects and behaviours, constrain possible actions, and decide which tools should be called.

This is why the author describes AI as both a builder and an executor. At build-time, AI helps translate business intent into ontology models and then into system artefacts. At run-time, AI helps translate user intent into ontology-defined behaviours and tool execution.

This is a powerful idea. However, for financial data foundations, I would adapt it carefully. I do not think the immediate goal of QuantFlow should be to generate complete financial applications from ontology models. Financial systems are too regulated, too operationally sensitive, and too dependent on deterministic calculation, lineage, entitlement, approval, and audit controls.

However, for QuantFlow, the ontology model can become the semantic source of truth for the financial data foundation. Instead of generating a full financial application, a QuantFlow financial semantic model could generate or drive:

Nested BigQuery / Iceberg / Snowflake schemas
Graph nodes and relationships
Validation rules
Data quality tests
Lineage metadata
AI tool schemas
Semantic documentation
Product model explanations
Rule execution bindings
Agent-safe operating context

This changes how I think about the semantic layer. The semantic layer should not only describe existing data. It should drive how data structures, rules, tools, lineage, documentation, and AI context are produced.

In the author’s application architecture, one ontology YAML can act as the single source of truth for business modelling, program generation, and AI reasoning.

For QuantFlow, the equivalent could be a finance-specific semantic profile:

Financial semantic model as business definition
Financial semantic model as data/code generation foundation
Financial semantic model as AI-agent reasoning context

For example, an ISDA CDM-inspired model of an interest rate swap could define:

Objects:
Trade, product, fixed-rate payout, floating-rate payout, party, observable, schedule, cashflow, settlement

Behaviours:
Book trade, amend trade, fix rate, generate cashflow, settle payment, terminate trade

Rules:
Day count, business day adjustment, fixing rule, settlement rule, product qualification rule

Generated artefacts:
Canonical nested data schema
Validation rules
Graph representation
Tool schema
Lineage model
Documentation
AI explanation context

Hybrid Reasoning: LLMs Should Not Replace Rules

Another important part of the article is the discussion about ontology reasoning. Once we have built an ontology, a natural question appears:

Where does the reasoning capability come from?

The author compares three different reasoning paradigms.

The first is traditional OWL-based semantic reasoning. This is the classic knowledge graph approach, based on description logic. It can support semantic entailment, automatic classification, and consistency checking. It is logically rigorous, but can be expensive to model, maintain, and scale.

The second is graph database reasoning, such as Neo4j and Cypher. This is less about formal logic and more about graph traversal, pattern matching, path discovery, and graph algorithms. It is practical and scalable for many real-world use cases, but it does not provide the same type of formal semantic guarantees as OWL reasoning.

The third is LLM-based natural language reasoning. This is the most flexible approach. A large language model can read structured context, understand ambiguous user questions, translate them into domain concepts, and generate hypotheses. But it also has obvious weaknesses: it is non-deterministic, it may silently violate rules, and its reasoning process may not be fully auditable.

The author’s final view is not to choose one and reject the others. The useful architecture is hybrid reasoning.

In finance, many rules are not optional. Product validation rules, lifecycle rules, settlement rules, regulatory rules, eligibility rules, and data quality rules cannot simply be interpreted by an LLM in a probabilistic way. They often require deterministic execution. Therefore, the ontology should not replace deterministic execution. It should define the meaning and boundaries within which execution happens.

For QuantFlow, this means the semantic layer should not be designed only as a passive knowledge base. It should become the grounding layer for hybrid reasoning.

A user may ask a vague question such as:

Why does this IRS have this cashflow?

An LLM can translate the question into relevant financial concepts:

trade
interest rate payout
calculation period
floating rate fixing
cashflow generation
settlement

The graph can locate the related objects:

Trade → Product → Payout → Schedule → Observable → Fixing → Cashflow

The rule engine can validate the applicable rules:

day count convention
business day adjustment
reset rule
payment date rule
settlement rule

The calculation engine can reproduce the cashflow amount.

The lineage model can show which source data and events produced it.

The AI agent can then generate an explanation that is not just plausible, but grounded in the actual semantic model and deterministic tools. For financial systems, this is not just a design preference. It is necessary for explainability, auditability, lineage, regulatory confidence, and AI reliability.

Open Questions and the Bigger Paradigm Shift

In the final part of the article, the author openly lists several unresolved questions:

How reliable is deep multi-step reasoning?

How should we handle large-scale precise calculation?

Can scenario modelling reduce complexity, or will it become another source of complexity?

How should large ontologies be retrieved into the LLM context?

How much can we reduce LLM variance?

How do we measure whether an ontology is complete enough?

How do we prevent ontology definitions from drifting away from real business practice?

What is the real incremental value compared with GraphRAG, ontology-grounded extraction, and neuro-symbolic knowledge graph approaches?

These questions are actually highly relevent to AI-native financial data foundations. Compared to many other industries, the semantic foundation needs to be more explicit, more testable, more versioned, and more connected to deterministic tools. For QuantFlow, this means the ontology-inspired semantic layer must be evaluated, not only described.

The author ends up with the article with a broader claim: ontology plus AI may represent a structural shift in software architecture.

The author identifies three gaps that traditional software has struggled with.

• Translation gap between business meaning and code – Business experts describe intent in natural language. Developers translate it into implementation. Meaning is often lost in the translation.
• Interaction gap between user intent and traditional UI – Users have to adapt to menus, forms, workflows, and screens. The software does not naturally understand what the user wants.
• Adaptation gap between static software systems and dynamic business change.

The author believes ontology-driven AI-native systems are capable to reduce those gaps: the ontology model becomes a semantic specification of the business; AI helps translate intent into model definitions, model definitions into system artefacts, and user requests into model-grounded actions.

For financial industry specifically, I am not sure whether or not the ontology plus AI will replace all financial software. it sounds a bit too extreme. However, I do think this type of paradigm shift may be unavoidable in financial data foundations.

I cannot predict exactly what the paradiam shift will look like, but just some ad-hoc guesses:

the old application-centric architecture:

Applications own behaviour.
Databases store state.
Reports expose results.
Humans interpret meaning.

towards a more semantic-model-centric architecture:

Semantic models define meaning.
Rules constrain behaviour.
Graphs expose relationships.
Tools execute deterministic logic.
AI agents interpret intent and explain results.
Humans supervise high-impact actions.

Reference

人月聊IT, “从本体论到本体建模，从本体建模到AI原生-长文系统总结我历史文章观点和思维演进”, 2026, https://cloud.tencent.com/developer/article/2681679 (in Chinese)

• AI-Native Financial Data Foundation