# Graph Engineering

**TL;DR:** Designing and maintaining the entity-and-relationship layer that AI systems traverse, covering schema, extraction, resolution, provenance, and pruning

Vector search finds things that sound alike. Graphs answer questions about how things connect. Ask "what did we decide about pricing?" and semantic similarity handles it fine. Ask "which customers were affected by the decision that Priya made in Q2, and who else touched that decision," and you need a structure that stores relationships as first-class objects. Graph engineering is the work of building and maintaining that structure so it stays correct as reality changes underneath it.

Schema design comes first and constrains everything after it. What is a node, what is an edge, how strictly are they typed? The failure mode at this stage is a beautifully elaborate ontology with forty entity types that nobody ever populates, because extraction can't reliably distinguish them. Start narrow, with entities you can extract with high precision, and add types when there's a query that needs them.

Extraction is where an LLM reads unstructured text and emits entities and relations. It is also where drift enters your system, because the same document processed with a different model or a tweaked prompt yields subtly different edges. Version the extraction prompt like schema migration code. Then comes entity resolution, the unglamorous work that determines whether the graph is useful at all: "Acme Corp," "Acme Corporation," and "ACME" must collapse into one node, or your graph fragments into a constellation of near-duplicates that traversal can never connect.

Every edge needs provenance and time. Provenance means the source document, the extraction run, and a confidence score, so you can trace a claim back and re-derive it when the source updates. Time means validity intervals, because "Sarah works at Acme" is not a fact but a fact-with-a-window, and a graph that stores it as timeless will confidently tell you something false eighteen months from now. Graphs also grow monotonically unless someone stops them, so pruning and compaction are ongoing operations rather than one-time cleanup, and skipping them is how context rot sets in.

Then there's traversal design. A query that hops without bound returns half the graph, and half the graph does not fit in a context window. Practical systems cap hop depth, rank paths by edge weight and recency, and cut off at a token budget. The retrieved subgraph then needs serializing into text the model can actually use, which is its own design problem: a raw edge list is technically complete and practically useless compared to a few well-formed sentences.

In practice, graphs work alongside other stores rather than replacing them. Maximem Synap organizes memory across three stores, vector, graph, and file, because they answer different question shapes, and across three scopes, User, Customer, and Client, so relationships stay bounded to the right context. The graph store is where relationships between memories live, which is exactly the part vector similarity cannot reconstruct.

## Why it matters

Semantic search retrieves passages, but real questions are usually about connections: who depends on this, what changed since, which decisions share a cause. A well-engineered graph makes multi-hop reasoning tractable and gives every answer a traceable path through explicit relationships instead of a similarity score nobody can audit. A badly engineered one is worse than nothing, since fragmented entities and stale edges produce confident, wrong answers with the appearance of structure.

## Example

A company builds an internal assistant over five years of project documents. Vector search alone answers "what was the Helios launch plan" adequately and fails completely at "who worked on projects that depended on the Helios API, and what did they flag." Graph engineering makes the second question answerable: people, projects, and services become nodes, dependencies and authorship become typed edges, entity resolution merges "Helios API," "helios-api," and "the Helios service" into one node, and traversal is capped at three hops and ranked by recency so the retrieved subgraph fits in context.

## Related terms

- [Knowledge Graph](https://www.maximem.ai/glossary/knowledge-graph)
- [Graph RAG](https://www.maximem.ai/glossary/graph-rag)
- [Embeddings](https://www.maximem.ai/glossary/embeddings)
- [Retrieval Pipeline](https://www.maximem.ai/glossary/retrieval-pipeline)
- [Memory Consolidation](https://www.maximem.ai/glossary/memory-consolidation)
- [Context Rot](https://www.maximem.ai/glossary/context-rot)
- [Hybrid Search](https://www.maximem.ai/glossary/hybrid-search)

---

Source: [https://www.maximem.ai/glossary/graph-engineering](https://www.maximem.ai/glossary/graph-engineering)