The beta opened today, and the standard library opened with it: 22 typed device types across 3 libraries — pumps and drives, IO and controllers, materials handling — each one a single definition carrying its tags — with states, alarms, commands, a UI faceplate, and a closed-loop simulation profile where the equipment calls for them. All of it distilled from production control code, not modelled from datasheets.
This post is about what comes after those three.
A vertical is additive
The reason we can talk about new verticals with a straight face is structural. A device type is data — a typed definition the whole platform resolves against. The faceplate renders from it, the simulation runs from it, the alarms and commands derive from it, and the PLC code generation reads it. Adding a vertical means authoring a new set of definitions, instance templates, and conformance vectors. It does not mean new platform features, new renderers, or new engines.
The 22 types shipping today are the existence proof: three libraries already share one device model, one faceplate system, one simulation runtime. A clarifier, a compressor, and a computer-room air handler are — to the platform — the same kind of thing: tags, states, alarms, commands, a faceplate, a sim profile.
The three we’re building toward
Water utilities. A full water and wastewater control device library: lift and pump stations, clarifiers and thickeners, chemical dosing, aeration blowers, filtration and backwash. Water is the closest to home — the platform’s first end-to-end proving ground was a dam pump station, and pumping is where the shipped library is already deepest.
Gas. Gas processing and distribution control: compressor stations, metering and regulating runs, odorization, pipeline valve stations. Equipment where the interlock story matters most — which is exactly what the typed device model is for: the interlocks are explicit in the definition, not folklore in a vendor project file.
Data centre. The mechanical and electrical plant behind the racks: CRAC and CRAH units, chilled-water plant, UPS and generator sets, PDUs and switchboards. A data centre is heavy industry that happens to contain servers, and it deserves the same control discipline as a wash plant.
Planned means planned
You will notice there are no dates in this post, and no dates on the library page either. That is deliberate, and it is the same rule we applied everywhere else on this site: when something is bench-proven rather than field-proven we say so, and when something is planned rather than built we say that too. Each vertical ships when its definitions are distilled and its conformance vectors pass — you will see it appear in the catalogue, not in a press release.
The sequence is the honest commitment, and you get a say in it. The order we build these — and the device families we start with inside each — will follow what beta users actually ask for. Family lists above are our starting candidates, not a locked scope.
Tell us what your plant needs first
If you run water, gas, or data-centre infrastructure — or something we haven’t listed — the beta is open and the conversation is too. Tell us which device families would have to exist before the library is useful to you; that is precisely the input that decides what gets built next. And if you’re at QME this week: Stand C820, bring the question in person.
One caveat we will keep repeating while the beta label is on: the beta is for evaluation, authoring and simulation, and supervised commissioning trials alongside your existing control systems — not for production control of live plant. The roadmap above is about making the library ready for your vertical; taking the beta label off is about making the platform ready for your production. Both happen in the open.