Static diagrams work fine when a system is small, stable, and owned by the people who drew it. As soon as those three conditions change, and they always do, the diagram and the system start diverging. The diagram does not get worse all at once. It gets worse one valve, one re-piped line, one retired operator at a time.
The first crack is usually accuracy. A new sensor goes in, a valve gets re-piped, a downstream consumer migrates to a different feed. None of these changes feel big enough to justify opening the diagram, exporting a fresh image, and re-circulating it. But the changes accumulate. Within a year or two, the diagram in the runbook is documenting a system that does not exist anymore, and nobody knows exactly which parts are still right.
Plenty of tools overlay live values on top of a diagram, and that helps. But those overlays are decoration: the diagram does not actually know that this pump feeds the downstream tank, or that this valve sits between two units, or that pressure dropping here and flow rising there are part of the same upset.
The numbers update on the picture, but the picture has no understanding of what those numbers mean relative to each other. Operators read the values from the diagram and the relationships from memory, or from a separate dashboard that knows the values but not the system underneath them.
The third crack is ownership. The original author moves teams, leaves the company, or forgets what their own shorthand meant. Anyone who tries to update the diagram has to reverse-engineer the symbols or risk introducing inconsistencies that other people then quietly ignore. Over enough time, the diagram becomes something everyone references when onboarding and nobody trusts when something is on fire.
These are not problems with diagramming software, or with showing live data on top of a drawing. They are problems with treating the diagram as a deliverable, a picture that happens to display values, instead of as a model of the system. A diagram that knows its own underlying structure, the data items behind each node, the dependencies between steps, the typical operating ranges, does not have to be redrawn when the world changes, and the values it shows mean something because the structure underneath them is real.
Once that structure is machine-readable, the diagram stops being a better drawing. It becomes context something can act on: an engineering agent can read the graph, trace what feeds a unit, pull the relevant history, and reason about where an upset started, because the relationships are data, not a layout. That is the premise Streamsight is built around, and why the diagram is the model itself rather than a separate source of truth the model points at.
Operational context rarely disappears in a single event. It dissipates across diagrams, dashboards, tickets, and the memory of a few key people. How it leaks, and what to do about the shape of where it lives.