Context Graphs, and how they connect people to priorities

This is a course, not a summary. Eight modules build from "what is a graph" to a concrete design for Cadence's people-to-priorities graph, with a worked query that flat retrieval cannot answer. Every claim is tagged by how much you should trust it.

Start with the family tree, because the vocabulary is a minefield of near-synonyms that vendors use loosely.

The ancestor: semantic networks

A semantic network (Quillian, 1960s) is a knowledge base that represents semantic relations between concepts as a directed or undirected graph whose vertices are concepts and whose edges are semantic relations Sourced fact S11. This is the decades-old root of everything below: nodes-are-things, edges-are-meaning.

The workhorse: knowledge graphs

A knowledge graph (KG) is a semantic network populated with real-world entities and their relationships, usually at scale, usually meant to be queried and reasoned over. Modern KGs come in two competing data models (Module 2). The important lineage fact: a KG is the substrate; "context graph" is a usage of that substrate.

The disputed term: context graph

Here the field genuinely disagrees Contested. One camp (TrustGraph) frames a context graph as distinct layers — ontological grounding + AI-optimized retrieval — built on top of a base knowledge graph Vendor framing S12. Another camp states flatly that "a context graph is a knowledge graph; the distinction is not in the underlying data structure — it is in what the graph is optimized to do" Sourced fact S12. A third, code-tooling usage defines it as "a graph where nodes represent chunks of information (files, functions, concepts, past conversations) and edges represent relationships (imports, calls, references, similarity)" Vendor framing.

The working definition for this course Inference: a context graph is a labeled, typed, often temporally-aware graph that serves as an explicit relational memory / grounding layer — most often for an LLM. Structurally it is a knowledge graph; the word "context" names its job (feed relevant, connected context to a reasoning system), not a new data structure.

The LLM "memory / context layer"

The newest sense of the term. Graph-based agent memory uses a graph as an LLM's long-term memory because it "can naturally encode relational dependencies between memory elements... due to its intrinsic ability to model entity relationships, capture hierarchical semantics, and support flexible traversal" — capabilities that fixed-length token windows, vector databases, and log buffers lack Sourced fact S1.

The load-bearing theory: two data models, how you attach meaning and metadata to edges, and how you model time. Time is the part Cadence cannot skip.

Two data models: RDF triples vs. Labeled Property Graphs

There are two dominant graph data models at different abstraction levels Sourced fact S4:

• RDF (Resource Description Framework, from the W3C semantic-web world): everything is a triple — subject – predicate – object. Fine-grained, standardized, great for open-world data integration.
• Labeled Property Graph (LPG) (from graph-DB vendors like Neo4j): nodes and edges are first-class objects that carry inlined key-value properties and labels.

"The two models look at graphs from different abstraction layers (triples in RDF vs. edges connecting vertices with inlined properties in LPGs)" Sourced fact S4. A unifying Statement Graphs model can represent both and be queried by either family of query language — but only as a read-only, two-language (SPARQL + Gremlin) proof-of-concept, not production Sourced fact S4.

A practical difference that bites: in RDF, relationships are not first-class — you can't distinguish two relationships of the same type between the same two nodes without join-table-style workarounds; LPGs give every relationship its own identity and properties Vendor framing S13.

Edge semantics, provenance, confidence, weighting

You will want to say things about a relationship — who asserted it, when, with what confidence. Traditional RDF reification (modeling a statement as its own resource so you can annotate it) is widely regarded as "cumbersome, misunderstood, unpopular" and is "one of the most persistent criticisms of RDF... compared to LPGs" — per Ora Lassila, co-author of the original 1999 RDF spec Sourced fact S8. RDF-star / RDF 1.2 fixes this with "triple terms" that annotate a statement directly, superseding the old reification vocabulary as the preferred mechanism (without removing it) Sourced fact S8.

Takeaway Inference: to carry "this task supports this rock — confidence 0.8, asserted by AI on 2026-07-01," an LPG edge property or an RDF-star triple term both work; the LPG is simpler. Classic reification is the anti-pattern to avoid.

Temporal & bitemporal modeling — the part Cadence lives or dies on

This is the single most Cadence-load-bearing area of the theory. Bitemporal modeling adds two orthogonal time axes Sourced fact S5 S6:

• Valid time — when a fact holds in the real world (when was this rock actually in effect).
• Transaction time — when the fact was recorded/asserted (what did we believe last Tuesday).

