Most advice about knowledge graphs is a pile of disconnected tips. Tips don't transfer well — you learn one project's lessons and then re-learn them on the next. What transfers is a framework: a named, reusable model you can apply to any graph problem and know what to decide at each stage. This article presents one, deliberately simple enough to remember and reuse.
I call it the QUERY framework because the word is both a mnemonic and a reminder of the central truth: a knowledge graph exists to answer queries, and every decision should serve that. The five stages are Questions, Units, Edges, Resolution, and Yield. Walk them in order for a new build; revisit any single stage when something's wrong. Each maps to a phase you'll recognize from our step-by-step guide, but the framing here is the reusable model behind the steps.
Stage Q: Questions
What it decides: The entire scope of the graph.
Every QUERY engagement starts by writing three to five concrete questions the graph must answer. Not "understand our data" — specific, answerable questions like "which suppliers depend on a single shipping route." This stage is non-negotiable and comes first because every later decision is judged against it.
When you're done: You have a written question list specific enough that someone else could tell whether a given query belongs to it. This list becomes the graph's living specification — you'll return to it at every later stage.
The discipline of Q prevents the single most common failure: modeling data instead of questions, which our common mistakes guide ranks first.
Stage U: Units
What it decides: Your node types — the units of meaning in the graph.
Read your questions and extract the distinct kinds of things they reference. These become node types. The rule is strict: a unit qualifies only if a question references it. A supplier, a route, a shipment might qualify; a "metadata blob" does not.
The Lean Test
Apply this test to every candidate unit: does removing it make any of my questions unanswerable? If no, cut it. Lean unit sets keep the schema comprehensible. The failure mode here is node inflation — promoting properties (a date, a status) to nodes when they should stay attributes.
Stage E: Edges
What it decides: The relationship types that connect your units.
From the verbs and relationships in your questions, derive edge types. The governing principle is fewest edges that answer the questions. Before adding an edge type, ask whether an existing type plus a property would do the same job. DEPENDS_ON with a kind property often beats four near-synonym edges.
When you're done: Every question can be traced as a path through your units and edges, even if some paths are multi-hop. Crucially, you do not add edges for relationships that traversal can derive. "Suppliers sharing a route" emerges from walking through route nodes; you don't store a direct supplier-to-supplier link.
Stage R: Resolution
What it decides: When two records become one node — the correctness foundation.
This is the stage teams under-invest in and the one that determines whether the graph tells the truth. Build resolution as a tiered pipeline:
- Exact match on a strong key → auto-merge.
- Fuzzy match on weaker signals above a threshold → auto-merge; below → human queue.
- No reliable signal → keep separate, flag.
When you're done: Your most important entities each map to exactly one node, verified by spot-check, and the pipeline runs on every future ingest. Resolution is not a stage you finish once; it's one you operationalize. Skipping it is the most damaging error in the entire discipline, and our best practices article treats it as a first-class pipeline for this reason.
Stage Y: Yield
What it decides: Whether the graph actually delivers, and how it evolves.
Yield is where you prove the graph answers your Stage Q questions and set it up to keep doing so. Two activities:
- Validate: Express each question as a traversal, run it, and check results against known truths. Maintain a fixed validation set you re-run after every change, because graphs fail silently.
- Evolve: When a new question arrives, loop back to Stage U or E and add only what that question needs, then re-validate.
When you're done: Your validation set passes, and you have a documented loop for adding to the graph without bloating it. Yield turns a one-time build into a living system.
When to Apply Each Stage
The framework isn't only linear. Use it diagnostically:
- Graph answers nonsense? Suspect Stage R — duplicate or missing nodes.
- Can't express a question as a query? Revisit Stage U or E — a unit or edge is missing.
- Schema nobody understands? You skipped the lean tests in U and E.
- Graph drifting out of relevance? Stage Y's evolution loop isn't running.
This diagnostic use is the framework's real payoff. When something breaks, QUERY tells you which stage to inspect instead of leaving you to guess.
Applying QUERY to a Real Problem
To see the framework move, run it against a concrete brief: a logistics company wants to understand supply-chain risk.
Q (Questions): "Which of our products depend on a single supplier?" "If this port closes, which shipments are affected?" "Which suppliers share a dependency we didn't know about?" Three questions, all relationship-shaped.
U (Units): The nouns yield Product, Supplier, Shipment, Port. A "risk score" is not a unit — it's a derived property, so it stays out.
E (Edges): The verbs yield SUPPLIED_BY, SHIPPED_THROUGH, CONTAINS. Note there's no direct supplier-to-supplier edge; "suppliers sharing a dependency" emerges from traversal through shared ports or parts.
R (Resolution): The same supplier appears as "Acme Logistics," "Acme Log.," and a tax ID across systems. The pipeline collapses them into one node, or every risk answer is wrong.
Y (Yield): Each question becomes a traversal, validated against known dependencies. When the company later asks "which products are affected by a labor strike," that new question loops back to U to add a Region unit — only what the question needs.
Walking a real brief this way shows the framework's discipline in action: lean units, derived relationships, resolution as the correctness anchor, and a question-driven evolution loop. The same five stages would structure a fraud graph, a recommendation graph, or a research graph with no change to the method.
How QUERY Relates to AI
The framework holds whether or not large language models are involved, but two stages shift when they are. In Stage U and E, an LLM can propose units and edges by reading unstructured text — accelerating work that used to be manual. In Stage R, the LLM's proposals must pass through your resolution pipeline, because models cheerfully invent duplicates. The framing stays the same: AI proposes within stages, your governed framework disposes. That division is why graphs and LLMs pair so well rather than competing.
Frequently Asked Questions
Why a framework instead of just a checklist?
A checklist tells you what to do; a framework tells you why and which stage owns a given decision. The QUERY stages let you diagnose problems — nonsense answers point to Resolution, unaskable questions point to Units — rather than just confirming tasks are done. Frameworks transfer across projects in a way checklists don't.
Do I have to follow the stages strictly in order?
For a first build, yes — each stage depends on the prior one. Questions scope Units, Units enable Edges, and so on. For an existing graph, jump straight to whichever stage your symptom points to. The order matters most when building from scratch.
What if my questions change midway through?
That's what Stage Y's evolution loop is for. A changed question sends you back to Units or Edges to add only what it requires, then through validation again. The framework expects questions to evolve; rigidity would defeat the purpose. A graph that can't evolve slowly dies.
Which stage do teams most often get wrong?
Resolution (R), by a wide margin. It's invisible work with no immediate payoff, so teams skip it and the graph silently produces wrong answers. The framework deliberately makes R its own named stage to force the investment that ad-hoc approaches skip.
Can the QUERY framework handle very large graphs?
Yes — the stages are scale-independent. Large graphs make Resolution harder and Yield's performance checks more important, but the framework's logic is identical. If anything, the discipline matters more at scale, where node inflation and silent corruption are harder to spot by eye.
Key Takeaways
- The QUERY framework — Questions, Units, Edges, Resolution, Yield — is a reusable model for any graph problem.
- Questions scope everything; every later stage is judged against the written question list.
- Units and Edges should pass a lean test: remove anything no question needs.
- Resolution is its own named stage because it's the under-invested key to correctness.
- Yield validates against ground truth and runs the loop that lets the graph evolve without bloating.