Skip to content

How to Build AI That Explains Itself: Causal Ontology in IROHA

By OpenKuber Research ·

Author: Abhijeet M
Published Date: 2026-07-03T08:23:31.251Z


Most financial AI tells you what happened. We built the machinery to tell you why, traced to a verifiable source, structured as a graph, explainable to anyone.

Why Is HDFCBANK Moving Today?


Open any trading terminal on any morning in India and you will see the same thing. A price. A percentage. Maybe a chart. Maybe a news headline scraped from Moneycontrol. What you will almost never see is an answer to the only question that actually matters for making a decision: why is this stock moving?

Not "what is the RSI?" Not "is it above the 200-DMA?" Those are measurements of movement, not explanations of it. An RSI of 28 tells you a stock has fallen. It does not tell you whether the fall is because of a SEBI order, a FII block deal, an RBI policy tone shift, or a rural FMCG channel check that leaked through WhatsApp before the official earnings call.

This distinction between correlation-based measurement and causal explanation is the entire design thesis of IROHA. And to build something that explains causation rather than observing correlation, you need an ontology. Not a database. Not a dashboard. An ontological model of how Indian financial reality is connected.

Prediction without explanation is a coin flip with extra steps. The RIA who can tell a client "here's exactly why your portfolio moved today, with citations" has a fundamentally different product than one who says "markets were volatile."

  • OpenKuber internal design principle

Nouns, Verbs, and the Architecture of Meaning

The word "ontology" comes from philosophy it is literally the study of what exists. In computer science, an ontology is a formal specification of the concepts in a domain, the relationships between them, and the rules that govern those relationships. It is, in the most precise sense, a machine-readable map of how a domain of knowledge fits together.

Palantir, whose Foundry platform is one of the architectures IROHA draws from, describes its ontology system this way: the Ontology represents not just data, but the complex, interconnected decisions of an enterprise. Objects are nouns. Actions are verbs. Logic ties them together. Security governs who can see what.

For a financial platform operating in Indian markets, this breaks down as follows:

Image

This is the critical distinction between a data pipeline and an ontology. A data pipeline moves numbers from one place to another. An ontology models the meaning of those numbers and the relationships between them. When IROHA answers "why is HDFCBANK moving today," it is not doing a keyword search. It is traversing a graph of causal relationships, each node a verified entity, each edge a typed relationship, each relationship traced to a primary source document.

The Spurious Signal Problem in Indian Markets

Here is the trap every retail investor and most quantitative models fall into: they observe that two things move together and conclude that one causes the other. This is the foundational confusion between correlation and causation, and in financial markets it is not just intellectually sloppy, it is actively dangerous.

A concrete example from NIFTY 50 data. Between 2020 and 2024, ice cream sales in Maharashtra and NIFTY 50 returns had a statistically significant positive correlation. Both went up in summer months. The model that finds this correlation and acts on it does not know that the real driver is a third variable: economic activity. Heat means more leisure spending and more economic activity that causes both ice cream sales and equity returns to rise together. The ice cream is not causing the stock market to move.

Image

The problem is not that correlation is useless. It is that correlation without causal structure leads to catastrophic model failures during regime changes. When the regime changes a new RBI governor, a changed FII classification, a monsoon anomaly purely correlational models break immediately because they were never modeling the underlying causal mechanism. They were modeling a statistical shadow of it.

Causal AI, grounded in the Pearlian framework of Structural Causal Models (SCMs) and Directed Acyclic Graphs (DAGs), is not just a more sophisticated statistical technique. It is a fundamentally different question being asked: not "does X correlate with Y" but "does X cause Y, and through what mechanism, and can we verify that with data?"

The three questions that separate causal from correlational AI

Image

The Citation-Forward Architecture

Explainability in AI is not just a regulatory checkbox. For SEBI-registered RIAs, it is the product. An RIA managing client wealth has a fiduciary duty. When a client asks "why did you recommend reducing HDFCBANK exposure?", "the model suggested it" is not an answer. The regulator does not accept it. The client does not accept it. And frankly, it should not be accepted it is a delegation of judgment to a black box.

