A graph can make meaning explicit. A system must still establish what is true now, what matters here, and what it is allowed to do.
At 09:10, a maintenance system has a well-formed graph. Pump P-17 is connected to power circuit C-4. Procedure M-12 applies to Pump P-17. The relationships are typed, the entities are identified, and the procedure has a source.
A dispatcher enters a request to return the pump to service.
The graph can help identify the relevant equipment and procedure. By itself, it does not establish whether the isolation lock is currently cleared, whether the inspection record is complete, whether the record is fresh, or whether this dispatcher has authority to release the equipment. Those are not missing edges to be guessed. They are operational questions that require current evidence, policy and an authorized decision path.
That gap is the subject of this article. A knowledge graph is an important structure for intelligence, but the structure alone does not complete the work of an intelligent system.
What the graph gives us
Knowledge graphs make relationships first-class. They connect entities through explicit, named relations, allowing systems to integrate information and traverse meaningful paths instead of treating every fact as an isolated text fragment. Researchers have used different definitions of “knowledge graph”; a widely cited survey describes one as graph-structured data intended to accumulate and convey knowledge about the world.[1]
RDF gives one formal version of this idea: an RDF graph is a set of subject–predicate–object triples.[2] A triple states a relation, such as Pump P-17 is served by Circuit C-4. An ontology can define what those terms and relations mean. A reasoner can then derive conclusions that follow from the declared axioms. OWL 2 is explicitly declarative: its formal semantics determine what follows from the modeled statements, while a reasoner computes those consequences.[3]
This is substantial capability. A well-designed graph can resolve identity, represent provenance, connect policy to an object, encode time, capture workflow state, and support deductive or inductive analysis. The title does not suggest that graphs are passive or incapable of reasoning.
It points to a different boundary: representing a fact is not the same as establishing that the fact is current, relevant, permitted, and actionable in this run.
The missing fact may be the important one
Suppose the graph contains no assertion that an active isolation lock remains on Pump P-17. Under OWL’s open-world assumption, the missing assertion does not prove that the lock is cleared; the information may simply be incomplete.[3] An operational system therefore needs an explicit way to determine whether the relevant source is complete and current, or whether it must consult another system before deciding.
This is a state problem. “Inspection completed” is not just a relation if the decision depends on who recorded it, when it was recorded, which procedure version applied, and whether the inspection remains valid. A graph can represent all of those dimensions. The runtime must still retrieve the correct version and account for updates, conflicts, delays, and missing data.
It is also a context problem. A knowledge graph may contain a large universe of connected facts. An intelligent system must select the subset relevant to this request, the current operational state, the applicable rule, and the requester’s authorized scope. Giving a model more graph content does not automatically give it the right context. Context selection determines what the model is asked to reason over and what it must leave out.
Inference adds another layer. A reasoner may derive that a particular procedure applies because the pump belongs to a class of equipment covered by the procedure. A model may interpret an ambiguous inspection note. Those results answer different kinds of questions and carry different guarantees. The system should preserve the premises, source, inference method, uncertainty, and version behind each conclusion.
Validation does not grant authority
Rules and validation make meaning operationally useful, but they do not all do the same job.
SHACL, for example, defines a language for validating RDF graphs against conditions. A validation report can show that a graph conforms to a declared shape or identify violations.[4] That is valuable for data quality and structural checks. A conforming graph still does not, on its own, authorize a person to release a pump or execute a restart operation.
The distinction matters in implementation. A policy can be represented as data. It can also be evaluated by a rule engine or deterministic service. But the system still needs to establish which policy version governs, which state it applies to, and whether all required preconditions have passed. A rule that exists in a graph but is not invoked at the action boundary is documentation, not enforcement.
Identity has the same boundary. A graph may state that a person holds the role of maintenance lead. That relationship does not authenticate the current requester or prove that the requester’s permissions remain valid. Runtime identity and authorization services must establish who is acting and what that identity may do.
Tools connect reasoning to systems that can change state. A read operation may retrieve the latest inspection record. A write operation may release equipment, update a work order, or notify another team. Each action needs an explicit permission scope, validated inputs, and a defined outcome if the operation fails or the underlying state changes between decision and execution.
Controlled execution closes the loop. Before a consequential action, the system checks current preconditions and authority; it executes through a governed interface; then it records the result and makes the outcome observable. Where the risk warrants it, a human can review, pause, approve, or take over. NIST’s AI Risk Management Framework treats human–AI arrangements as context-dependent and calls for clear roles and responsibilities in operational settings.[5]
The system property
A knowledge graph can be the semantic backbone of an intelligent system. It can make entities, relationships, rules and provenance explicit. It can support retrieval, inference and validation. Those are not cosmetic contributions: they make reasoning more structured and inspectable.
Operational intelligence appears when those capabilities work with the rest of the system: current state, task-specific context, suitable inference, executable rules, verified identity, permissioned tools, controlled transitions and observable outcomes.
CARM’INK’s position is that Semantic Intelligence begins with meaning and continues through its governed use. The graph gives the system a structured account of what is known and how concepts relate. The surrounding architecture determines which parts apply now, what follows from them, who may act, and how the action is controlled.
A graph can tell a system what is connected. Intelligence must also establish what the connection means in this context, whether its evidence is current, which conclusions are justified, and what the system is authorized to do with them.
References
- Aidan Hogan et al., “Knowledge Graphs”, ACM Computing Surveys, vol. 54, no. 4, Article 71, 2021.
- W3C, “RDF 1.1 Concepts and Abstract Syntax”, W3C Recommendation, 25 February 2014.
- W3C, “OWL 2 Web Ontology Language Primer,” Second Edition, W3C Recommendation, 11 December 2012.
- W3C, “Shapes Constraint Language (SHACL)”, W3C Recommendation, 2017.
- National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework (AI RMF 1.0)”, NIST AI 100-1, 2023, Appendix C.