You set the requirements and make the decisions. Calculations, documentation and inter-discipline assignments come out of the model and update themselves with every change.
R2O is a way to run a project from the spec to operation in one model. The engineer sets the requirements and makes the decisions, while calculations, documentation and inter-discipline assignments come out of the model. When something changes, the system recalculates everything that depends on it and shows what is out of date.
Change it once — everything follows.
A project starts not with a drawing but with what the result has to be: room purposes, loads, codes, budget. Codes are part of the model: each rule finds what it applies to, and every rule links to the clause of the code it comes from.
The result is not a set of documents but a working facility. The model yields manufacturing and purchasing orders, data for installation and commissioning, and, after handover, a facility passport for the operations team.
All disciplines and all stages work with the same data. Nothing is moved by hand from one program to another or retyped from one spreadsheet to another.
The model knows what depends on what. Change the input data and everything dependent is recalculated; whatever cannot be recalculated without an engineer is marked as out of date.
In CAD, a person draws lines. In BIM, a person models objects, and the system derives views and schedules. In R2O, a person sets requirements and decisions, and everything else is derived from them.
Today the path from spec to facility runs through different programs and different people. Data is moved between them by hand, and at every hand-off something gets lost or goes out of date.
The model knows what depends on what. Below are three example chains — the approach is not tied to one discipline or process.
One change runs through the whole chain. What can be recalculated is recalculated; the rest is marked.
The model yields more than a drawing: the equipment gets signals, the signals give a control diagram, a program and a product breakdown for manufacturing. The program can be tested on the model before anyone goes to site.
Measurements and decisions from installation and commissioning return to the model. The operations team gets the facility as it is, not as it was drawn.
The system does not design instead of the engineer. It takes on calculations, formatting and cross-checking, while decisions and signatures stay with a person.
The system assembles whatever follows standard solutions and proven rules.
Generators and AI propose an option. It goes through the checks, and an engineer accepts it through an approval route, like a document.
Functions that people's safety depends on are built only from tested templates.
Responsibility for the project stays with the engineer. Every value records who set it and why.
Every part of the approach has long been in use in mechanical engineering, aviation, industrial automation and IT. What is new is putting them together in one model for all construction disciplines.
design rules are written down so that the system can execute them
requirements are elements of the model, not text next to it
one connected chain of data from concept to operation
the control program is tested on the model before going to site
a change in the input data rebuilds everything dependent, like a program after an edit
The approach is built into ProMatrix Engineering, an object-based design system for all disciplines: architecture, heating and ventilation, automation, water supply, electrical, low-voltage systems, and later structures, site planning and surveying. The module is in development, and we show it as it is — stage by stage.
The first milestone is under way — “Drafting architecture and HVAC with objects”: architecture, ventilation and heating already work in the model. Next comes a pilot on a real project alongside AutoCAD. We invite design firms to become pilot customers.
ProMatrix Engineering is part of the ProMatrix ecosystem: document management, tasks, comments, cost estimates, procurement and installation all work on the same data. So the model does not stop at project issue.
Tell us where the chain breaks for you today — between disciplines, on changes, or after the project is issued. We'll walk through it on your example.
We reply during business hours. If it's urgent, Telegram is the fastest way.
