Enterprise Knowledge Graph: Entities and Provenance

An enterprise knowledge graph is a governed model of the important entities in a company, the relationships between them, and the evidence that supports those relationships. It connects people, teams, customers, products, projects, services, documents, tickets, decisions, and systems so search and AI can retrieve organizational meaning—not only similar text.

The word “graph” can create the wrong expectation. A graph database stores nodes, relationships, and properties. A knowledge graph adds domain meaning: identity rules, entity types, relationship semantics, constraints, and source evidence. An enterprise knowledge graph adds another requirement: every result must respect changing identities, source permissions, ownership, provenance, lifecycle, and policy across many applications.

The useful question is therefore not “Do we have a graph database?” It is “Can we explain which real-world thing this node represents, why this edge exists, who may see it, when it was valid, which source supports it, and what happens when the source changes or disagrees?”

The short answer

A production enterprise knowledge graph needs six contracts:

1. Identity: stable enterprise IDs plus mappings to every source-native ID.

2. Semantics: explicit entity classes, relationship types, direction, cardinality, and domain rules.

3. Evidence: source links, versions, extraction method, confidence, and transformation lineage.

4. Authorization: node, edge, property, aggregate, traversal, and output policies tied to current identity.

5. Time and lifecycle: valid-from, valid-to, created, observed, superseded, disputed, archived, and deleted states.

6. Operations: ingestion, validation, conflict handling, ownership, review, observability, rollback, and repair.

Start with a bounded business question—such as product impact, account context, service ownership, policy applicability, or expertise discovery. Model only the entities and relationships required to answer it safely. Expand after you can measure entity accuracy, relationship precision, permission enforcement, provenance coverage, retrieval quality, and business outcome.

Graph database vs knowledge graph vs enterprise knowledge graph

A graph database can store a knowledge graph, but it does not create one automatically. Likewise, an enterprise graph may use relational tables, a search index, vector embeddings, event storage, or cached graph projections in addition to a graph database. The logical model and governance contract matter more than a single storage engine.

The core entity model

Stable identity

Give each entity a stable internal ID that survives display-name changes, source moves, and reorganizations. Preserve every source-native ID and canonical URL as an alias with its source, time range, and confidence.

Common entity classes include:

• people, groups, teams, roles, and agents;

• customers, partners, vendors, and accounts;

• products, features, plans, and regions;

• projects, programs, goals, decisions, and tasks;

• services, repositories, deployments, incidents, and controls;

• documents, messages, tickets, records, dashboards, and datasets;

• policies, procedures, obligations, approvals, and exceptions.

Do not merge entities because their names are similar. Use deterministic identifiers where available. Probabilistic resolution should remain reviewable, retain the candidates and evidence, and support later split or correction.

Typed relationships

Edges must say more than “related to.” Useful relationship types include:

• person MEMBER_OF team;

• team OWNS service;

• service DEPENDS_ON database;

• document DESCRIBES product;

• policy APPLIES_TO region;

• decision CHANGES project;

• ticket AFFECTS customer;

• page SUPERSEDES page;

• artifact WAS_DERIVED_FROM source;

• agent ACTED_ON_BEHALF_OF user.

For each type, define allowed source and target classes, direction, multiplicity, inverse relationship, whether the edge is asserted or inferred, required evidence, validity period, sensitivity, and owner.

The difference between OWNS, EDITED, MENTIONED, and WORKED_ON matters. An edit is observed activity; it is not proof of ownership. A mention may support retrieval but should not establish authorization or accountability.

Properties and structured state

Place attributes on the entity or relationship when they are needed for filtering, authorization, calculation, lifecycle, or explanation. Examples include product version, account tier, region, sensitivity, effective date, relationship confidence, and source authority.

Avoid copying large document bodies into graph properties. Keep primary content in an appropriate store and link the graph entity to stable source objects and retrievable passages.

Provenance: why the graph believes an edge

Provenance turns a relationship from an opaque assertion into inspectable evidence. The W3C PROV model offers a useful conceptual foundation:

• an Entity is a physical, digital, conceptual, or other thing;

• an Activity occurs over time and uses, transforms, or generates entities;

• an Agent bears responsibility for an activity or entity.

It also distinguishes relationships such as wasGeneratedBy, wasDerivedFrom, wasAttributedTo, used, wasAssociatedWith, wasRevisionOf, hadPrimarySource, and actedOnBehalfOf.

You do not need to implement the entire ontology to benefit from the discipline. A minimum provenance record for a graph assertion should include:

• assertion ID and graph version;