The BiTemporal RDF (BiTRDF) model integrates both to enable "time travel" querying of dynamic and historical knowledge, and does so by embedding time as a reference directly into resources "rather than appending timestamps as auxiliary attributes... avoid[ing] the complexity of reification-based approaches" Sourced fact S5. The bitemporal combination is stable, peer-reviewed theory in the Snodgrass lineage Sourced fact S6.

Caution on maturity: the broader spatio-temporal KG subfield is immature and fragmented — "unified modeling frameworks are largely absent and most current models are tailored to specific use cases rather than designed for reuse" Sourced fact S7. There is no off-the-shelf temporal-graph standard to adopt wholesale; you design edge semantics and annotation strategy deliberately.

Ontology design & entity resolution

An ontology is the formal schema of entity types and allowed relationships. Entity resolution is deciding when two records are the same real-world thing. Poor entity resolution is "one of the most common sources of data 'garbage'" in knowledge graphs, degrading downstream retrieval accuracy Vendor framing S14 — a theme that returns as a hard pitfall in Module 7.

Two very different intake paths: structured data (ETL) and unstructured text (extraction). Cadence has a lot of the first and a little of the second, and the second is where LLMs earn their place.

The canonical pipeline

A production KG-construction pipeline from unstructured text decomposes into a defined component set — data loader → text splitter → chunk embedder → schema builder → lexical graph builder → entity & relation extractor → graph pruner → KG writer → entity resolver (some optional) Sourced fact S9. The extractor operates per text chunk, and the schema grounds the LLM to a predefined list of allowed node and relationship types rather than letting it invent arbitrary entities Sourced fact S9.

Nuance the source is explicit about Contested: the schema is a soft guide by default; hard enforcement requires the graph-pruner step (additional_node_types=False) Sourced fact S9.

Incremental update, dedup, conflict resolution

The entity-resolver stage is not optional in practice: failing to resolve duplicates produces garbage-in/garbage-out retrieval Vendor framing S14. For a live app the hard part is keeping the graph fresh as source rows change weekly — covered as an open question in the caveats, because the sources diagnose the drift problem far better than they solve it for transactional apps.

Native graph database, or a graph view over the relational store you already have? The honest answer for Cadence is "probably the second, at first" — and the sources give you the decision rule.

The engines and their languages

The decision rule that actually matters

The most useful contrarian finding in the whole research set Vendor framing S18: "Don't pick based on schema. Pick based on query shape." Having relational or highly-connected data does not by itself justify a graph database — many-to-many relationships (students↔courses) are handled fine by SQL join tables. Graph databases win when you traverse relationships directly instead of executing deep, variable-length JOINs, delivering multi-hop results "in seconds where relational databases struggle" Vendor framing S17.

This is the "why bother" module. The case for a context graph over plain vector search rests on two verified claims about what similarity-only retrieval structurally cannot do.

The structural argument

Graph-based memory explicitly encodes relational dependencies that fixed-length token sequences, vector databases, and log buffers cannot Sourced fact S1. And pure similarity matching fails on multi-hop queries for a precise reason: "answers to complex queries often depend on entities not in the original query. Pure similarity matching cannot bridge this gap", and separately, "similarity does not guarantee relevance" Sourced fact S1.

Honest nuance Contested: embeddings encode some relational information implicitly, so the advantage is explicit-vs-implicit structure — and well-built hybrid (vector + graph) systems often win over either alone Inference.

GraphRAG, mechanically

GraphRAG (Edge et al., Microsoft Research, 2024) is a two-stage LLM-built index plus map-reduce querying Sourced fact S2 S3:

1. Use an LLM to derive an entity knowledge graph from source documents.
2. Apply community detection (the Leiden algorithm) to group closely related entities into a hierarchy, and pre-generate a summary per community.
3. At query time, each community summary yields a partial answer; all partials are aggregated into a final response.

The problem it was built to solve: conventional/naive vector RAG "fails on global questions directed at an entire text corpus, such as 'What are the main themes in the dataset?', since this is inherently a query-focused summarization task, rather than an explicit retrieval task" Sourced fact S2 S3. On ~1M-token datasets, GraphRAG showed "substantial improvements over a conventional RAG baseline for both the comprehensiveness and diversity of generated answers" Sourced fact S2.

No single structure wins

