Ontology adoption checklist: data, identities, and business definitions
Prepare enterprise ontology adoption by reviewing business questions, sources, identities, relationships, definitions, permissions, and updates. Includes practical evaluation cases.
Begin an ontology adoption review with one business question, rather than collecting every record in the organization. Its objects, relationships, definitions, and source data need to be reviewed together before you can evaluate whether the connections are useful.
Questions can vary: which tasks and records relate to an asset, which orders need review when supply changes, or which team owns an activity and which guidance applies? Begin with the business goal. For changing states or processes, also review time and update requirements.
The following sections use one concrete example: a fictional equipment upgrade for Customer A. “Which project does this sensor-parts order belong to, and which contract terms apply?” The records include a contract, ERP account C-104, a project register, and orders. Adapt the same review items to other objects, including assets, products, teams, and processes.
1. Define the question and a verifiable result
Connecting all company data is difficult to scope or evaluate. Specify which order should lead to which project and applicable contract terms.
List the result fields you actually need: project ID, contract version, relevant clauses, order owner, and original source location. Identify the reviewer and acceptance criteria so a proof of concept does not depend on conflicting expectations.
2. List the data and responsible owners
| Item | What to prepare | Example |
|---|---|---|
| Sources | System, location, access method | ERP orders and maintenance contracts |
| Objects and properties | Types, states, and required information | Product, task, location, quantity, progress |
| Identifiers | Unique IDs and mapping criteria | Account C-104 and project ID |
| Relationship evidence | Record that establishes each link | Project ID on the order |
| Business definitions | Terms, statuses, dates, exceptions | Record that establishes acceptance |
| Owners | People who resolve meaning and errors | Purchasing and contract-management teams |
| Updates and time | Change frequency, event times, stored history | Status change time and record update time |
An initial consultation can begin with data types, structures, and the workflow you need. You do not need to send all sensitive records first. Agree on the sharing method and scope for the access environment.
3. Check identities instead of matching names alone
Determine whether a shared ID connects Customer A in the contract to ERP account C-104. If none exists, an approved mapping or review process may be needed. Specify how similar names, separate legal entities, branches, and subsidiaries are distinguished.
List exceptions such as orders without a project ID, projects under multiple contracts, and changed owners. An evaluation containing only clean examples can miss the difficulties that appear in operation.
4. Define effective dates for links and criteria
Contract amendments and owner changes can alter the applicable relationships. Record source versions, effective dates, and how current data is established.
Check whether order completion, receipt, and acceptance mean different things. Document differences before collapsing team-specific statuses into one label. An unverified status should remain distinguishable from a confirmed non-applicable one.
5. Review permissions and updates
Permission to view an order does not imply permission to view all its related contracts. Specify how source access applies to graph exploration and answers. Include changes caused by deletion and revoked access.
For internal-network requirements, review data access, processing configuration, model environment, and operating responsibilities together. Choosing a deployment location does not complete integration or permission design.
For operational records or measurements, review event and collection times, units, missing data, and retained history. For processes, define stage order, branches, completion criteria, and exceptions. If the goal includes a digital twin or simulation, scope data updates and analytical model validation separately.
6. Evaluate ordinary cases and exceptions separately
| Situation | Behavior to verify |
|---|---|
| Correct objects and relationships exist | Link the project and contract to original evidence |
| Another customer has a similar name | Avoid joining the wrong account |
| Project ID or contract is missing | Identify the missing evidence |
| Contract has been amended | Establish the version applicable to the question |
| User lacks contract access | Do not expose restricted contract information or relationships |
If document retrieval and answer generation are also involved, separate retrieval, answer, citation, and permission checks as described in the RAG PoC evaluation guide. Microsoft GraphRAG local search provides an example of using relationships during retrieval. Selecting a tool and agreeing on business definitions remain separate responsibilities.
What to include in an adoption inquiry
Describe the environment concretely: “We want to trace ERP orders to projects and contract terms. Account and project IDs exist, and purchasing can confirm the definitions.”
Other goals might be connecting assets to work and inspection history, or understanding supply, stock, and order relationships. Familiarity with ontology terminology is not required. Explain the expected result and available records so the model and adoption scope can be discussed.
A clear scope helps identify the first records and connections to review. Read the enterprise data ontology introduction and ontology, knowledge graphs, and RAG comparison, then explore an applicability review with Wissly Ontology Beta.