• subject, predicate, and object;

• source system, source object ID, and canonical URL;

• source version and observed timestamp;

• asserted by a source, extracted by a rule, or inferred by a model;

• extraction rule or model version;

• supporting passage, field, event, or API response;

• confidence and validation status;

• reviewer, review date, and dispute state;

• transformation and derivation chain;

• superseded or invalidated relationship.

Provenance is not the same as correctness. A relationship can be accurately traced to an outdated, ambiguous, or unauthorized source. Ranking and reasoning must combine provenance with authority, validity, applicability, and access.

Permission-aware graph design

Security cannot be applied only after traversal. A graph can leak information through a node name, an edge, a path length, a count, an inferred relationship, a recommendation, or the absence of an expected result.

Preserve source access

Carry source ACLs, groups, direct grants, inherited restrictions, classifications, and sharing state into the graph or an authoritative policy layer. Record how enterprise identity maps to each source identity.

Authorize every surface

Apply policy to:

• seed entities and autocomplete;

• node and edge candidate generation;

• properties and evidence passages;

• multi-hop traversal;

• graph aggregates and centrality signals;

• embeddings and reranking features;

• generated answers, citations, and explanations;

• saved subgraphs, caches, exports, analytics, and logs;

• agent tools and downstream actions.

Filtering the final document is too late if an unauthorized edge already influenced ranking or generation.

Separate visibility from action authority

A user may be allowed to see that a service owner exists but not the confidential incident that established the relationship. An agent may be allowed to retrieve an account relationship but not change the CRM. Model read, quote, propose, approve, and execute as separate grants.

Fail closed on uncertainty

Unknown identity mappings, missing ACLs, stale group membership, source errors, and policy conflicts must not widen access. Return less context, abstain, or route the case for repair.

Test change, not only steady state

Measure behavior when a user changes team, a group is renamed, a guest expires, an owner is deactivated, a source object moves, a restriction is added, or access is revoked. Record revocation latency across source, index, graph, cache, conversation, and exported artifacts.

Time and versioning

Enterprise relationships change. A person changes teams, an account owner transfers, a policy becomes effective, a service dependency is replaced, and a page is superseded.

Distinguish at least:

• valid time: when the relationship was true in the business domain;

• observed time: when a source or connector saw it;

• ingestion time: when it entered the graph;

• transaction time: when the graph stored or changed it.

Late events and corrections must not silently rewrite history. Preserve prior assertions, the activity that invalidated them, and the source of the replacement. Support “current as of now” and “what was believed as of date X” queries when the use case requires them.

Use stable entity identity with versioned properties and edges rather than creating unrelated nodes for every update. Create a distinct entity when the domain meaning truly changes—for example, a new contract version or a separately governed policy edition.

Reference architecture

1. Source and connector layer

Connect systems of record and authoring tools. Preserve object types, IDs, URLs, versions, authors, owners, timestamps, ACLs, deletes, comments, attachments, and change events.

2. Identity and entity resolution

Map source principals and objects to stable enterprise identities. Keep deterministic, asserted, and probabilistic mappings distinct. Route ambiguous merges to review.

3. Semantic normalization

Map source-specific objects and fields to shared entity and relationship types without discarding native semantics. Validate domain/range, required properties, and forbidden combinations.

4. Provenance and policy

Attach evidence, lineage, confidence, time, classification, and source access to assertions. Resolve current user and agent policy before retrieval.

5. Retrieval and graph projection

Combine lexical, semantic, structured, and graph retrieval. Use graph neighborhoods for entity context, authority, related work, dependencies, expertise, and impact. Limit depth, breadth, time range, and policy scope.

6. Grounding and work

Turn the authorized subgraph into an evidence package containing claims, paths, supporting passages, conflicts, time boundaries, and gaps. Use it for search, grounded answers, briefs, impact analysis, or controlled proposals.

7. Evaluation and repair

Record bad merges, missing edges, unsupported inferences, permission defects, stale assertions, disputed ownership, failed questions, and downstream outcomes. Assign each defect to a source, schema, identity, policy, retrieval, or application owner and rerun the same case after repair.

High-value use cases

Product and service impact

Trace a proposed change through services, repositories, owners, customers, documents, incidents, and controls. The graph narrows the investigation; primary source evidence and current owners confirm the action.

Account intelligence

Connect customer, contract, stakeholders, opportunities, tickets, product usage, commitments, and internal owners. Enforce tenant and deal-team boundaries, and separate inferred interest from approved commercial commitments.

Expertise discovery