The ontological approach to explainable AI solves this by inverting the usual architecture. Instead of producing an answer and then post-hoc explaining it (which is what LIME, SHAP, and attribution methods do), the ontology structures the reasoning before the answer is generated. Every claim in the output has a traceable path through the graph. Every node in the path has a source. Every source has a timestamp and a document reference.

This is what we mean by citation-forward: the citation is not appended to the answer. The citation is part of the structural path that generated the answer.

Every causal claim IROHA makes must satisfy: Entity → Relationship → Entity → Source Document. No orphan claims. No unsourced edges. If a node in the causal graph cannot be traced to a verifiable primary source (NSE filing, RBI bulletin, SEBI circular, IMD report), it is not added to the graph. This is not a goal. It is a hard architectural constraint.

The IROHA ontology schema in practice

json
# IROHA Ontology Node Schema (simplified)
{
 "entity_id": "RBI_REPO_RATE_APR2026",
 "entity_type": "MacroSignal",
 "properties": {
 "value": 6.25,
 "unit": "percent",
 "direction": "cut_25bps",
 "policy_tone": "accommodative_with_caution"
 },
 "citation": {
 "source": "RBI",
 "document": "MPC_Minutes_Apr_2026",
 "url": "https://rbi.org.in/Scripts/...",
 "retrieved_at": "2026-04-04T09:30:00+05:30"
 },
 "causal_edges": [
 {
 "target": "BANKING_SECTOR_NIM",
 "relationship": "CAUSES_COMPRESSION",
 "mechanism": "deposit_repricing_lag",
 "effect_size": -0.12,
 "confidence": 0.81,
 "lag_days": 45
 }
 ]
}

This schema does something that no standard time-series database or vector store does: it encodes the mechanism of a relationship, not just the fact of it. "RBI cut rates" is a fact. "RBI cut rates, and this causes NIM compression in banks with a 45-day lag due to deposit repricing lag, with an estimated effect size of -12bps and 81% confidence" is an explanation. The first is a data point. The second is intelligence.

The Knowledge Graph Architecture: Domains, Not Data Sources

Most financial intelligence systems are built around data sources: feeds, APIs, vendor subscriptions arranged in a pipeline and handed to a model. IROHA is built differently. The ontology is structured around causal domains: distinct epistemic regions of financial reality, each with its own ingestion cadence, citation requirements, and mechanism types. Calling this "five domains" understates it. It is five families of causal structure, each of which contains dozens of entity types, hundreds of relationship templates, and an open-ended number of instances that evolve in real time. The architecture below represents the current v0.1 taxonomy not a ceiling, but a foundation designed to be extended. The domains interoperate through a shared entity resolution layer, which is where the real analytical power lives.

Image

The entity resolution layer is what makes cross-domain intelligence non-trivial. When a monetary policy event in Domain I propagates through to a corporate earnings revision in Domain IV, and that revision coincides with a structural FII exit in Domain II, IROHA's graph does not treat these as three separate observations but it treats them as three threads in a single causal explanation. The entity node for HDFCBANK can hold active causal edges from all five domains simultaneously, each weighted by confidence and recency, each traceable to a primary source. That is the architecture a regime-change-aware system needs: not more data, but more precisely structured causal relationships between the data it already ingests.

A news aggregator shows you headlines. IROHA's ontology shows you the causal paths between events. A headline says "RBI cuts repo rate by 25bps." The ontology says "RBI repo rate cut → banking sector NIM compression (lag: 45d) → HDFCBANK EPS revision (effect: -3.2%) → institutional rerating (confidence: 0.74)." Same event. Fundamentally different utility for a decision-maker.

The Reasoning Layer: Where Causal Structure Meets Execution

Software systems are easy to describe in layers. What is harder and more revealing is being precise about what each layer guarantees and why a given design decision was made. OpenKuber's architecture is four tiers, but the relationships between them are not merely sequential. They are epistemically dependent: each layer assumes specific guarantees from the one below it, and makes specific guarantees to the one above. Understanding that dependency structure is what separates a system designed for correctness from one designed for the appearance of correctness.

Image