Crucially, the survey states there is no dominant structure — it's an objective-dependent trade-off: "precision and explicit multiple-hop reasoning favor relational graphs; compression and conceptual abstraction favor hierarchical or tree-like summaries; temporal fidelity motivates temporal knowledge graphs... cross-modal or fuzzy recall often favors vector stores or hybrid systems" Sourced fact S1.

Everything above, applied. This module maps Cadence's real schema to graph entities and edges, works a query flat retrieval can't answer, and says plainly where the graph is overkill. All schema facts below were read from prisma/schema.prisma; all design recommendations are Inference.

The entities (nodes)

The edges (typed relationships)

These are the real foreign keys, grouped by what they connect Inference on grouping; FKs are fact:

Person → work

• CAPTAIN_OF / CREATED / CONTRIBUTES_TO → Rock (captainId, createdById, contributors[])
• ASSIGNED → Task (Task.assigneeId)
• MEMBER_OF / CAPTAINS → Group (Group.members[], captainId)

Person → measurable (the accountability truth table)

• RESPONSIBLE_FOR → Measurable via MeasurableResponsibility (source = CAPTAIN/MEMBER, effectiveTo = null means active) — this, not a bare ownerId, is where person↔metric accountability lives, and it is valid-time-stamped.

Work → work (the "ladder", i.e. the goal chain)

• PARENT → Rock (Rock.parentId, self-ref — climb to tier 1)
• SUPPORTS → Rock/Project (Project.parentRockId, Task.rockId/projectId)
• MEASURES → work item via MeasurableWorkItemLink (polymorphic itemType)

Person → time (pulse / check-in linkage)

• REFLECTED → WeeklyReflection (userId, keyed weekOf)
• PulseConversation uses the ADR-0073 typed-FK exclusive arc: exactly one of reflectionId | reviewPeriodId | quarterlyReviewPeriodId (enforced by a SQL CHECK). This is Cadence's own answer to polymorphic edges — worth studying as the house pattern for any new cross-type edge.

Worked example — the query flat retrieval cannot answer

The payoff

The question a manager actually wants: "Which of my reports are working on priorities that don't ladder up to any active company rock?" This is a multi-hop, negation-over-traversal question. A vector search over check-in text cannot answer it — the answer depends on entities (the company rocks) that are not in the query, exactly the failure mode the survey names Sourced fact S1.

As a graph traversal (Cypher-style pseudocode)

// reports of manager M, their active rocks, that DON'T reach a tier-1 company rock
MATCH (m:Person {id:$managerId})<-[:REPORTS_TO]-(r:Person)
MATCH (r)-[:CAPTAIN_OF|CONTRIBUTES_TO]->(rock:Rock {state:'active'})
WHERE NOT EXISTS {
  (rock)-[:PARENT*1..5]->(company:Rock {tier:1, state:'active'})
}
RETURN r.name, rock.title // the misaligned work, per report

The variable-length [:PARENT*1..5] traversal is the whole game: one clause climbs an arbitrary-depth ladder. In SQL that same climb is a recursive CTE:

-- the same "does it reach a tier-1 rock" test, recursively
WITH RECURSIVE ladder AS (
  SELECT id, "parentId", tier FROM rocks WHERE id = rock.id
  UNION ALL
  SELECT p.id, p."parentId", p.tier
  FROM rocks p JOIN ladder l ON p.id = l."parentId"
)
SELECT NOT EXISTS (SELECT 1 FROM ladder WHERE tier = 1 AND state='active');

Both work. The point is not "SQL can't" — it demonstrably can. The point Inference is that as these questions compose ("...and whose owner also flagged feeling blocked in last week's pulse, and whose measurable is trending down"), the recursive-CTE version multiplies in complexity while the graph version adds one MATCH clause each. That compounding is the real, honest case for a graph layer — consistent with the "pick by query shape" rule Vendor framing S18.

Product features the graph unlocks

• Who's blocked — a BLOCKED_BY edge extracted from pulse text, traversed to find chains and their root cause.
• Starved priorities — company rocks (tier-1) with few or no CONTRIBUTES_TO / ASSIGNED edges reaching them: attention is a graph property.
• Alignment — the worked example above, run org-wide.
• Manager-bias correction — grounding an AI review draft on the actual edges (tasks completed, measurables moved) rather than the manager's recalled narrative Inference; aligns with existing Cadence philosophy.
• AI chat / briefs / recommendations — GraphRAG-style community summaries over the org subgraph, so a brief cites real connected entities instead of hallucinating them.

