Your AI roadmap rests on one arrow.It is the only part of the slide nobody has specified.

01 · The arrow

The arrow doing all the work

Start with what is going right, because it is real. A model is only as good as the data underneath it, and plant data in its native state is not that data yet. Think about a tag named FIC_1042A_PV, a timestamp from a clock nobody synchronised, and an asset hierarchy that lives in the head of whoever commissioned the site. Somebody has to attach the units, resolve the asset identity, normalise the naming across sites built a decade apart, and keep all of it current instead of exporting it once. That is real engineering, and I would far rather work with a category that does it deliberately than one that assumes a model will infer it.

Now look at the bottom of the same slide. The layers above the boundary get the whole diagram, and the arrow that crosses it gets a label saying secure connection, or sometimes nothing more than a padlock. That arrow is the load-bearing element on the slide, and it is the only one left unspecified. It does not tell you which side holds the listening socket, or whether that inverts during failover, commissioning or remote support. It does not tell you what identity crosses the boundary. And it does not tell you what happens to the readings when the link is down for six hours.

Those are not details you can settle later, because everything above them inherits whatever answer they turn out to have. A catalog cannot un-forward a port, and lineage will not tell you which side dialled. If that arrow turns out to be a forwarded port pointing at a historian, the governed surface above it is standing on a permanent inbound rule that nobody will remember approving three years from now. I am not calling that a defect in the readiness layer, because it is simply a question that layer does not ask. The arrow is the load-bearing part of the whole picture, and everything above it inherits whatever it turns out to be.

02 · Which side opens

Which side opens the connection?

So what would you actually decide at that crossing? The property I would design for is the direction of initiation, which simply means which side opens the connection. What makes it matter is not so much how each arrangement behaves under attack as how it behaves under a mistake.

An inbound listener that is wrongly reachable produces no symptom at all. The plant keeps running, the data keeps flowing, the ticket gets closed, and the error is visible only from outside. Make the equivalent mistake on a path the plant opens outward and the connection simply does not establish. Data stops arriving, a buffer fills, somebody notices a gap in a trend, and the reason for it is sitting in a log. The first kind of mistake fails open and quietly, and the second fails closed and loudly.

I have written the full argument out in What can reach your control layer? That note goes through what the property does not buy you, and where it relocates the trust decision rather than removing it. Ask which side opens the connection, because that one answer decides whether your next mistake announces itself or hides.

03 · The ceiling

The answer is only as good as the path

Here is why this lands on you rather than on whoever owns the platform. Governance is the word carrying the most weight in this category, and nearly all of it gets applied above the boundary. It covers who may query which pipeline, what lineage a reading carries inside the platform, and which policy was applied to which request. All of that is useful, and it begins in the middle of the story.

The data an agent consumes is only as governed as the path it took to arrive, and that path sets the ceiling in three ways. An identity that sits in a configuration file outlives the person who set it, and a lineage graph can record who read a number and still have no idea who moved it. A record of what moved and of what changed in the configuration is only worth having if you can export it into your own tooling. And a path that quietly drops readings during an outage hands the layer above it a gap that is indistinguishable from a quiet shift, so an agent asked whether a pump ran overnight can only answer from the readings that arrived.

So there are three questions worth asking before anybody books the demo. None of them is about the model, and you can answer all three from a firewall ruleset, a directory and a log.

• Which side opens the connection, which host holds the listening socket, and does either of those flip during failover, commissioning or remote support?

• Does the identity crossing the boundary bind to the directory you already administer, and who can revoke it on a Friday afternoon once the person who built the path has left?

• What durable record exists of what moved and of who changed the configuration, and can you read that record in your own tooling rather than inside somebody else’s platform?

None of that makes the modelling and cataloging redundant. What it does is set what that work inherits. What you get out of the AI layer is capped by the path your readings arrived on, so ask about the path before you watch the demo.

04 · How we help

How can we help?

Where a purchase actually helps here is at the crossing itself. The outcome to ask for is a boundary you can describe in one sentence to whoever audits you, and a layer above it that stays a choice you can change your mind about later.

Flowgate is where we built that crossing. Relay nodes inside the plant open every connection outward to the node above them, so the plant side of the path carries no inbound rule. Readings buffer where they were captured while a link is down, which turns an outage into late data instead of a gap the layer above cannot tell from a quiet shift. Sign-in binds to the Active Directory you already run rather than to another shared password, and every change lands in a timestamped, hash-chained record. It publishes in the open forms the layer above already consumes, which are MQTT and Sparkplug B.

I want to be plain about what kind of claim that is. It describes how the parts are put together, not what they withstand, and nothing here prevents an intrusion, detects one, or has been rated or certified against anything. Flowgate’s part of the job is the crossing and nothing above it. It exposes no tools for an agent to call and it is not a query interface for a model, so it is the feed into the layer that does those things, and that layer is not ours.

None of this replaces the readiness work either. A well-arranged path carrying badly named tags will deliver badly named tags, on time, and a site that has skipped the modelling and cataloging will not get further by arranging its boundary well. Both jobs have to be done, and one of them has to be done first.

What happens above that stream is your choice of layer, whether that means models, agents, analytics, or a platform you bought two years ago. That is what keeps the layer above it somebody else’s decision, and it can be anybody’s.

05 · Sources

Sources

• CISA, alert: protect operational technology against activity targeting PLCs in water and wastewater systems, 2026-07-30
• ARC Advisory Group, how MCP complements OPC UA in industrial AI