Why ontology governance is essential
Companies today produce considerable volumes of data. ERPs, CRMs, PLMs, HRIS, document repositories, Excel files, and business applications feed operational processes every day. Yet despite this wealth of information, one reality persists: data remains siloed, described with different terminologies, and hard to use coherently.
This is exactly the problem the Graphicient application addresses. Through the GraphForge feature, it lets you build an ontology and connect it to previously separate data (ERP, CRM, Excel files, business applications) within a single Neo4j knowledge graph.
An ontology is a knowledge model of a domain. It structures business concepts, their properties, and the relationships linking them, providing a shared frame of understanding for everyone in the domain. This knowledge becomes actionable through three other features: Explore, to visualize data and hidden links across complex ecosystems; KPI Forge, to build custom indicators; and AI Chatbot, a conversational agent able to reason over the data to produce reliable, contextualized answers.
On day one, the ontology is built with care: every node is named, every relationship documented, every piece of data in its right place. Then time passes. One user adds an attribute without documenting it, another adds concepts from a different business domain, a third connects a new data source without asking who will be able to access it. Six months later, the ontology looks like any other poorly maintained database: diverging definitions, blind spots on confidentiality, an AI agent starting to reason over incomplete or contradictory knowledge.
An ontology is never a deliverable you install once: it's a living asset that grows at the pace of decisions made by the teams using it. At Graphicient, these risks aren't handled after the fact, but prevented upfront, through ontology governance that sets the rules, responsibilities, and validation processes needed throughout its lifecycle. This governance is built around two major strands: analyzing what exists, and planning future governance.
Step 1: analyzing what exists, a diagnosis before any action
At Graphicient, an ontology is never built in a vacuum: it's created to answer use cases, specific business questions. A well-built ontology should serve several use cases at once; conversely, a single use case never justifies creating a new ontology on its own. Before any modeling, each organization goes through a diagnosis structured around four strands:
- The project's stakes and objectives, which shape everything else: reconciling conflicting data, speeding up decisions with a single source of truth, mapping business knowledge.
- Defining the use cases: the business domain involved, a description of the need, its status, the ontology it belongs to, and its end users, to avoid duplicates from the start.
- An inventory of the data sources feeding each ontology: type, location, estimated volume, nature of the data, and how it flows in and out.
- A diagnosis of existing governance, across four dimensions: data quality, lifecycle, access control, and regulatory compliance, along with responsibilities already in place.
This diagnostic phase isn't a formality: it's what identifies, from the start, which constraints will shape future governance.
Step 2: planning future governance
Once the existing landscape is mapped, Graphicient's support turns to organizing what will last, around four inseparable strands: the quality of the ontology and the AI agent, to ensure the model stays coherent as it evolves; data confidentiality, so reconciling sources never results in uncontrolled exposure; ontology evolution, to govern changes to the model, data, and use cases over time; and the distribution of responsibilities, which specifies who owns each of these decisions.
Ensuring the ontology's quality over time
At Graphicient, a simple principle guides modeling: an ontology's quality is built at creation and maintained throughout its lifecycle. The GraphForge module lets you build the data model representing a business domain: nodes, such as EMPLOYEE and POSITION, linked by relationships, for example HOLDS, each able to carry attributes, such as a start date. "Julie Martin" then becomes a concrete instance of the EMPLOYEE node.
The approach is iterative and incremental, in six steps: scope or reuse an existing ontology, identify, link, document, instantiate, validate. It encourages progressively building a simple domain core, extended as needs grow. Several cross-cutting rules ensure the ontology stays readable by the AI agent and by all business users, a shared language essential for an ontology to serve several teams unambiguously:
- Unique naming rules for every node, relationship, and attribute, written in English with strict conventions, so the AI agent can navigate and understand the graph natively.
- Precise construction rules to decide between creating a new node and adding a simple attribute, plus semantic information (definition, synonyms, business rules) so no concept is duplicated or ambiguous.
- Modeling errors to avoid, the ones that stop the AI agent from reasoning correctly over the graph.
- A framework for using industry standards (like Schema.org), used to reconcile or compare several ontologies with each other.
- A validation checklist with three parts: conventions and structure, enrichment for the AI agent, validation and governance.
Mastering confidentiality, the price of reconciling data
Reconciling previously separate data is a tremendous source of value, but it comes at a cost: the loss of the natural confidentiality that fragmentation provided. Once connected in a single graph, confidential data can become visible to a much wider audience than before. Governing an ontology therefore also means governing its confidentiality.
At Graphicient, confidentiality is never set at the data level, but at the ontology level: GraphForge lets you specify a level for every node type, relationship, and attribute. In an HR ontology, the EMPLOYEE node can stay public (name and position visible to everyone) while the associated salary attribute can be classified secret. Four levels exist, each inheriting the ones below it: public access, intermediate access, secret access, top secret access.
Classification is configured only once and automatically applies to all current and future instances of that type. The day an administrator classifies the salary attribute as secret access, the rule immediately applies to every employee in the system, both those already present and those hired afterward. There's no gray area: once a type is classified, all of its instances, past and future, are subject to the same rule.
This is resolved at the level of the context, a workspace grouping a project, an ontology, and its users. A single user can therefore have broad access on a project they own, and restricted access on another where they only provide support. Three roles structure each context: the Owner, who created the context, sets their own confidentiality level without limit, and can add or change the other roles; the Administrator, appointed by the owner, who adds users and configures accessible levels, but can never change their own role or that of the owner or other administrators; and the User, who consults data but can never set confidentiality levels or change anyone else's role, positioned by default at the lowest access level.
Putting this confidentiality in place relies on explicit governance: appointing at least one context administrator as soon as the ontology is created, scheduling a periodic review of access rights, requiring explicit validation of the confidentiality level for every new node, relationship, or attribute before it goes live, and regularly auditing the ontology to catch any type that slipped through this classification.
Evolving the ontology without ever losing control
An ontology is never set in stone. Business needs evolve, new data sources appear, use cases show their limits. At Graphicient, this evolution is organized around three clearly identified triggers.
Improving an existing use case. Before any change (adding, removing, or renaming nodes, relationships, or properties), the central question is: which other use cases and users would be affected? An impact analysis is carried out by the context's owner and administrator. If no other use case is involved, the update is made directly; if several are involved, a governance committee is convened. In every case, any newly created element must be assigned a confidentiality level before going live.
Creating a new use case. The decision to attach this need to an existing ontology or create a new one is made through three successive questions: does an ontology already cover this need? If so, are its confidentiality constraints compatible? If they are, is the proportion of concepts already present sufficient (above 50% coverage, the existing ontology is extended; below that, a new ontology is created)?
Enriching the ontology with new data. The starting point here isn't a functional problem but a data opportunity: a new source arriving, the recurring update of an already connected source, or a data quality upgrade campaign, jointly led by the context owner and the data governance lead.
A clear distribution of responsibilities
None of the above would work without an explicit distribution of roles and, for each ontology, the named identification of the people holding them. At Graphicient, seven complementary functions are systematically documented with the name of the person appointed to each:
- The Context Owner, a business stakeholder on the client side, carries strategic and functional responsibility: they create the ontology, know the sources, coordinate use cases, and approve changes.
- The Context Administrator carries day-to-day operational responsibility: they add users and classify every node, relationship, and attribute type.
- The data source's technical lead, on the client side, guarantees hosting, technical security, and the execution quality of data flows.
- The Graphicient application's technical lead, on Graphicient's side, ensures context availability and implements requested technical changes.
- The data security lead, cross-functional within the client organization, defines access control rules and approves any change that could impact confidentiality.
- The data governance lead, cross-functional on the client side, coordinates the whole setup and runs governance committees.
- The Governance Committee steps in when a change request impacts several use cases or several context owners, and arbitrates changes by consensus.
Governance as an investment, not a constraint
Setting up ontology governance at Graphicient isn't adding bureaucracy to a data project. It's an upfront investment that avoids far heavier costs down the line: a duplicated ontology that has to be reconciled after the fact, an AI agent whose trust has to be rebuilt after months of wrong answers. This initial discipline is what makes possible, over time, fluid exploration with Explore, reliable indicators with KPI Forge, and an AI agent able to answer in natural language with AI Chatbot, all built on structured, secure knowledge.
An ontology without governance is just one more schema among many, doomed to degrade as soon as several hands edit it without shared rules. A governed ontology, on the other hand, stays a reliable asset over time: identified owners at every step, confidentiality levels kept up to date, changes arbitrated rather than endured. It's this discipline, more than the technology itself, that makes an ontology the shared language of an entire company, understood as well by business teams as by artificial intelligence.