Multi-tenancy / org-scoping

Open problem — no source covers this. None of the reviewed sources address enforcing per-org isolation within a shared context graph. Cadence's answer already exists in the relational layer — RLS + orgId on every tenant row (ADR-0023). The design question Inference: is org a node label, an edge/property filter, or a physically partitioned subgraph? A projection-from-relational approach inherits RLS for free and is the safest default; a native store would need org isolation rebuilt from scratch, which is a strong argument against standing one up early.

Where a context graph is overkill for Cadence

Inference throughout — fixed-depth lookups (this rock's captain, this task's assignee, this week's pulse for this person) are perfect relational queries and gain nothing from a graph. Simple many-to-many (person↔group membership) is a join table, and "relationships alone don't justify a graph database" Vendor framing S18. Reserve the graph for variable-depth traversal, negation-over-paths, and AI grounding. Everything else stays in Postgres.

These failure modes are empirical, not theoretical. The two that will bite Cadence hardest are entity-resolution debt and drift from the source-of-truth.

Inconsistency at scale is the norm, not the exception

Large real-world KGs routinely contain logically contradicting statements. Testing across DBpedia, YAGO, and LOD-a-lot — over 28 billion triples — revealed billions of contradictions, condensable into compact anti-pattern catalogs (222 / 13 / 135 anti-patterns respectively); LOD-a-lot alone "contains over a billion contradictions" Sourced fact S10.

The catalog

Read in this order; each item earns its place. Then do the exercises against Cadence's own data — that is where fluency actually forms.

Reading list, prioritized

1. Start here — the "why": Edge et al., From Local to Global: A Graph RAG Approach (arXiv:2404.16130) S2. The canonical GraphRAG paper. Read the abstract and §1–2 for the flat-RAG failure argument.
2. The map of the field: Graph-based Agent Memory: Taxonomy, Techniques, and Applications (arXiv:2602.05665) S1. §V (structure trade-offs) and §VI-A (why similarity fails) are the load-bearing sections.
3. The data-model decision: Gelling et al., Bridging graph data models (arXiv:2304.13097) S4 for RDF vs LPG done rigorously; Lassila's RDF-star intro S8 for edge-metadata.
4. Time: Time Travel with the BiTemporal RDF Model (MDPI Mathematics 13:2109) S5 — the valid-time/transaction-time distinction Cadence needs.
5. Build it: the Neo4j GraphRAG Python KG-builder docs S9 — the concrete pipeline, hands-on.
6. Stay honest: de Groot et al., Analysing Large Inconsistent KGs Using Anti-patterns S10, and the "pick by query shape" argument S18.

Exercises against Cadence data

1. Recursive CTE warm-up. Write the SQL that, for one Rock, climbs parentId to determine whether it reaches an active tier=1 rock. You now understand the ladder in the relational world.
2. Feel the pain. Extend it: reports of a manager × their active rocks × the ladder test × "and their measurable is trending down." Watch the CTE grow. This is the graph's motivation, felt firsthand.
3. Project a subgraph. Export one org's Person / Rock / Task / Measurable rows + FKs into an LPG (Neo4j or in-memory) and re-run exercise 2 as Cypher. Compare clause count and readability.
4. Extraction. Take 20 real WeeklyReflection.content rows; prompt an LLM to extract BLOCKED_BY edges grounded to a fixed schema (Person, Rock, Task only). Measure precision. This is Module 3 for real.
5. Temporal query. Using MeasurableResponsibility.effectiveFrom/effectiveTo, answer "who was responsible for this metric as-of last quarter" — valid-time in practice.
6. Drift check. Snapshot the projected graph, change a rock's parent in Postgres, and measure how your reconciliation cadence catches it. Feel the source-of-truth discipline from Module 7.

How much to trust this

The strongest sources cluster on two poles: the 2024 Microsoft GraphRAG paper (canonical but vendor-authored, evaluated via LLM-as-judge win-rates on a specific ~1M-token regime) and 2025–2026 arXiv surveys (current but non-peer-reviewed, stating architecture as assertion rather than measured result). The bitemporal claims rest on peer-reviewed MDPI/ACM sources and stable Snodgrass-lineage theory — those are solid. One source (MDPI BiTRDF full text) returned 403 on fetch and was verified via search excerpt only. Several "fails/cannot" framings are the cited authors' characterizations of baselines; well-engineered hybrids partially close those gaps.

Genuinely open questions the research did not answer

• Org-scoping a shared graph: node label vs property filter vs partitioned subgraph — traversal-perf and leakage trade-offs unaddressed by any source.
• Native store vs graph-view-over-Postgres for Cadence's scale: the perf-cliff crossover point is described only abstractly.
• Operational query-language / algorithm guidance (Cypher vs SPARQL vs Gremlin; which centrality/community algorithms for "starved priorities") — under-covered beyond GraphRAG's Leiden default.
• Reconciliation cadence for a live app with weekly-changing priorities — the drift problem is well-diagnosed at web scale but has no validated incremental-update recipe for a transactional product.

25 claims were adversarially verified (2-of-3 refute votes required to kill a claim); all 25 survived. Tier reflects source quality.

1. primary · arXiv
   Graph-based Agent Memory: Taxonomy, Techniques, and Applications (2026). arxiv.org/html/2602.05665v1
2. primary · arXiv
   Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft, 2024). arxiv.org/abs/2404.16130
