# Knowledge Graph Inconsistencies

## The Problem

Relationships between entities (users, teams, resources) stored inconsistently or incompletely, breaking multi-hop reasoning and access control logic.

### Symptoms

* ❌ "Alice is in Engineering" + "Bob is in Engineering" but no team entity
* ❌ Relationships not bidirectional
* ❌ Entity resolution errors (multiple IDs for same entity)
* ❌ Broken transitive relationships
* ❌ Cannot query "who can access X?"

### Real-World Example

```
Knowledge base facts:
→ Doc A: "Alice works on Project Phoenix"
→ Doc B: "Project Phoenix uses Database Prod-DB"
→ Doc C: "Bob manages Database Prod-DB"

Query: "Who can access Prod-DB?"

Expected reasoning:
→ Alice → Project Phoenix → Prod-DB ✓
→ Bob → manages → Prod-DB ✓

AI response: "Bob manages Prod-DB"
→ Missed: Alice's indirect access via Project Phoenix
→ Relationships not explicitly modeled
```

***

## Deep Technical Analysis

### Implicit vs Explicit Relationships

**Text-Based (Implicit):**

```
Current approach:
→ Facts embedded in text
→ "Alice is member of Engineering team"
→ LLM must infer relationships

Problems:
→ Inference unreliable
→ Multi-hop reasoning fails
→ Cannot query graph structure
```

**Graph-Based (Explicit):**

```
Knowledge graph:
→ Nodes: Alice, Engineering, Project Phoenix
→ Edges: 
  - Alice -[memberOf]-> Engineering
  - Engineering -[worksOn]-> Project Phoenix
  - Project Phoenix -[uses]-> Prod-DB

Graph query:
→ MATCH (u:User)-[:memberOf]->(t:Team)-[:worksOn]->(p:Project)-[:uses]->(d:Database {name: "Prod-DB"})
→ RETURN u

Explicit traversal finds Alice
```

### Entity Resolution

**Multiple Representations:**

```
Same person, different references:
→ "Alice Smith"
→ "Alice S."
→ "A. Smith"
→ "alice.smith@company.com"
→ User ID: 12345

Without resolution:
→ Treated as 5 different entities
→ Relationships fragmented
```

**Canonical Entities:**

```
Entity resolution:
→ Create canonical: entity_id: "user_12345"
→ Map all variants:
  - "Alice Smith" → user_12345
  - "alice.smith@company.com" → user_12345

All relationships link to canonical ID
```

### Relationship Types

**Access Control Graph:**

```
Relationship types:
→ memberOf: User → Team
→ hasAccess: Team → Resource
→ manages: User → Resource
→ inheritsFrom: Role → Role

Query: "Can Alice access X?"
→ Traverse: Alice -[memberOf]-> Team -[hasAccess]-> X
→ Or: Alice -[manages]-> X
→ Multiple paths possible
```

**Temporal Relationships:**

```
Relationships change over time:
→ "Alice was in Engineering (2022-2023)"
→ "Alice now in Sales (2024-present)"

Graph needs temporal dimension:
{
  from: "user_12345",
  to: "team_engineering",
  relationship: "memberOf",
  valid_from: "2022-01-01",
  valid_until: "2023-12-31"
}

Current query uses current relationships only
```

### Hybrid RAG + KG

**Combined Approach:**

```
1. Vector retrieval: Find relevant chunks
2. Entity extraction: Identify entities in chunks
3. Graph expansion: Query KG for related entities
4. Enriched context: Chunks + graph facts

Example:
Query: "What does Alice work on?"
→ Vector: Retrieves "Alice's bio"
→ KG: Finds Alice's team, projects, permissions
→ Combined: Complete picture
```

***

## How to Solve

**Build explicit knowledge graph for entities and relationships + implement entity resolution (canonical IDs) + use typed relationships (memberOf, hasAccess, manages) + store bidirectional edges + implement graph traversal for multi-hop queries + combine vector search with graph expansion + maintain temporal validity of relationships + test access control queries against graph.** See [Knowledge Graphs](/rag-scenarios-and-solutions/data-quality/knowledge-graph.md).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.twig.so/rag-scenarios-and-solutions/data-quality/knowledge-graph.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.