{"slug": "knowledge-graphs-and-llms-where-simulation-fits", "title": "Knowledge graphs and LLMs: where simulation fits", "summary": "Konjugate's model assistant lets users describe a change in plain language — such as adding an ambient boundary at 298 K connected to a battery — and proposes the nodes, states, relationships and equations for a simulation graph, according to the company. The article argues that knowledge graphs record what is true while simulation graphs compute what happens next, so an LLM should draft the model and the engine should run it rather than the model inventing figures such as how fast a warehouse drains. Konjugate does not import a knowledge graph today, making that step manual; its logistics toolbox instead converts a region's OpenStreetMap data into a runnable network of roads and places.", "body_md": "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.\n\nA 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.\n\nThat 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.\n\nNow ask a different question: *if Port A closes for nine days, when do the shelves empty?*\n\nThe 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.\n\nA 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.\n\n|  | Knowledge graph | Simulation graph | \n|---|---|---|\n| A node is | An entity | A component with state | \n| An edge is | A stated fact | An equation or rule | \n| You ask | What is connected, and how? | What happens next, and when? | \n| The answer is | Looked up | Computed | \n| You check it by | Tracing it to a source | Running it and reading the results | \n\nNeither 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.\n\nBuilding a simulation graph by hand takes work, and that is a good job for a model. Konjugate's [model assistant](https://www.konjugate.com/2026/08/the-model-assistant.html) 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.\n\nWhat matters is the division of labour:\n\nThat 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.\n\nA 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.\n\nA reasonable workflow looks like this:\n\nKonjugate 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.\n\nA 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.", "url": "https://wpnews.pro/news/knowledge-graphs-and-llms-where-simulation-fits", "canonical_source": "https://www.konjugate.com/2026/10/knowledge-graphs-and-llms-where.html", "published_at": "2026-10-29 04:06:12+00:00", "updated_at": "2026-10-29 04:11:55.109196+00:00", "lang": "en", "topics": ["large-language-models", "artificial-intelligence", "ai-tools"], "entities": ["Konjugate", "OpenStreetMap"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/knowledge-graphs-and-llms-where-simulation-fits", "markdown": "https://wpnews.pro/news/knowledge-graphs-and-llms-where-simulation-fits.md", "text": "https://wpnews.pro/news/knowledge-graphs-and-llms-where-simulation-fits.txt", "jsonld": "https://wpnews.pro/news/knowledge-graphs-and-llms-where-simulation-fits.jsonld"}}