Lychee Technology Inc.

Appearance

How to Build an Enterprise Ontology Without a 2-Year Knowledge Engineering Project ​

Part 3 of 3 in the Enterprise Ontology series. Part 1 named the failure. Part 2 mapped the architecture. This part is the build playbook.

Ontology projects have a bad reputation, and most of it was earned. The 2010s version was a 2-year program run by a knowledge engineering team, governed by a steering committee, and disconnected from any operational system that mattered. It produced a beautiful taxonomy that nobody used.

That is not the version your agents need.

The pragmatic version starts narrow, ships in weeks, and earns the right to expand by reducing measurable operational pain. Here is what that looks like.

Start where semantic debt is most expensive ​

Do not start with "the enterprise ontology." Pick one workflow where semantic ambiguity is already costing money.

Strong candidate domains:

  • supplier onboarding and payment approvals
  • legal entity reconciliation for risk reporting
  • customer entitlement resolution
  • inventory allocation across warehouses
  • insurance claims triage
  • procurement approvals
  • regulatory case review
  • revenue recognition workflows

The right domain has three properties: clear business value, known semantic ambiguity, and operational pain you can measure today. If finance, ops, and engineering already argue about definitions in this domain, that is the signal.

The six-step build sequence ​

Linear flow diagram showing six numbered steps from Bound the Domain to Add Monitoring, with feedback arrows looping back

1. Bound the domain ​

Pick one workflow. Not a department. Not a system. A workflow.

"Approve supplier payments" is a workflow. "Procurement" is not. Narrow scope shortens the build cycle and clarifies whether the ontology is working.

2. Identify the core business objects ​

For supplier payments: Supplier, Purchase Order, Invoice, Contract, Legal Entity, Bank Account, Receiving Event, Approval Policy, Payment Request.

For risk reporting: Legal Entity, Counterparty, Instrument, Exposure, Guarantee, Jurisdiction, Portfolio, Reporting Obligation.

Aim for less than 10 objects. If you have 20, your domain is too broad.

3. Map source data to business objects ​

Connect the objects to the systems that already hold the data. Start with ERP tables, CRM records, data lake schemas, document repositories, and APIs.

You do not have to duplicate the data. The ontology can act as a semantic layer that binds business objects to source records. This is what platforms like Palantir Foundry's Ontology and Microsoft Fabric's ontology layer are designed to do.

4. Define relationships and constraints ​

This is where the ontology starts paying off for agents. Examples from the supplier-payment domain:

  • A Supplier must have a verified Bank Account before payment.
  • An Invoice must reference a valid Purchase Order, unless an exception policy applies.
  • A Receiving Event must exist for goods-based invoices.
  • A high-risk Jurisdiction triggers additional Approval requirements.
  • A Legal Entity may have parent, subsidiary, branch, and affiliate relationships affecting reporting.

These are the rules that scattered documents and tribal knowledge encode today. Write them down once, machine-readable.

5. Connect actions to preconditions ​

Every governed action gets explicit preconditions. The agent does not call the tool because the tool exists, it calls the tool because the preconditions are satisfied.

Examples:

  • The agent may draft a payment recommendation. It may not approve payments above $50,000.
  • The agent may update a CRM field if source evidence meets confidence requirements.
  • The agent may escalate a case. It may not close one without human approval.
  • The agent may prepare a regulatory filing. It must route the filing for review before submission.

This is the layer that turns the ontology from documentation into kinetic infrastructure.

6. Add monitoring and feedback loops ​

Ontology quality is measured in production. Track where agents misinterpret objects, where constraints are missing, where humans override decisions. Feed those failures back into the ontology.

Ontology is not a one-time project. It is a living governance discipline.

Industry anchor: financial services ​

If you are in financial services, you do not have to start from scratch.

The Financial Industry Business Ontology (FIBO) provides a formal model of legal entities, instruments, contracts, ownership structures, obligations, securities, loans, and derivatives. It defines the relationships in a machine-interpretable form.

For risk reporting, FIBO maps cleanly to the goals of BCBS 239, the Basel Committee on Banking Supervision's principles on risk data aggregation. BCBS 239 demands accuracy, integrity, completeness, adaptability, lineage, and consistent taxonomies across the bank. An ontology is the only practical way to deliver those guarantees to an agent.

The bank that uses FIBO-aligned objects can ask: are these two records the same legal entity? Which exposures aggregate together? Which jurisdictional rules apply? It can answer programmatically. The bank that does not is matching strings and hoping.

Measuring ontology ROI ​

Six metrics will tell you whether the ontology is reducing ambiguity or just adding another architecture diagram.

  1. Semantic failure rate. How often do agents make errors because they misunderstood an object, relationship, or definition? Track over time.
  2. Decision consistency. Do agents produce equivalent outcomes for logically equivalent inputs across teams, regions, and systems? Inconsistency is a signal that the semantic layer is incomplete.
  3. Reconciliation effort. Hours per week spent matching records, resolving entity ambiguity, and explaining cross-system discrepancies. A working ontology drives this number down.
  4. Auditability. Can you reconstruct why the agent made a recommendation or took an action, from source data to business object to inference to decision? If yes, the lineage is working. If no, you have a governance problem.
  5. Human remediation cost. How much time do people spend correcting agent outputs? Track count, severity, and cycle time. The ontology should reduce repeat corrections.
  6. Action rejection quality. How often do policy and validation layers block, modify, or escalate proposed actions? The goal is not zero rejections. In high-risk workflows, targeted rejections show the control plane is working.

What ontology won't do ​

Ontology will not fix bad data. If your source records are wrong, the agent will reason correctly over wrong objects.

Ontology will not replace access control, tool permissions, action validation, or human-in-the-loop escalation. It is one layer in the control plane, not the whole plane.

Ontology will not make unsafe automation safe. If your action schemas are too permissive, the ontology makes it easier for agents to do the wrong thing with confidence.

And an outdated ontology is worse than no ontology because agents will enforce stale constraints with the same conviction they would enforce current ones. Versioning and governance are non-negotiable.

Govern it like production infrastructure ​

Treat the ontology as production infrastructure, not a wiki page.

Every object, relationship, constraint, and action schema needs an owner. Each change needs a review path. Each release needs versioning. Each agent action needs traceability back to the ontology version it used.

This matters because business rules move.

Approval thresholds change. Legal entities merge. Sanctions statuses update. Product definitions shift. Jurisdictional rules change. Source systems rename fields.

If the ontology does not move with the business, agents will apply stale logic with confidence.

The governance loop should be simple:

  • business owner proposes a semantic change
  • data or platform owner maps the change to source systems
  • risk or compliance owner reviews constraints
  • engineering owner updates action preconditions
  • monitoring confirms whether failures decrease

Do not build a ceremony-heavy governance board before the ontology has users. Start with clear ownership and release discipline for one workflow.

Where to start ​

The question is no longer "do enterprise agents need business semantics?" They do. The useful question is:

Which workflow in your business is paying the highest tax on semantic ambiguity today, and what would change if an agent could operate on governed objects there?

That is where to start. Not with the enterprise ontology. With the one workflow where the semantic blindspot is already expensive.

References ​