Enterprise Architecture for Knowledge Graph and Ontology Management

In the previous article, I explained that enterprises require more than just a graph database or ontology editor. They need a management layer that supports change, validation, collaboration, approvals, releases, and integration with the broader enterprise environment.

The next logical question is: what should this architecture look like?

This article outlines the architecture of SolidState Graph. Instead of detailing individual features, it focuses on platform structure, domain boundaries, and the process of moving knowledge from draft to governed production graph.

SolidState Graph as the Control Plane

An enterprise graph environment involves multiple stakeholders.

Ontology engineers define concepts and relationships. Data stewards integrate source data. Domain experts review semantics. Applications, AI systems, and RAG pipelines consume the resulting knowledge.

SolidState Graph serves as an intermediary between these users and the underlying graph ecosystem.

The platform does not replace Neo4j, RDF stores, SPARQL endpoints, files, or enterprise source systems. Those technologies continue to store, expose, and serve the graph.

SolidState Graph provides an operating layer around these systems. It enables teams to manage graph and ontology assets consistently, without requiring users to understand the specifics of each database, format, or deployment environment.

A Layered Architecture

The platform is structured as a set of distinct architectural layers, rather than as a single monolithic graph application.

The experience layer provides access through the web interface and APIs. The workspace layer manages teams, sessions, visibility, and collaboration context.

The knowledge management layer manages ontologies, graph assets, mappings, metadata, and provenance. The lifecycle layer oversees versions, branches, reviews, approvals, and releases.

Validation and AI assistance function above the integration layer, while databases and repositories remain external to the core platform.

The key consideration is not the number of layers, but the clear separation between them.

The user interface should not write directly to the graph database. AI services should not publish directly to production. Database-specific behaviour should not influence the core knowledge model.

Internal Domain Boundaries

The same principle applies inside the platform.

SolidState Graph is best understood as a collection of related domains, rather than as a single ontology or graph service.

The workspace domain defines where teams manage assets. The ontology domain manages concepts, classes, properties, relationships, constraints, and semantic definitions.

The graph domain manages entities, relationships, and graph instances. The mapping domain links source data to the ontology and graph structure.

These domains are closely related, but should remain distinct models.

An ontology defines meaning and structure, while a knowledge graph contains the corresponding facts, entities, and relationships. They influence each other, but may evolve at different rates and require separate review processes.

Validation, lifecycle, release, provenance, identity, and adapter domains provide the control around these core assets.

This separation ensures the platform is more than an ontology editor with added database access.

A Governed Change Lifecycle

Knowledge graphs are never truly finished.

Definitions change, relationships are corrected, source systems evolve, and new evidence emerges. A platform managing enterprise knowledge must therefore treat change as a primary concern.

Changes start in a draft workspace or branch, allowing teams to modify ontologies, graph data, mappings, or metadata without impacting the released graph.

These changes then undergo validation and review. Once approved, the platform creates an immutable release snapshot and publishes it through the appropriate adapter.

This creates a clear distinction between three states:

• work in progress

• approved release

• published graph

Audit and provenance are maintained throughout the process. The platform should always be able to identify what changed, who made the change, which checks were performed, who approved it, and where it was published.

This distinction separates simple graph editing from managing a graph as an enterprise asset.

Separate Read and Write Paths

Reading from a graph and modifying a graph are fundamentally different operations.

Applications require fast, reliable access to released knowledge. Authoring and publication require controls, validation, approvals, and traceability.

The read path is straightforward: a query passes through the API and adapter to the graph store.

The write path is intentionally more controlled. Authors work within a workspace, changes are validated and approved, and only approved releases reach the publish adapter.

This separation safeguards the production state without hindering graph consumption.

It also enables proper permission management. Applications may have read access to the graph, while publication is restricted to a controlled service identity.

Adapter-Based Integration

SolidState Graph should remain independent of any single graph database.

Neo4j may be the initial adapter, but the core platform should not depend on Cypher or any single vendor’s capabilities.

The adapter layer translates internal platform operations into the queries, APIs, and publication mechanisms supported by each target system.

The adapter layer must also recognise system capabilities. One database may support transactions and incremental updates, while another may provide only a SPARQL endpoint or file-based import.

The platform should accommodate these differences, rather than assuming all graph systems operate identically.

This approach allows SolidState Graph to maintain consistency at the management layer while leveraging the strengths of each underlying platform.

Deployment Architecture

Logical boundaries do not require every component to be a separate microservice in the initial release.

A modular monolith is a practical starting point, provided that boundaries between workspace, ontology, graph, validation, governance, release, AI, and adapters remain clear.

Clients access the platform through an API gateway. Core services manage the various domains, while a platform metadata database stores workspaces, versions, policies, releases, reviews, and audit history.

This metadata database is separate from the external graph database.

The graph database stores and serves the released knowledge graph, while the platform database maintains the information required to manage the graph throughout its lifecycle.

An event bus supports asynchronous workflows and enterprise integrations. Events such as validation completion, review requests, release approvals, or publication failures can be consumed by other services and pipelines.

The adapter service establishes a controlled boundary between SolidState Graph and external graph stores, repositories, identity providers, and enterprise systems.

Where AI Fits

AI should be integrated within this architecture, but must not bypass established processes.

OpenIE, LLM-based extraction, and KGGen-style approaches can identify candidate concepts, entities, relationships, and mappings from unstructured text.

These outputs should enter the same draft workspace as human-authored changes, retaining source evidence, confidence levels, and extraction metadata.

From there, they move through validation, review, approval, and release like any other change.

AI can accelerate graph and ontology creation, but should not circumvent provenance, validation, or accountability.

From Graph Tools to a Managed Platform

The value of this architecture lies in the boundaries it establishes.

Graph databases manage storage and query execution. Ontology services manage semantic models. Workspaces manage draft state. Validation services manage quality checks. Lifecycle services manage change. Release services manage approved versions. Adapters manage database-specific behavior.

SolidState Graph unifies these responsibilities as a management control plane for enterprise knowledge graphs.

In the next article, I will step back from the platform architecture and examine what a knowledge graph actually contains. A stored triple may represent a fact, but enterprise knowledge is rarely that simple. We need to distinguish between facts, claims, business concepts, context, evidence, and trust before we can decide what belongs in a graph and how it should be governed. The next article, “A Knowledge Graph Is More Than Triples: Facts, Claims, Concepts, and Context,” will explore these distinctions and explain why they matter when building knowledge graphs that enterprises can rely on.