Should this problem become
a knowledge graph pilot?
Eight questions to test whether relationships, evidence, and real user decisions justify a scoped build.
01 - CHECKLIST
Progress: 0/8
Answer for the first bounded use case.
Do not answer for a future enterprise platform. Answer for the smallest pilot your team could actually evaluate.
YES = 2 · NOT SURE = 1 · NOT YET = 0 · MAX 16
"Not yet" is not a failure or a rejection; it marks a condition worth preparing before the build, or during a short scoping. The score does not measure technology quality or organizational maturity - it measures whether the conditions exist to bound a pilot sensibly and evaluate it.
- 01
Is there a specific user and decision the pilot should support?
Name who will use the result, what they need to decide, and what a better answer would change.
- 02
Does the answer depend on relationships between entities?
A graph may help when paths, dependencies, shared exposure, hierarchy, or multi-hop context changes the answer.
- 03
Are useful data sources available - and can their records be connected?
Check whether the sources contain identifiers, names, dates, versions, or other defensible connection points.
- 04
Can the first model be limited to a few important relationships?
The pilot should model only what is needed to answer its first test questions - not the entire domain.
- 05
Must answers remain traceable despite gaps, conflicts, or changing facts?
Decide whether users need to inspect the source, date, status, uncertainty, or reasoning path behind an answer.
- 06
Can you define 5-10 questions the pilot must answer?
Concrete questions keep modeling, ingestion, queries, and evaluation tied to a bounded outcome.
- 07
Can a domain user evaluate whether the answers are useful and correct?
Identify who will test the result and what correct, complete, useful, and traceable mean.
- 08
Is there a clear decision to stop, change, or scale after the pilot?
A useful pilot can recommend expansion, a narrower approach, a simpler technology, or no graph at all.
02 - RESULT
Readiness is a scoping question - not a technology score.
The checklist is designed to expose missing decisions and evidence. A low score can save a team from building the wrong thing; a high score still needs a bounded scope.
Answer all 8 questions for a useful interpretation. (0/8)
03 - FIT
A pilot may make sense when…
- Several sources describe connected parts of the same problem.
- Relationships, paths, dependencies, or shared exposure affect the answer.
- Users need to trace an answer back to evidence.
- A limited model can be tested against concrete questions.
A simpler approach may be better when…
- The task is mainly finding a passage in one clean document set.
- The necessary records cannot be connected reliably.
- No user, decision, or evaluation questions have been defined.
- A relational database, search index, or conventional RAG already answers the question well.
04 - PROCESS
Scope the uncertainty before building the system.
- 1
Problem workshop
Users, decisions, sources, relationships, and test questions.
- 2
Written scope
Selected data, model boundary, deliverables, success criteria, and limitations.
- 3
Fixed price
The approved scope is priced before implementation begins.
- 4
Build and evaluate
Working graph, selected queries or retrieval, evidence trail, and a next-step recommendation.
05 - CONTACT
Discuss a bounded pilot.
Share the decision, available sources, and the question the system should answer. You will get a direct assessment of what is worth scoping - and what is not.
Every pilot is scoped and priced before work begins.