3. primary · vendor research
   Microsoft Research publication page for the GraphRAG paper. microsoft.com/en-us/research/publication/…
4. primary · peer-reviewed
   Gelling, Fletcher, Schmidt, Bridging graph data models (arXiv:2304.13097, Springer 2024). arxiv.org/pdf/2304.13097
5. primary · peer-reviewed
   Time Travel with the BiTemporal RDF Model, MDPI Mathematics 13(13):2109 (2025). mdpi.com/2227-7390/13/13/2109
6. primary · peer-reviewed
   Chekol & Stuckenschmidt, Towards Probabilistic Bitemporal Knowledge Graphs (WWW 2018). dl.acm.org/doi/…/3191637
7. primary · arXiv survey
   Plamper, Köpcke, Groß, A Survey on Spatio-Temporal Knowledge Graph Models (arXiv:2512.16487, 2025). arxiv.org/abs/2512.16487
8. primary · standards author
   Ora Lassila, RDF-star intro, W3C TPAC 2024. lassila.org/publications/2024/TPAC2024/…
9. primary · framework docs
   Neo4j GraphRAG Python — KG Builder user guide. neo4j.com/docs/neo4j-graphrag-python/…
10. primary · peer-reviewed
    de Groot, Raad, Schlobach, Analysing Large Inconsistent Knowledge Graphs Using Anti-patterns (Springer, 2021). link.springer.com/chapter/10.1007/978-3-030-77385-4_3
11. secondary
    Wikipedia — Semantic network. en.wikipedia.org/wiki/Semantic_network
12. blog · vendor
    TrustGraph — Context Graph vs. Knowledge Graph. trustgraph.ai/guides/key-concepts/…
13. blog · vendor
    Neo4j — RDF vs Property Graphs. neo4j.com/blog/knowledge-graph/…
14. blog
    Modern Data 101 — Entity Resolution at Scale. moderndata101.com/blogs/entity-resolution-at-scale…
15. blog · vendor
    FalkorDB — Graph Database Anti-patterns & AI Performance (super nodes). falkordb.com/blog/graph-database-anti-patterns-ai-performance/
16. blog · practitioner
    Semantic Arts — Six Enterprise Knowledge Graph Anti-Patterns. semanticarts.com/six-enterprise-knowledge-graph-anti-patterns/
17. blog · vendor
    PuppyGraph — Graph Database vs Relational Database. puppygraph.com/blog/graph-database-vs-relational-database
18. blog
    "RDBMS vs Graph DB: Why relationships alone don't justify a graph database." medium.com/@go-fireball/…
19. blog · vendor
    AWS — Improving RAG accuracy with GraphRAG. aws.amazon.com/blogs/machine-learning/…graphrag/
20. blog · vendor
    Senzing — Knowledge Graphs & GraphRAG. senzing.com/knowledge-graphs-graphrag/

Cadence schema facts (Modules 6–8) were read directly from prisma/schema.prisma and confirmed in src/lib/person-measurables.ts, src/app/today/today-data.ts, and ADRs 0069 / 0073 / 0074 / 0075 — not from any web source. All such facts are labeled as schema-derived; all design recommendations built on them are labeled Inference.