While defining Concept, Claim, Practice, and Evidence for WisdomAI, I began to worry: if I add more Buddhist texts later, will these node and relationship types still work? If something new is needed, am I extending the ontology—or merely adding knowledge to the graph?

I had previously treated ontology and knowledge graph as two names for roughly the same thing: nodes, relationships, and a visual network. This practical question exposed the distinction I had missed.

The distinction sounds theoretical until a new text, a disputed interpretation, or a financial exception enters the system. Then it becomes a governance question: is this a new fact, a new category, or evidence that our model of the domain is incomplete?

The library analogy that made it click

A useful first analogy is a library. The ontology is its shared classification and cataloguing system: which kinds of things can be registered and how authors, texts, traditions, themes, and citations may relate. The knowledge graph is the library's actual catalogue: which books are present, which author wrote each book, and which text cites another.

Parent/child chunking is different again: it describes how one book is divided into reviewable sections and smaller retrieval passages. RAG is the process of finding relevant books and passages for a question.

Three layers—not two

The project also forced me to separate domain meaning from engineering representation. An ontology is not the same as the JSON schema used to store it.

A Buddhist domain reviewer evaluates whether the concepts and relationships are meaningful and accurate. Chloe decides how approved knowledge is represented in data, which fields are required, and how versions and permissions work. The reviewer needs visibility into the structure so omissions can be identified, but does not need to design JSON or databases.

WisdomAI: two parallel tracks, one evidence bridge

In WisdomAI, ontology design and parent/child chunking are parallel—not sequential—workstreams. Chunking preserves where a passage begins, ends, and belongs. Ontology defines how knowledge extracted from that passage can be represented. They meet at Evidence.

This separation protects two different kinds of truth. Source structure protects textual context; semantic structure protects the meaning of the interpretation. A small retrieval child may help find the passage, but the approved parent preserves enough context to review it. Evidence then anchors every semantic claim back to its source.

The graph does not become true merely because an LLM created an edge. More precisely, a knowledge graph stores concrete assertions—not truth by default. AI may propose that a Practice cultivates a Concept, but that edge remains proposed until a qualified human reviews its Buddhist meaning. Records can move through proposed, reviewed, approved, rejected, and deprecated states; only approved content may support formal answers.

What happens when a new text does not fit?

The goal is not to design a universal Buddhist ontology in advance. A useful core starts small, then learns from controlled exceptions. When a new source arrives, there are three different changes:

• New instance: a Claim from a new text fits existing classes and relations. Add it to the graph.
• New context: two traditions interpret the same Concept differently. Add a Tradition or Context qualifier without breaking the core.
• New domain object: repeated sources show that Practice alone cannot represent prerequisites, obstacles, or dedication. Consider Prerequisite, Obstacle, or Dedication as a subtype, relation, or new class.
• New core distinction: only when several sources cannot be represented accurately should the core ontology be reviewed and versioned.

This is why ontology is not merely a diagram made before implementation. It is a governed contract that lets the knowledge base grow without silently changing the meaning of old records.

The same missing layer in enterprise finance

An ERP already contains relationships, but that does not automatically make it an enterprise knowledge graph—and a collection of table definitions does not automatically become an ontology.

Suppose FP&A asks: “Why was professional-services expense for the U.S. entity's ERP project 35% over budget in July 2026?” Before explaining anything, the system must fix the analytical grain: actual ledger, budget version, period, legal entity, cost center, account, project, currency, and whether the view is monthly or year-to-date.

Without this scope, “35% over budget” has no stable financial meaning. The variance is also not an ordinary graph fact. It is a governed calculation with a formula, dimensional scope, source datasets, currency basis, timestamp, and lineage.

One variance can have several drivers

A 35% unfavorable variance rarely traces to one invoice. It may combine posted invoices, unbilled accruals, prior-period reversals, timing shifts, scope changes, foreign exchange, reallocations, or a budget baseline that omitted committed work.

The graph may reveal one supporting path—Account 6210 → Journal Entry 2068 → Invoice 7842 → Purchase Order 319 → Vendor A → ERP Project → Contract C-104—but that is one contributor, not the whole explanation. The planning system supplies the approved budget version; the ledger supplies posted actuals; deterministic code calculates the variance; document RAG retrieves the contract, change order, forecast notes, and policy context.

Financial objects that must not be collapsed

A purchase order represents a commitment, not necessarily an expense. An invoice is a vendor claim, not necessarily a posted or paid item. A journal entry recognizes an accounting effect. An accrual can recognize incurred cost before an invoice arrives. A payment settles a payable.

Ontology preserves these distinctions. The graph records the specific connections and their effective dates. A temporal state—Draft, Submitted, Approved, Posted, Paid, or Reversed—matters because the answer may differ between a current view and a historical close-date view.

Variance analysis and accounting treatment are separate branches

Why spending exceeded budget is a management-accounting question. Whether part of the cost should be capitalized, accrued, reclassified, or expensed is a financial-accounting question. Capitalization may change income-statement recognition, but it does not by itself explain why project commitments exceeded plan.

The graph may assert that an expense may require review under a capitalization policy. It should not assert that the cost should be capitalized unless an authorized accounting review has approved that treatment.

Approval is not one generic relationship

Business-spend authorization, purchase-order approval, invoice approval, journal approval, payment release, budget change, and accounting-policy judgment are different authorities. Treating them all as approved_by risks turning operational approval into accounting authorization. The model must also preserve segregation of duties among preparer, reviewer, approver, and payment releaser.

The ontology makes cross-system questions expressible. The knowledge graph makes concrete assertions traceable. Governed source systems remain responsible for balances and official records; deterministic services own calculations; authorized people own judgment and execution.

Why the distinction matters for AI agents

Without ontology, an agent may merge concepts finance must keep separate: invoice date versus posting date, commitment versus expense, cost center versus legal entity, budget owner versus accounting approver, and policy exception versus policy violation.

Without a populated knowledge graph, ontology remains an elegant vocabulary with no concrete evidence to traverse. Without governed metrics, the graph cannot safely calculate balances or variance. The agent needs all three—plus provenance, temporal state, segregation of duties, deterministic controls, and permission boundaries.

The simplest way I now remember the difference is this: ontology is the grammar, the knowledge graph is the set of sentences, and governance determines which sentences the system is allowed to treat as true.

I increasingly believe the hardest part of enterprise AI is not connecting more data. It is deciding what those connections mean, who may confirm them, and under which conditions a system may act on them.