Knowledge Systems Design

Most enterprises operate with multiple, overlapping, partially-incompatible vocabularies for the same concepts. The same customer is recorded in different formats across systems; the same product is classified differently by sales and operations; the same risk is described in incompatible language by trading and compliance. An ontology is the explicit, agreed model of these concepts — what counts as an instance, what attributes are mandatory, how concepts relate — and it is the substrate on which downstream knowledge systems depend.

We design ontologies pragmatically rather than philosophically. The objective is not a perfect representation of the world but a useful representation of the part of the world the system operates on. We start from the queries the system needs to answer and the decisions it needs to support, and we model only the concepts and relationships those queries require, with explicit room for extension as new use cases arise.

Standards — schema.org, FIBO, SNOMED CT, GS1, industry-specific reference models — are reused where they fit, adapted where they almost fit, and ignored where they do not. The risk of starting from a bare canvas is greater than the risk of inheriting accumulated complexity, but the reverse is true at the long tail.

• Domain ontology and taxonomy design
• Reuse and adaptation of standards
• Semantic data integration
• Reference data management
• Versioning and evolution strategy
• Tooling for governance and review

A knowledge graph realises an ontology against actual data. Customers, products, suppliers, transactions, events and the relationships between them become a connected, queryable structure that downstream systems — search, recommendation, fraud detection, compliance, generative-AI grounding — can rely on. The value is not in the graph itself but in the products it makes possible.

We build knowledge graphs in the technologies appropriate to the workload — Neo4j, Amazon Neptune, JanusGraph, AnzoGraph, native RDF stores, or property-graph layers over relational warehouses where they suit better. We pay close attention to entity resolution, since a graph in which the same real-world entity appears as multiple nodes is worse than no graph at all, and we layer in continuous-integration practices so that the graph evolves predictably with the upstream data and ontology.

Where the use case warrants it, we extend the graph with embedding-based representations that support similarity search, recommendations and the kind of semantic retrieval that grounds large-language-model applications without requiring those models to remember everything. The combination of structured graph and learned embeddings is unusually powerful and increasingly mainstream.

“The graph itself is rarely the deliverable. The products it makes possible are.”

Where decisions are governed by complex policies — eligibility, pricing, risk classification, regulatory compliance, clinical pathways — pure statistical models are the wrong tool. Policy logic is best expressed as policy logic: as readable rules, structured decision tables, and inference engines that can derive consequences from facts and a body of rules. The result is a system whose behaviour is fully traceable and which can be updated by domain experts without retraining a model.

We use modern decision-management platforms (Camunda DMN, Drools, Decision Model and Notation tooling) where they fit the use case, and bespoke rule engines where they do not. We pay particular attention to the editorial process: who can change a rule, with what review, with what testing against historical cases, and with what staged rollout. Without that process, rule bases decay quickly into illegible accretions.

Hybrid architectures combine the best of both worlds. A neural model handles perception or pattern-recognition where rules cannot be written; a rule engine handles policy compliance and final decision-making where rules can be. The neural component supplies inputs to the rule engine — extracted entities from a document, a calibrated probability, a classification — and the rule engine reaches a decision that can be defended against any audit. We design these architectures explicitly, with a clear separation between learning and reasoning components and explicit interfaces between them.

Explainability is not a feature you add to a model after the fact. It is a property of the architecture as a whole. Knowledge-based systems are explainable by construction: every decision is the product of facts and rules that can be inspected, and the explanation is a direct trace of the inference chain rather than a post-hoc reconstruction.

Where machine-learned components are part of the system, we pair them with explanation tooling appropriate to the model class — feature attribution for tabular models, attention and rationale extraction for sequence models, prototype-based explanation for image models — and we surface those explanations alongside the system's output, in language a domain expert can act on. The objective is not to make the model interpretable in the abstract; it is to give the human reviewer the evidence they need to override or accept the system's recommendation.

We work closely with risk and compliance functions to define the standards explanations must meet, and we test those standards against actual cases as part of acceptance. An explanation that satisfies a data scientist but confuses a case-handler does not pass.

Knowledge systems require ongoing care. Ontologies evolve as the business changes; graphs need entity-resolution maintenance as new sources are connected; rule bases need pruning, deduplication and review against actual outcomes. We design the operating model alongside the technology: the editorial roles, the review cadence, the change-control process, the performance-monitoring dashboards. The result is a system whose half-life is measured in years, not months.

Many of our deployments are paired with light-touch managed services that handle this ongoing care, particularly in the early years before the client's internal teams have absorbed the practices. We are equally happy when clients take operational ownership immediately; the design accommodates either.