Knowledge Graphs

Not primarily. The hard work is agreement rather than software: deciding what the organisation means by customer, contract, supplier, or incident when different functions currently use different definitions. The graph database comes later. What is being built is an explicit, governed account of what the organisation knows, how it defines it, where each assertion came from, and the contexts in which it holds. The technology stores and exposes that account; it does not settle the definitions.

Quality gives the organisation reliable records. Semantic structure makes the meaning and relationships among those records explicit across contexts. Both may be needed where a system must reason across customers, contracts, products, suppliers, and policies rather than retrieve one item at a time. Accurate records with implicit relationships can be difficult to use consistently at scale, while rich relationships built on unreliable records merely make the error easier to traverse. The quality investment is the foundation; structural work extends what can be done with it.

Because the definitions are choices with consequences. The definition of customer can shape retention reporting, regulatory scope, and whom an AI system includes or excludes. Once encoded and reused across systems, those definitions influence decisions at scale. Connecting data can also create sensitivity that existed in no single source, so permissions must govern relationships and derived inferences as well as individual records. The Board does not author the definitions, but the few that materially affect revenue, risk, regulatory exposure, or customer trust warrant its visibility.

Not by itself. A knowledge graph can provide provenance for the information and relationships used in an answer, giving an auditor or Risk Committee an evidence path it can inspect. It does not expose the internal reasoning of a model, prove that the model used the information appropriately, or replace contemporaneous decision logs and human review. Where decisions depend on relationships spread across several systems, the graph can be an important part of explainability. It is one layer of the evidence, not the whole answer.

Start with a question the Board asks repeatedly and receives only a partial or slow answer to: exposure to a jurisdiction, supplier dependence on a commodity, or concentration risk across contracts. These are relationship questions, and the relevant connections are often fragmented across tables, documents, systems, and people. Model one bounded domain, such as suppliers, jurisdictions, commodities, and contracts, then test whether the resulting graph makes repeated analysis faster, more consistent, and more traceable. The aim is to prove the value of the structural work, not to begin with an enterprise-wide graph.

The latent graph exists either way, in your systems’ foreign keys and your people’s heads. Left ungoverned, it forms by default: definitions set implicitly by whichever system shipped first, relationships encoded by accident, and AI systems reasoning over structure nobody chose. Meanwhile the advantage compounds elsewhere, because structural work is slow, proprietary, and cannot be bought in. A well-governed semantic layer built from proprietary operating knowledge is one of the few durable advantages available while the models themselves commoditise.