Architecture
How it is put together
Enough detail to judge whether this is real. The deeper walkthrough, component maps, data-flow diagrams, the parts we are still building, is behind a preview link we are happy to hand out.
Shape of the system
Cloud-first, and built to stay up
Powoflow is a lot of small independent parts rather than one big program. They scale on their own, they are replaced one at a time without downtime, and a fault in one stays inside that one instead of taking the system with it.
A record store and a graph
Your records live in one store and your relationships live in a graph, because they answer different questions. “What is this pump’s service history” and “what else goes down if this breaker opens” are not the same query, and pretending they are is why most systems answer the second one badly.
The two never drift apart
A change that affects both the record and the graph is committed as one thing, then applied to the graph from that commitment. If the second step is delayed it still happens; it cannot be skipped. So the graph is never quietly out of step with the records it describes. A failure mode that is easy to create and very hard to notice.
Events, not polling
Nothing sits in a loop asking “has anything changed yet?”. A reading arrives, and everything that cares about it is told. The alarm check, the stored history, the screen someone is watching. A value changing on a Field Agent reaches a browser without anyone refreshing.
Field Agents survive the link
Field Agents keep their own history and do their own analysis on site, then reconcile when the link returns. The cloud is where everything is brought together and kept. It is not something the site needs in order to keep working.
Never inside a control loop
Powoflow reads, correlates and presents. It does not actuate safety functions and does not sit between a controller and a process. That is a deliberate boundary, and it is why it can be added to a plant without re-qualifying one.
Measured, not estimated
The route figure is 493 customer endpoints plus 118 administrative ones, counted from what is actually served rather than from the specification. The specification documents fewer than exist, which is a defect on our side and not a reason to quote the smaller number.
Go deeper
The technical preview
Component-level diagrams, the edge deployment map, the data model, and an explicit list of what is not built yet. It is behind a password because the roadmap section is candid enough that we would rather hand it over in a conversation than leave it open to competitors.
Ask for the preview linkBring your architect
The questions we most want are the awkward ones, consistency, failure modes, what happens when a region goes away.