Choose the information structure
Knowledge base vs knowledge graph: when do connected relationships matter?
A knowledge base organises information so people or systems can find and use it. A knowledge graph explicitly records relationships between things. They can work together: a graph may connect the clients, agreements and people described in a knowledge base. The choice depends on your questions and the effort needed to keep those connections correct.
Use the simplest structure that answers the recurring question reliably; add explicit relationships when people repeatedly have to reconstruct them.
Compare how each structure helps you find an answer
| Part | Knowledge base | Knowledge graph |
|---|---|---|
| Main organising idea | Pages, records or documents arranged for finding and use. | Identified things connected by named relationships. |
| Simple question | Open a current agreement or method. | Find a node and its relevant properties or links. |
| Connected question | Read several records and join their details. | Follow explicitly recorded links between records. |
| Upkeep | Keep content, versions, owners and navigation current. | Also maintain identities, relationship meanings and validity. |
| Combination | Documents can provide the evidence. | Relationships can point back to those documents. |
These are design choices, rather than a rule that one technology replaces the other. A database or document system can also hold relationships. The important question is whether those relationships are explicit enough for the work you want to do.
Ask the same client-work questions in both designs
Use the invented reporting situation from our knowledge graph guide. In the knowledge base, a client page links to the current agreement, reporting task and responsible people. In the graph, those connections have named relationships.
| Question | Client-page knowledge base | Explicit graph |
|---|---|---|
| How often is the report due? | Open the current agreement and read the requirement. | Read the current agreement node or linked source. |
| Who resolves a task requirement? | Find the task, its agreement and the agreement’s owner. | Follow task → governing agreement → owner. |
| Which tasks depend on an expiring agreement? | Inspect task records or use an index maintained for that purpose. | Find tasks linked to agreements with the relevant validity date. |
| Why is that owner recorded? | Open the ownership note or decision. | Open the evidence attached to the ownership relationship. |
If a client page answers the first two questions reliably, preserve that useful structure. The third question creates a stronger reason to record relationships explicitly, especially if it occurs across many clients. Test it with representative records before accepting the extra maintenance.
Carry permissions and evidence through either structure
A connected query must not expose a private client simply because a shared person links to it. Filter authorised records and relationships before producing the answer. Check summaries and exports too.
Keep origin, validity and collection dates separate. An imported record can be recent while its underlying agreement is old. In our current build, Said describes lower confidence when information is not seen again by its validity date, with human decisions resolving important uncertainty.
An AI layer does not choose the right structure for you. It can retrieve material from a knowledge base, query graph relationships or use both. Evaluate the sources selected and the resulting answer in each design.
Include the cost of keeping relationships correct
Estimate how often the links change and who can approve them. Duplicate clients, inconsistent names and unowned relationships will create problems whatever graph software you choose.
Start with a narrow question, a few connected records and a known expected answer. Include a missing link and an outdated agreement. If the graph adds little useful information or makes ownership harder, simplify the design.
Worked example
Choosing a first reporting structure
Invented teaching example. No client outcome is claimed.
NEED
One account team must find the current reporting agreement and its owner.
FIRST DESIGN
A maintained client page with links can answer the chosen questions.
REASON TO RECONSIDER
The team later needs to find every task affected by agreements expiring across many clients.
TEST
Compare an explicit relationship query with a maintained index using the same approved sample records.
Neither design is assumed to be faster or more accurate in advance.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.