Knowledge graphs and LLMs: where simulation fits

Pairing a large language model (LLM) with a knowledge graph is now a standard way to make its answers more reliable: the graph supplies facts, and the model puts them into words. This article is about the question that comes next. A knowledge graph can tell a model what is connected to what, but it cannot tell it what will happen when something changes. That job belongs to a simulation, and the two kinds of graph fit together better than the shared word suggests.

What a knowledge graph gives an LLM

A knowledge graph stores facts as nodes and relations: Port A supplies Warehouse B, Warehouse B stocks Bread, Bread is a Perishable. An LLM that can look things up in it has something firmer to stand on than its training data. It can answer "which warehouses depend on Port A?" with a traversal instead of a guess, and it can cite where the answer came from.

That is the strength of the approach: a knowledge graph records what is true. Questions about membership, ownership, dependency and category all have answers you can look up and check.

What it cannot give

Now ask a different question: if Port A closes for nine days, when do the shelves empty?

The knowledge graph knows Port A supplies Warehouse B. It does not know how fast Warehouse B drains, how much stock it holds or how long a delivery takes. Those are quantities that change over time and push on each other, and a fact store has no way to step them forward. An LLM asked this question from the graph alone will produce a fluent paragraph with numbers it made up.

The other kind of graph

A simulation graph has the same shape with different contents. Each node carries state (a stock level, a temperature, a balance). Each edge is a relationship that says how one node's state changes another's. An engine steps the whole structure through time and reports the trajectory.

	Knowledge graph	Simulation graph
A node is	An entity	A component with state
An edge is	A stated fact	An equation or rule
You ask	What is connected, and how?	What happens next, and when?
The answer is	Looked up	Computed
You check it by	Tracing it to a source	Running it and reading the results

Neither replaces the other. A fact says Port A supplies Warehouse B. A relationship says how many tonnes per day, and what happens to the stock when that stops.

Where the LLM helps with simulation

Building a simulation graph by hand takes work, and that is a good job for a model. Konjugate's model assistant lets you describe a change in plain language, such as adding an ambient boundary at 298 K connected to a battery. It then proposes the nodes, states, relationships and equations you would otherwise author yourself.

What matters is the division of labour:

• The model drafts. It turns a description into candidate structure.
• A validator checks. The proposal goes through the same native validator as any hand-built model, and a malformed one is rejected rather than applied.
• You review. The proposal is split into individual steps with a visible diff, and it states the assumptions it made.
• The engine computes. The numbers in the results come from running the equations, not from the model's recollection.

That last point is the answer to the made-up paragraph above. The LLM never has to guess how fast a warehouse drains. It helps write the relationship, and the engine runs it.

A caution that applies today: the assistant works well with a strong hosted model, and small local models still ask too many questions or guess at ambiguous requests. You review every proposal either way.

Putting the two together

A reasonable workflow looks like this:

1. Facts first. A knowledge graph, or any structured source, tells you which components exist and what connects them.
2. Structure to model. That structure becomes the skeleton of a simulation graph. The nodes and edges carry over, and each edge gains an equation.
3. Draft with an LLM. Describe the missing relationships and review what the assistant proposes.
4. Run and ask. Simulate, change one edge and run again to answer the "what if" question.
5. Learn from data. Where you have measurements, recover the causal links from the data instead of assuming them.

Konjugate does not import a knowledge graph today, so step two is manual. The closest thing it has is in the logistics toolbox, which turns a region's OpenStreetMap data into a runnable network of roads and places. That is the same idea from a different source: existing structured data becomes the skeleton of a model you can simulate.

The bottom line

A knowledge graph tells a model what is true. A simulation tells it what will happen. An LLM is useful on both sides, as a reader of the facts and as a drafter of the model, but the answer to a "what if" question should come from running the model, not from the LLM.