Combine explicit role, team, project membership, authored work, recent activity, and peer validation. Do not turn activity volume into an unreviewed employee ranking. Expose why a person was suggested and let people correct the profile.

Policy applicability

Connect policy editions to regions, roles, products, systems, controls, owners, and effective dates. Preserve supersession and exceptions so search and agents use the applicable rule rather than the most linked page.

Research and decision lineage

Connect claims, sources, briefs, decisions, experiments, projects, and outcomes. Users can inspect which evidence informed a decision and which later evidence changed it.

How to evaluate an enterprise knowledge graph

Create test cases for duplicate names, renamed teams, merged customers, service aliases, contradictory owners, expired policies, deleted sources, restricted neighbors, hidden edge properties, multi-hop leakage, late updates, deactivated users, and valid no-answer behavior.

Common failure modes

Starting with a universal ontology

Model one business question first. A company-wide ontology without retrieval tasks and owners becomes a taxonomy program detached from outcomes.

Using “related to” for everything

Vague edges cannot support explanation, constraints, or safe reasoning. Define relationship semantics and evidence requirements.

Merging activity with authority

Frequent editing or collaboration is a signal, not proof of ownership, expertise, or approval power.

Losing source identity

Flattened entities without canonical links, versions, and native IDs cannot be repaired when sources change.

Filtering permissions at the UI

Unauthorized graph context may already have influenced retrieval, aggregates, generation, or memory. Enforce policy throughout the pipeline.

Treating inferred edges as facts

Label inference, confidence, model version, scope, and evidence. Require human validation where a wrong relationship changes access or action.

Ignoring graph deletion

Deleting a source object must invalidate derived edges, embeddings, projections, caches, and generated artifacts according to retention policy.

A 90-day implementation plan

Days 1–30: question, schema, and authority

Choose one use case. Define entities, typed relationships, source-of-truth matrix, identity rules, provenance record, permission boundary, and success measures. Build a gold set of nodes, edges, paths, and forbidden results.

Days 31–60: ingest, resolve, and secure

Connect representative sources. Preserve IDs, ACLs, versions, and deletes. Implement entity resolution and semantic validation. Test real identities, multi-hop paths, hidden properties, and revocation.

Days 61–90: retrieve and repair

Combine graph context with primary passages and structured filters. Produce evidence-linked answers or impact reports. Record defects, assign owners, repair sources or mappings, and rerun the gold set. Expand the schema only when a new relationship improves a measured task.

Frequently asked questions

What is an enterprise knowledge graph?

It is a governed cross-system model of organizational entities and typed relationships, with source evidence, identity, permissions, time, lifecycle, and operating controls.

Is a graph database required?

No. A graph database is often useful for connected traversal, but the system may also use search, relational, vector, event, and object stores. The knowledge contract is logical.

How is it different from enterprise search?

Enterprise search retrieves content across repositories. A knowledge graph supplies entity identity and relationships that can improve authority, personalization, impact analysis, expertise, and multi-hop context. Search remains a major consumer of the graph.

How is it different from a context graph?

A knowledge graph centers entities and semantic relationships. A context graph extends that foundation with temporal work events, execution traces, policy context, and outcomes to model how work changes.

What is provenance in a knowledge graph?

It is the record of where an assertion came from, which source and version support it, how it was extracted or inferred, who or what was responsible, when it was valid, and how it was transformed or superseded.

Can a graph respect source permissions?

Yes, but only when source identity and ACLs are preserved and authorization applies to nodes, edges, properties, traversals, aggregates, evidence, generated outputs, caches, and actions.

Official sources

• Glean Help Center: Knowledge Graph

• Glean: Enterprise Graph

• Glean Help Center: About Glean Search

• Neo4j: Graph database concepts

• Neo4j: What is a graph database?

• W3C: PROV-O, the PROV Ontology

• W3C: Provenance Access and Query

Where Dokki fits

Dokki is useful when a knowledge graph needs a human-readable operating layer. Entities and relationships can stay connected to source documents, structured records, decisions, and review history instead of becoming an opaque backend index. Start with one high-value entity type, define provenance and permission rules, and keep the validation record in the same workspace.

Sources

• Glean: Knowledge Graph security

• Glean: Enterprise Graph

• Glean: About search administration

• Neo4j: Graph database concepts

• W3C: PROV-O provenance ontology

_Last verified: July 21, 2026._

• What Is a Context Graph? A Practical Model for AI

• AI Enterprise Search: Architecture and Grounded Answers

• Enterprise Knowledge Base: Architecture and Governance