What Your Software Lets You Automate Decides Who Benefits From AI

1. A question nobody asks during procurement

Software in this industry is bought on features. Does it model the geometry, produce the schedules, handle the takeoffs, connect to the estimating package. Those questions get asked carefully, and they are the wrong ones to ask first.

The question that determines what a firm will be able to do three years later is narrower and almost never appears in an evaluation matrix: how far into this system am I allowed to reach? Not what the software does today, but which parts of it I can change when my work stops matching the assumptions the vendor made.

That question has become urgent because of what changed on the other side. A firm with programmatic access to its own systems can now describe an automation in plain language and have working code produced in minutes. The bottleneck used to be the cost of the developer. Increasingly the bottleneck is whether the system will let a developer, human or otherwise, in at all.

2. Five layers, and where the door closes

It is more useful to think about openness as a set of layers than as a property a product either has or lacks. Every system in this industry is open at some layers and closed at others, and the position of that line is what matters.

Two clarifications, because this is where the argument is usually made badly.

Proprietary does not mean sealed. Autodesk Revit ships a documented .NET API, a visual programming environment in Dynamo, an active Python ecosystem in pyRevit, and IFC export as an open exchange format. A great deal can be automated inside Revit, and a language model can write that automation. Anyone who claims otherwise has not used it.

Open source does not mean unlimited. Modifying the core engine of a large open system is possible in principle and unwise in practice, because it breaks the upgrade path. The practical benefit of open source sits in the two middle layers, not at the bottom.

So the real distinction is narrower than the usual debate, and sharper. In a proprietary system you can automate operations on the data model. In an open one you can change the data model itself: what an object is, which attributes it carries, which role may see which record, and what the system does when a value changes.

3. What that difference looks like in practice

An example from outside construction makes the point cleanly, because the constraint is the same and the evidence is concrete.

In a commercial real estate operation running on an open source enterprise resource planning system, adapting the software to the operation meant adding three hundred and twenty one custom fields across twenty eight entities, defining nine new data models, and writing four security groups, fourteen access control lists and three record-level rules that determine which user sees which contract. It also meant setting accounting period locks so that no user, including the person who configured them, can alter an entry from a closed period.

None of that is exotic engineering. It is the ordinary work of making a general system fit a specific operation. The relevant fact is that it was possible at all, and that once the schema was open, describing the next change in plain language and having it implemented became a matter of hours.

Now consider the same intent inside a modelling platform whose schema is fixed. You can write an add-in that renames parameters, checks a model against a rule set, exports a schedule, or pushes data to another system. What you cannot do is decide that in your practice a wall carries a warranty obligation and a responsible party, and have the software treat that as a first-class property of the object with its own permissions and its own audit trail. You can approximate it with shared parameters and discipline. You are approximating, and the approximation is what degrades at handover.

4. Why this is a distribution problem

Here is where the technical distinction turns into an economic one.

A large firm can work at any layer regardless of licensing. It funds a dedicated technology group, buys enterprise agreements, commissions custom development against proprietary APIs, and negotiates with vendors from a position where its requirements reach the product roadmap. Closed layers are a cost, not a barrier.

A firm of fifteen people cannot. It has no technology group and no leverage with a vendor. What it does have, for the first time, is the ability to produce working automation from a description of the problem. That new capability is real, and it is bounded exactly by how deep the software lets it reach. Where the system is open, a small firm can now do things that used to require a team. Where the system is closed above the schema, it is left with whatever the vendor decided to expose.

The result is uncomfortable and worth stating plainly: a technology promoted as a democratiser of productivity can concentrate it further, because access to the layer where adaptation happens is distributed the same way capital already is.

This matters for construction specifically because the industry's productivity problem is not located in its large firms. It is located across a long tail of small and mid-sized contractors, designers and specialty trades that perform most of the work. A capability that reaches only firms with a technology budget will not move the aggregate number, and the aggregate number has not moved in half a century.

5. The governance question underneath

There is a second consequence, and it belongs to risk rather than economics.

If a system is open enough that automation can alter its schema, its logic and its access rules, then automation can alter the governance of the project's information. A model can add a field, change who is permitted to see a record, or rewrite the condition under which an invoice is generated. That is precisely the capability that makes open systems valuable, and it is also an unattended risk.

Four questions follow, and they are the same ones a project team should be asking about any autonomous system operating on its information:

1. Which layers may automated changes reach, and which are declared off limits?
2. Who reviews and authorises a change to the schema or to an access rule before it takes effect?
3. What record survives showing what was changed, by whom or by what, and when?
4. Which states are frozen, so that no actor of any kind can alter them afterwards?

ISO 19650 already requires that approved information containers become fixed revisions rather than editable working files. That requirement was written with human carelessness in mind. It reads differently, and more urgently, once the thing that might overwrite an approved container is a process nobody watched run.

6. Questions to ask before buying

For a firm evaluating software, the following are worth more than a feature comparison. None requires technical expertise to ask.

1. Can we add attributes to your core objects, and do those attributes survive an upgrade?
2. Can we define who sees which individual record, or only who sees which type of record?
3. If we leave, in what format does our data leave with us, and what is lost in the translation?
4. What can be automated through your API without a commercial negotiation, and what cannot?
5. Can we lock a period, a revision or a state so that it cannot subsequently be altered by anyone, including an administrator?
6. If we build something on your platform, who owns it?

The answers rarely appear in the sales material. They determine what the firm will be able to do with the tool in five years, and how much of that will depend on the vendor's roadmap rather than its own.

7. What this does not claim

It does not claim that open source software is better. Proprietary modelling platforms in this industry are mature, well supported and hard to replace, and their ecosystems solve real problems that no open alternative currently solves. Nothing here argues for replacing them.

It does not predict that an open equivalent will appear. It observes that the layer at which a system closes is now a more consequential procurement decision than it was, because the cost of writing automation has collapsed while the cost of being denied access has not.

And it does not treat this as a purely technical matter. Which layers are open, who owns what is built on them, and who is accountable when an automated change goes wrong are contractual questions. They are settled, or left unsettled, in the licence and in the appointment.

References

• ISO 19650-1:2018 and ISO 19650-2:2018, Organization and digitization of information about buildings and civil engineering works, including building information modelling.
• Autodesk, Revit API developer documentation; Dynamo; the pyRevit project.
• buildingSMART, Industry Foundation Classes (IFC) specification.
• Odoo S.A., developer documentation on model inheritance, access control lists and record rules.
• McKinsey Global Institute, Reinventing Construction: A Route to Higher Productivity (February 2017), on sector productivity and the seven action areas.
• National Institute of Standards and Technology, GCR 04-867, Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry (2004).