The ontology is not a component of IROHA it is the substrate the entire L3→L4 relationship depends on. Without typed causal structure, BISON cannot audit. Without citation anchors, explanation collapses into assertion. The design principle here borrows from compiler theory: the precision of your output is bounded by the precision of your intermediate representation. For OpenKuber, the causal ontology is that intermediate representation. Everything downstream of ASAHI is only as rigorous as the graph it runs on.

The Palantir parallel and where the analogy breaks

Palantir's Foundry Ontology is the closest architectural reference: a system designed to represent not just data but the interconnected decisions of an enterprise objects as nouns, actions as verbs, logic as connective tissue, security woven through everything. That framing is genuinely useful for understanding what an ontology is trying to accomplish at the infrastructure level.

But the analogy has limits worth being precise about. Palantir's ontology is fundamentally an operational graph it models what exists and what actions can be taken on it. IROHA's ontology is a causal graph it models not just what exists, but what causes what, through what mechanism, with what lag, and at what confidence level. The edges carry semantic load that a standard operational ontology does not need. A Palantir edge might represent "flight X is scheduled for crew manifest Y." An IROHA edge encodes "RBI repo rate cut causes NIM compression in the banking sector, via deposit repricing lag, with effect size −12bps, confidence 0.81, over a 45-day horizon, per MPC Minutes April 2026." The mechanism, the effect estimate, the confidence, and the citation are all structurally part of the edge not annotations appended to it after the fact.

The showcase at labh.openkuber.com is not a sandbox. It is a production instance of the L1→L3 pipeline running against real market data. Every position it holds is backed by a traversable causal graph built before the trade was taken. The causal chain is not retrospective rationalisation it is the decision structure that produced the position, visible after the fact precisely because it existed before it.

The Intelligence Gap: When the Answer Isn't Enough

There is a specific failure mode in financial AI that does not get enough attention. It is not the failure to produce a correct answer. It is the failure to produce an answer that can be interrogated. A system that says "reduce HDFCBANK exposure by 8%" may be right. But if the person acting on that output cannot trace why; cannot walk through the reasoning, cannot point to the evidence, cannot identify what would have to change for the answer to change then they are not using intelligence. They are delegating judgment to a black box and hoping the black box is having a good day.

This is not a theoretical concern. It is the operational reality of anyone who manages other people's money, advises on investment decisions, or sits in front of a client and is expected to explain what the system told them. The explainability requirement is not about satisfying regulators though it does that too. It is about the fundamental accountability structure of any advisory relationship. When something goes wrong, "the model said so" is not a defensible position. It is an admission that the practitioner did not actually understand the recommendation they were acting on.

IROHA is designed around this constraint from first principles. The causal graph is not a feature added to make the system more transparent. It is the primary output. The recommendation if there is one is downstream of the graph, not the other way around. An advisor using IROHA does not receive a signal and then look for justification. They receive a causal structure and then decide whether the evidence warrants action. That inversion is the entire point.

A system that can explain its reasoning is not just more trustworthy. It is fundamentally more useful because it can be corrected, refined, and interrogated in ways a black box cannot.

The practical consequence of this architecture is that IROHA's outputs are structured for conversation, not just consumption. When a client asks why a position was changed, the answer is not a summary statistic. It is a traversable argument: these factors shifted, through these mechanisms, with these confidence levels, sourced from these primary documents. The client can disagree with any step. The advisor can defend any edge. That is what a defensible investment process looks like not a number from a model, but a reasoned position that can withstand scrutiny.

IROHA's causal ontology UI is the primary demo artifact for OpenKuber's @Tiny_Fish Accelerator Phase 2 presentation. The demo centers on a live HDFCBANK causal graph traversal taking the question "why is HDFCBANK down 2.3% today?" and showing, in real-time, how IROHA traces the answer through the five ontological domains to a set of cited, mechanism-typed causal explanations. Not a prediction. A diagnosis with receipts.

Also Checkout:


OpenKuber provides research infrastructure to regulated financial firms. Nothing on this site is investment advice or a recommendation to buy, sell or hold any security. OpenKuber is not registered with SEBI as an investment adviser or research analyst. Past price moves and model results do not indicate future performance. LabhLabs results come from paper trading; no real money is used.

Related: The Map Forward: Stateful Agents and Causal Architecture · Why Anakin Failed Performing in Indian Markets · How IROHA works