ZharfAI Team
Enterprise questions often depend less on a paragraph than on a path. Which customer products depend on the service that failed? Who currently owns those products? Which contract and policy apply in the customer’s jurisdiction? Was that ownership true when the incident occurred?
Vector retrieval is useful for finding semantically similar passages, but similarity does not establish identity, direction, cardinality, validity time, or authorization. A knowledge graph can represent those relationships explicitly. A language model can then translate a question, help extract candidates, or explain a result—but the graph query, provenance, and policy boundary should remain inspectable.
The durable design is not “LLM plus graph database.” It is an evidence-bearing semantic layer with stable identifiers, governed relations, temporal facts, validation, and measured query behavior.
A property graph may store nodes and labeled edges; an RDF graph represents statements as subject-predicate-object triples. Either can work. The important decisions are semantic, not brand-specific:
For interoperable RDF systems, RDF 1.1 Concepts remains the W3C Recommendation. As of 30 July 2026, RDF 1.2 Concepts is a Candidate Recommendation Snapshot, not a final Recommendation. Teams can test RDF 1.2 features, but contracts should declare the version they actually support.
SPARQL 1.1 Query provides a standardized query language for RDF graphs. SHACL provides a W3C Recommendation for validating RDF graphs against shapes, while PROV-O provides terms for representing provenance involving entities, activities, and agents. These standards do not design an enterprise ontology for you; they provide useful common machinery.
Before building clever paths, decide whether two records describe the same thing.
“ACME Ltd,” customer C-1042, tax identity GB…, and a CRM account may refer to one legal entity—or to a parent, subsidiary, duplicate, or outdated account. An incident record may call a service “Auth,” while the service catalog uses svc-identity-prod-eu. A model can suggest a match, but a false merge contaminates every downstream path.
Use source-scoped identifiers and an explicit resolution process:
sameAs, possibleMatch, supersedes, and partOf as distinct relations;Measure entity precision and recall on labeled pairs, but also measure damage: false-merge rate, unresolved duplicate rate, split rate, and number of downstream records affected by a correction. Never treat a generated canonical name as proof of legal identity.
Large “enterprise ontology” projects often stall because they try to model the whole company before answering one useful question. Start with a competency question and the minimum path needed to answer it.
For incident impact, the first schema might contain:
Service --DEPENDS_ON--> Service
Product --SERVED_BY--> Service
Customer --SUBSCRIBES_TO--> Product
Incident --AFFECTS--> Service
Team --OWNS--> Service
Person --MEMBER_OF--> Team
Contract --COVERS--> Customer
Policy --APPLIES_TO--> Product
Each edge should specify direction, allowed source and target types, cardinality expectations, validity interval, provenance, confidence or assertion status, and sensitivity. Do not use one vague relation such as relatedTo when dependsOn, owns, and coveredBy imply different traversal and risk.
Keep the graph close to the operational source. A CMDB remains responsible for service inventory; HR remains responsible for employment status; contract management remains responsible for executed terms. The graph carries referenced claims and source versions, not an ungoverned copy that quietly becomes “truth.”
This is where graph design complements RAG knowledge quality. Documents provide detail and evidence; the graph provides identity, relation, and traversal. Neither repairs stale or unauthorized sources automatically.
“Who owns Service A?” is incomplete without an as-of time. The current team may differ from the owner during a January incident. Contract coverage, policy versions, product dependencies, and organizational roles all change.
Represent at least two clocks:
An edge can therefore state that Team Blue owned Service A from 1 January to 15 March, the source record was imported on 3 January, and a correction was recorded on 20 March. An as-of query can reproduce what the system knew then or what is now believed to have been true then.
Provenance should identify the source artifact and version, extraction or transformation activity, responsible agent, ingestion time, and any rule that derived the claim. If an LLM extracts a relation from a document, store it as a proposed assertion linked to the source span, model digest, prompt or extraction version, confidence, and review outcome. Do not silently promote it to a verified fact.
Derived relations need the same discipline. If a rule infers that Product P is at risk because it transitively depends on failed Service S, return the traversed edges and rule version. The explanation is a proof path, not a model-written rationale.
A safe question-answering flow can be divided into explicit stages:
Allowing a language model to emit arbitrary SPARQL or Cypher against production is unsafe. It may create expensive traversals, bypass intended filters, misunderstand schema, or expose restricted relations. Use a read-only endpoint, query allowlists or templates, complexity limits, result caps, timeouts, and a semantic policy layer. Parse and inspect generated queries before execution.
For repeated workflows, prefer typed functions such as:
get_impacted_products(service_id, as_of, tenant_id)
get_current_owner(asset_id, as_of)
get_applicable_policy(product_id, customer_id, jurisdiction, as_of)
The model can map a user question to a function and explain its typed result. The critical traversal stays testable.
At 09:12, the identity service in the EU region begins returning elevated errors. An incident commander asks: “Which premium customers are affected, who owns the customer-facing products, and which notification commitments apply?”
The system resolves the incident to svc-identity-eu, then traverses authorized, temporally valid edges:
incident -> affects -> service
service <- depends_on* <- service <- served_by <- product
product <- subscribes_to <- customer
customer <- covers <- contract -> contains -> notification_clause
product <- owns <- team
The answer should not merely list names. It should return, for each affected customer:
Suppose a product-service dependency is inferred from traffic observations but has never been steward-approved. The system can include it in a clearly labeled “possible impact” list and request verification. It should not present the customer as certainly affected.
This example also shows why an enterprise memory system needs temporal and correction semantics. Yesterday’s answer must remain reproducible after today’s ownership update.
Schema validation catches structural errors before they reach a model. SHACL shapes can require, for example, that every active service has at least one owner, every ownership edge has a start date, and every inferred high-impact relation has provenance. Validation does not establish real-world truth; a perfectly shaped false statement is still false.
Maintain separate quality layers:
| Layer | Measures |
|---|---|
| Entity resolution | pair precision/recall, false merges, unresolved duplicates |
| Relation extraction | precision, recall, F1 by relation and source type |
| Graph integrity | SHACL violations, orphan nodes, illegal cardinality, cycle rules |
| Freshness | stale-edge rate, source-to-graph lag, missing owner rate |
| Provenance | source coverage, source-open success, derivation coverage |
| Query behavior | exact answer accuracy, path validity, temporal correctness, authorization denials |
| Generated response | claim support, citation correctness, abstention, omission of conflicting evidence |
| Workflow value | investigation time, steward correction burden, false escalations, missed impacts |
Create gold questions with expected entity IDs, paths, time conditions, and allowed outputs—not only expected prose. Test negative cases: no path, multiple identities, revoked access, contradictory sources, loops, stale dependencies, and a prompt-injection string stored as a node property.
The survey Knowledge Graphs by Hogan and colleagues provides a broad technical review of graph representation, creation, enrichment, quality, and publication. For graph-assisted summarization over large text corpora, Microsoft’s GraphRAG paper is one research approach; its reported results do not establish that graph retrieval is superior for every enterprise question or dataset.
RDF commonly uses an open-world assumption: absence of a statement does not imply the statement is false. Enterprise workflows often need closed-world checks: if the release record has no approved security sign-off, block the release.
Do not let the model choose this interpretation implicitly. Define it per predicate and workflow:
Similarly, distinguish uniqueness from preference. Two active addresses may be valid; one may be the preferred billing address. Cardinality constraints should reflect the business semantics and validity interval.
A graph can reveal sensitive facts through relationships even when each node looks harmless. A path among an employee, clinic, benefits program, and leave record may expose health information. Centrality or neighborhood queries can reveal strategic suppliers, privileged administrators, or vulnerable infrastructure.
Apply:
Embedding a restricted node into an unrestricted vector index can bypass graph controls. Every retrieval surface must preserve the same policy labels.
Phase 1 — question and ownership. Select one competency question, identify authoritative sources and stewards, define entity IDs and temporal semantics, and agree on correction service levels.
Phase 2 — offline graph. Ingest a bounded dataset, validate shapes, label extraction candidates, and answer gold queries without a language model. Fix identity and freshness failures first.
Phase 3 — evidence-linked assistant. Let a model resolve terms and narrate typed query results. Show paths and sources. Keep read-only execution and log every generated claim.
Phase 4 — operational integration. Add alerts or case creation only after precision, authorization, freshness, and rollback gates pass. Require human confirmation for consequential actions.
Release only when critical relations meet their precision threshold, provenance coverage passes, stale-data budgets are met, no unauthorized path is returned in adversarial tests, and the previous graph snapshot and query layer can be restored. Pause the service when authoritative feeds fail or validation violations exceed the error budget.
No. It gives the system structured facts and paths that can be queried and inspected. The model can still choose the wrong entity, query, or explanation. Evaluate each stage.
Usually not. Use vector or lexical retrieval for relevant passages and a graph for identity, relationships, constraints, and traversal. Combine them only with shared provenance and authorization.
No. RDF, property graphs, relational tables, and typed services can all represent relationships. Choose based on interoperability, query, governance, and operating requirements. Preserve explicit semantics either way.
It can propose entities and relations. High-impact facts need source spans, calibrated thresholds, validation, and often steward review. Extraction confidence is not truth.
For a new graph, relation precision and entity false-merge rate are often more urgent than graph size. A small, accurate, fresh subgraph is more useful than millions of ambiguous edges.
A reasoning graph earns trust when it can answer not only “what is connected?” but “according to which source, under which definition, at what time, and for which authorized user?” That is the difference between decorative graph context and an enterprise decision system.
Sources reviewed and current as of July 30, 2026:
An evidence-first checklist for selecting an AI company in Iran: define the workflow, test Persian performance, examine security, measure a pilot, and negotiate an exit.
Read More
The next generation of enterprise AI should not merely produce an answer. It should show the evidence, uncertainty, authority, and action path behind it.
Read More
When an answer can be independently checked, AI training can reward completed work rather than persuasive language—but the verifier becomes part of the product.
Read MoreSee the daily briefing and the operational guides. This page is an archive note, not an invitation to start a project.