From Table-Driven to Ontology-Driven: Why Data Alone Can't Explain Business

A customer asks why an order arrived three days late despite a promised 10th‑day delivery. The system shows status "completed" and an AI lists amount, tracking number, and sign‑off date — yet the real question remains unanswered. Digging further, the AI finds a failed inventory allocation and a delivery‑date change request, then concludes: "Due to stock shortage, both parties agreed to defer; order delivered." But did the customer actually approve the deferral? Does the allocation failure explain the full three‑day gap?

Same Status, Different Meanings

In sales, "completed" may mean order closed; in warehousing, goods shipped; in logistics, customer signed. "Delivery date" can be the original contract date, the warehouse’s planned ship date, or the revised committed date. Unifying field names without defining their business semantics hides these differences. Ontology‑driven design starts by agreeing with domain experts: which delivery? which date is the promise? what proves delivery? Only then map to tables, APIs, and documents. A well‑modeled relational database can achieve this; no graph database is required.

Process Model vs. Actual Execution

An Object‑Process Methodology (OPM) model can depict orders, states, and processes — e.g., "adjust delivery date requires customer confirmation." But the model alone cannot prove that a specific order actually went through a valid adjustment. You must locate the corresponding request, confirmation artifacts, and the rules in force at that time. A flowchart cannot create missing records.

Laying Out One Order’s Evidence

Assume an order promised 10 Sep delivery, actual sign‑off 13 Sep. The system holds:

1 Sep : Contract confirms 10 Sep delivery.

9 Sep : Inventory allocation fails, tagged "stock shortage."

10 Sep : Customer service submits request to move delivery to 13 Sep.

13 Sep : Logistics records full sign‑off with proof.

Three days late per original date. Whether the deferral took effect depends on finding approval records. If the AI cannot locate confirmation, it must say "no confirmation found" — not assume the customer never agreed. Any later‑found confirmation must be checked against the specific request and the rules valid at that time. The cause of delay (stock vs. transport) requires further evidence: re‑allocation, shipment timestamps, transit dwell time. A filled "delay reason" field is not proof unless its author, basis, and verification are known.

Time Order ≠ Causality

Allocation failure followed by late sign‑off looks causal, but another warehouse might have shipped the same day, with the real delay in transport. To explain cause, trace: was there a re‑allocation? when shipped? where did the dwell occur? Ontology‑defined relationships (which allocation belongs to which order, which approval targets which request version, which sign‑off covers which batch) prevent stitching unrelated logs into a false narrative.

Given the available evidence, the AI can tell the service agent: "Per original 10 Sep date, order is three days late. 9 Sep allocation failed; 10 Sep deferral requested but no effective confirmation found. Cannot attribute all three days to stock alone. Need to check deferral approval, subsequent supply, and transport records." Links to the source records let the agent continue investigating.

Incremental Adoption in Legacy Systems

Start with a concrete question: "Why was this order delayed?" Follow the trail; gaps reveal what to fix.

Ask domain experts first: What counts as delivery? Which date is the commitment? Who must approve a deferral? Data and app teams then verify whether existing records suffice. Do not let a field named "completed" dictate business meaning.

Can we assemble one order’s full dossier? Data and source‑system owners must align order IDs across systems, correlate request versions, allocation tasks, and delivery batches. A sign‑off for batch 1 cannot prove batch 2 arrived. Records may stay in their original systems; links must be accurate. Business occurrence time (13 Sep sign‑off) differs from platform ingestion time (14 Sep sync) — retrospectives must not use later‑arrived data as if it were known earlier.

What to capture for future changes: A checklist for each business event:

Object identity, event ID, business type — identify which order, which change, deduplicate.

Occurrence time vs. record/receipt time — separate business moment from system awareness.

Change content and triggering request — know what changed and why.

Source system and evidence reference — retrieve original proof, respect permissions.

Roles, confirmations, approvals — distinguish submitter, confirmer, executor.

Applicable rules and versions — re‑evaluate with the rules in force at that time; preserve historical links on corrections.

Will records survive once the business act is done? Use patterns like AWS Transactional Outbox: persist business state and outbound events in the same DB transaction, then publish events; consumers must handle duplicates. This does not cover all cross‑system actions — receipts and downstream success still need separate verification.

Ontology‑Driven ≠ Full Rewrite or Event Sourcing

Event sourcing stores the event stream as the system of record, enabling replay but adding versioning, query, and maintenance complexity (Microsoft Azure Architecture Center warns of these trade‑offs). You can keep the existing transactional database for current state, add missing records, and expose a semantic query layer that translates unified business concepts to source‑system data. Query results must indicate data freshness; any write operation re‑validates current state, permissions, and rules in the executing system. For simple, low‑risk, well‑understood data, the extra ontology and event platform are unnecessary. Invest when disputes over "what counts as delivery" or "why delayed" repeatedly consume manual effort and affect customer commitments or stocking plans — and budget for ongoing model, mapping, and record‑keeping maintenance.

Validate with Real Questions

Success is not measured by number of objects or tables linked. Domain and quality leads should pick a set of manually verified orders — including normal, unapproved deferrals, late‑arriving records, conflicting system claims, partial shipments — and test:

Can the system separate original date, effective revised date, and actual sign‑off date?

Does every conclusion cite evidence? When evidence is missing or contradictory, does it avoid fabricating an answer?

Are duplicate events (e.g., same notification received twice) counted as a single business change?

Has the time for agents to locate evidence and correct wrong explanations decreased?

Compare against the old query method. If the model exists but agents still struggle or mix up batch sign‑offs, the modeling and mapping need revision.

Summary

The customer cares not about table count or graph databases, but why the order was late and whether the explanation is evidence‑based. Ontology‑driven modeling earns its keep by giving the team a shared understanding of "delivery," "deferral," "confirmation" and by making those definitions traceable to concrete records in each order. Then, whether a new agent or a new AI assistant picks up the case, they don’t have to guess from scratch.

References

Lao Ma Zhi, "From Table‑Driven to Ontology‑Driven: The Shift in Business System Modeling for the AI Era," InfoQ Writing Community, 11 Sep 2026. This article extends that perspective with the order case, evidence checklist, and acceptance criteria; not a disclosure of the original project’s results. https://xie.infoq.cn/article/6dede5741f690a96aae024c95 AWS Prescriptive Guidance, Transactional Outbox Pattern. Used for dual‑write consistency between business updates and event notifications, and duplicate‑message handling boundaries.

https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html

Microsoft Azure Architecture Center, Event Sourcing Pattern. Distinguishes domain event logging from event sourcing, and outlines the latter’s applicability and engineering costs.

https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing