Can LLMs Auto-Build Ontologies? AI Finds Candidates, Business Defines Reality

Feeding dozens of policies, requirements documents, database schemas, and meeting minutes into a large language model (LLM) can produce a structurally complete ontology graph — including objects, attributes, relationships, constraints, and even RDF, OWL, or SHACL files — within minutes. This magical demo easily traps teams into thinking LLMs can fully automate ontology modeling and eliminate manual knowledge engineering.

The answer: LLMs significantly accelerate ontology engineering, but generating a formally correct model draft is not the same as defining business reality that can enter production systems.

LLMs suit discovering candidate knowledge, forming candidate models, assisting checks, and generating tests; business objects, boundaries, valid rules, and exception ownership must still be confirmed by people with business accountability.

First, dispel an illusion: four tasks that are not automatic modeling

Many auto-ontology demos actually perform only one of these four tasks:

Entity and relation extraction — e.g., extracting customers, orders, dates, and their relations from contracts. This identifies facts or instances in text but does not define stable business concepts and constraints.

Data structure conversion — turning tables, columns, and foreign keys into classes, properties, and relationships. This replicates system structure but may not express true business meaning, states, or responsibility boundaries.

Terminology normalization — mapping "customer ID", "cust_no", "Customer ID" to a unified term. This resolves name differences but does not prove the fields refer to the same business identity.

Formalization generation — producing RDF, OWL, SHACL, or query statements from descriptions. This proves the model can output standard syntax, not that object boundaries, rule semantics, and business outcomes are correct.

These capabilities are valuable but only partial tasks in ontology engineering. W3C's OWL 2 Primer emphasizes that an ontology is a precise description of a domain where terms and their relationships are explicitly fixed; OWL is a declarative language with formal semantics, not just another data format (reference [1]). Therefore, generating triples ≠ completing modeling; generating parsable OWL ≠ correctly describing business.

What LLMs can already help with in ontology engineering

Given clear input materials, task boundaries, and output contracts, LLMs can handle four groups of high-cost auxiliary work:

Discover candidate knowledge and model elements

LLMs can organize objects, attributes, events, states, rules, and exceptions from policies, contracts, SOPs, interface docs, historical tickets, and interview records, preserving original text locations and proposing class hierarchies, relationships, and constraints under scenario and competency-question constraints. The output is not "auto-discovered truth" but a candidate list to improve material coverage, expose terminology, and reveal source conflicts. A 2025 preprint study had LLMs generate OWL ontology drafts from user stories and competency questions; some model/prompt configurations achieved high quality but still exhibited superfluous elements, wrong domain/range, naming inconsistencies, and unstable restatement of complex restrictions and relations (reference [2]).

Generate formal artifacts and assist alignment

After structural constraints, LLMs can generate RDF, OWL, SHACL, queries, data mappings, and model docs; retrieve reference ontologies and internal terminology registries; propose reuse or mapping suggestions. This aligns with the "standards as compilation targets" idea: business people confirm the business model first, then the engineering pipeline generates standard artifacts. Similar names do not imply identical identity, lifecycle, or responsibility meaning, so automatic alignment only yields candidates and cannot override existing baselines.

Generate competency questions and boundary examples

LLMs can supplement competency questions from scenario cards and model drafts, generate test situations for conditions true/false, missing evidence, conflicting facts, and out-of-scope cases, and produce query or constraint test drafts. Related research positions this as automated or semi-automated evaluation support, not a replacement for human-established gold standards (reference [3]).

Combine with deterministic tools for structural checking

LLMs can work with parsers, reasoners, SHACL validators, and rule tests to explain syntax errors, duplicate concepts, unreasonable constraints, and competency-question coverage gaps, and propose repair candidates. A 2026 preprint based on insurance contracts found that splitting tasks into domain, management, coding, and quality-check roles improved structural quality, but query usability gains were limited; main benefits came from upfront planning and artifact decomposition (reference [4]). This shows the real value lies in designing clear inputs, roles, artifacts, and validation standards first — not in letting more agents debate. Results come from benchmarks or controlled experiments and do not prove unsupervised auto-construction is ready for enterprise production.

Essential boundary: why AI cannot replace business in "defining reality"

"Defining reality" here means confirming which business meanings, rules, and responsibilities the enterprise system is willing to formally commit to. Once a definition enters the ontology baseline, it may be reused by data governance, queries, rules, agents, and business systems; errors propagate stably. The core problem is not just hallucination — LLMs lack authority to answer four categories of questions:

What should be modeled

High-frequency terms in materials are not necessarily core concepts; low-frequency exceptions may decide risk boundaries. "Account managers often check orders" may not need to enter the ontology; "approved extensions take precedence over original delivery dates" appears rarely but may decide lateness judgments. Models can induce from materials but cannot decide which business parts the project is accountable for.

Whether two names represent the same business object

"Customer" in the database, "signing party" in the contract, and "customer" in sales talk may relate but not be directly mergeable. Group, legal entity, invoicing party, consignee, and credit-responsible party may have different identities and lifecycles. Such boundaries must be decided by policies, data sources, responsibility consequences, and competency questions — not text similarity.

Which rule is valid under current conditions

Policy documents, historical operations, system code, and frontline experience may conflict. LLMs can spot differences but cannot confirm which is still effective, who has interpretation authority, whether historical practice was non-compliant, or when new rules take effect. They also tend to treat "no extension approval found" as "certainly no extension approval exists." Under open-world semantics or incomplete data, missing records usually mean "unknown" or "insufficient evidence," not a negative conclusion.

Who bears the business consequences

Risk flags, limit adjustments, shipment holds, and formal notifications produce different consequences. Models can propose action candidates but cannot grant themselves permissions or assume responsibility on behalf of account managers, risk owners, or approvers. Therefore, ontologies may define action semantics, preconditions, and evidence requirements, but actual action authorization must enter deterministic permission, approval, transaction, and audit systems.

See a "reasonable but wrong" auto-modeling case: order fulfillment

Assume the team feeds the LLM four material types:

ERP order table and promised_delivery_date field;

Contract clauses on delivery dates and extension agreements;

Sales-maintained "extension under communication" records;

Business rule: "generate alert 3 business days after delivery date."

The LLM would likely quickly generate definitions such as: Order has promisedDeliveryDate; if current date > promisedDeliveryDate + 3 days then create RiskTask with hasEffectiveDeliveryDate.

If released directly, syntax may be perfect but business meaning wrong. After business, data, and risk owners confirm, a more sound definition: Order remains "pending fulfillment"; system generates "to-be-confirmed" risk task based on valid contract, approved extensions, delivery records, and observation time; missing or conflicting evidence triggers manual review; only after authorization does it become a formal alert.

The real difficulty is not writing Order, RiskTask, and hasEffectiveDeliveryDate in OWL, but confirming object boundaries, evidence for effective date, whether "no record" means negative or unknown, and the permissions and responsibilities required for risk-to-alert escalation. These questions can only be raised by the LLM, not answered by it for the enterprise.

Seven-step human-AI collaborative ontology building process

To let LLMs truly enter ontology engineering, place automation in the candidate and validation layers, not directly connected to the formal baseline. This is not a straight line from materials to ontology but a funnel that diverges from materials, converges through structural checks and responsibility confirmation, and ends at the formal baseline.

Step 1: Freeze scenarios and competency questions. First state what business judgments, queries, or actions the model must support. Without competency questions, LLMs expand concepts by text frequency and general experience, yielding a rich but unverifiable mega-ontology.

Step 2: Organize sources and authority levels. Manage policies, contracts, data dictionaries, interfaces, historical cases, and interview records separately; record version, validity, scope, and owner; distinguish authoritative rules, actual practices, historical records, and personal experience.

Step 3: Generate candidate packages, not formal models. Each candidate concept, relation, or constraint must carry source and version, candidate definition and rationale, reuse or conflict with existing models, uncertainties and counterexamples, affected competency questions, suggested confirmation roles, and handling status. Model confidence only prioritizes review; it cannot replace business approval.

Step 4: Execute deterministic structural checks. Use parsers, reasoners, SHACL, naming rules, and model diff tools to check syntax, logical consistency, duplicate elements, erroneous constraints, and baseline conflicts. Tool results and LLM-proposed fixes must be recorded separately.

Step 5: Responsible persons explicitly dispose. Candidate items must result in accept, accept-with-modification, reject, defer, or request-more-evidence — not just "read." Confirmation must come from people holding relevant business, data, rule, or risk accountability.

Step 6: Validate with competency questions and boundary examples. Beyond normal cases, cover conditions false, missing evidence, expired info, source conflicts, and unauthorized situations. If the model fabricates certain answers when evidence is insufficient, it cannot enter the production baseline.

Step 7: Versioned release with rollback evidence. Only confirmed and tested candidates enter the baseline. Release records bind competency questions, sources, review decisions, model diffs, test results, and impact scope. Runtime-feedback fixes must re-run the same governance chain; they cannot be auto-written into the formal ontology.

Engineering bottom line: three-zone isolation to prevent AI polluting the baseline

Implementation must distinguish at least three zones:

These zones can share a platform but state, permissions, and consumption interfaces must not mix. Otherwise "generation succeeded" easily equals "release succeeded" in engineering.

Who is accountable for auto-construction results

LLM / Modeling Agent: Responsible for material analysis, candidate extraction, formalization drafts, conflict flagging, test suggestions. Red line: No formal business definition or release approval authority.

Business Owner: Confirms scenarios, object boundaries, state meanings, expected business outcomes. Must decide: What business semantics the enterprise commits to in the current scenario.

Policy/Rule Owner: Confirms rule sources, validity, priority, exceptions. Must decide: Which rule is effective under what conditions.

Data/System Owner: Confirms object identity, authoritative data sources, mappings, timeliness. Must decide: Which data can prove current business facts.

Ontology Engineer: Chooses modeling patterns, controls consistency, reuse, maintainability. Must ensure: Confirmed business definitions are accurately translated into semantic models.

Security/Risk Owner: Confirms permissions, human review, action consequences, audit requirements. Must decide: Which judgments and actions can enter real business processes.

Human involvement must not degrade to a rubber-stamp "confirm" on LLM output. Responsible persons must see sources, counterexamples, impact scope, and test evidence to make meaningful judgments.

How auto-construction should be accepted

Evaluating an auto-construction capability cannot rely only on generation speed, triple count, or file parsability. At minimum check:

Source traceability: Can key candidates trace back to explicit materials, versions, and original locations?

Discovery coverage: Are objects, relations, states, rules, and exceptions required by competency questions obviously missing?

Semantic accuracy: Any erroneous merges, object/state confusion, treating unknown as negative?

Structural quality: Superfluous concepts, duplicate relations, unreasonable domain/range, unnecessary complexity?

Competency question coverage: Can the model support agreed queries, classification, reasoning, and evidence return?

Boundary behavior: Are missing, conflicting, expired, and unauthorized situations handled correctly?

Review cost: Does the LLM truly reduce material organization and formalization work, or shift cost to large-scale manual correction?

Result stability: Can same input, model, and config reproduce? Can changes undergo diff comparison and regression testing?

The following should directly block release: key definitions lack authoritative sources; core object identity or state ownership still disputed; high-risk rules/actions lack accountable owners; key competency questions or exceptional cases fail; model generation results untraceable or irreproducible.

Scenarios where auto-construction is not suitable

LLM-assisted modeling is not mandatory for every project.

Usually no need for complex auto-construction pipelines when:

Model scope is small, terminology stable, business experts and modelers can directly complete definitions;

Need is only retrieving answers from fixed documents, RAG already satisfies, no cross-system semantic reuse demand yet.

Scenarios that lack governance prerequisites for auto-construction:

No clear business owner, no authoritative source to confirm rules and object boundaries;

Team actually lacks real-time data, system interfaces, or process permissions — not concept discovery efficiency;

High-risk business tries to bypass change review, regression testing, and release responsibility via "auto-update ontology."

The first type yields limited benefit from LLMs; the second hides unresolved organizational and governance problems behind a prettier model diagram.

Summary

LLMs will become increasingly adept at candidate knowledge discovery, model draft generation, standard conversion, conflict checking, and test assistance. But enterprise ontology is not a material summary; it is the enterprise's reusable commitment to objects, relations, states, rules, evidence, and action boundaries.

Worth automating: material organization, candidate discovery, formalization, checking, regression. Not delegable to models: business definition authority, risk decision authority, result responsibility.

AI can move ontology engineering from "manual from-scratch writing" to "machine generates candidates, people confirm based on evidence," but must not substitute "human-AI collaborative modeling" with "model defines reality for the enterprise."

References

[1] W3C. OWL 2 Web Ontology Language Primer . https://www.w3.org/TR/owl-primer/

[2] Ontology Generation using Large Language Models . https://arxiv.org/abs/2503.05388

[3] Large Language Models Assisting Ontology Evaluation . https://arxiv.org/abs/2507.14552

[4] Towards Automated Ontology Generation from Unstructured Text . https://arxiv.org/abs/2604.23090