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.
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.
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.
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.
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:
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.
A reasonable workflow looks like this:
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.
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.