01
Find the real cost
Identify which manual step actually consumes the time. It is frequently not the one the team nominates.
BIM and design automation services
Automation is scoped, priced and delivered here as a service category in its own right — not as a paragraph at the end of a modelling proposal.
Automation
The engineering position
Checking should not scale with headcount
Doubling the model doubles the checking. The conventional lever is more people, and more people checking by hand produces less consistency rather than more — every reviewer has a slightly different threshold and none of them write it down. A rule set has exactly one threshold, it is written down, and the eleventh run costs the same as the first. That is the entire economic argument, and it only works if the model was authored to be read.
The value is in the rules, not the script
Anyone can write a Dynamo graph. The difficult part is knowing what a competent engineer actually checks and at what threshold — which requires people who have sized the systems the rules govern. An automation practice without discipline depth produces confident nonsense at scale, and there is a great deal of it in this sector right now.
Automation drafts; engineers decide
No routine we deliver writes to a live model, closes an issue, changes a status code or issues a deliverable. It reads, tests and drafts, and a named engineer accepts, amends or rejects. This is a design constraint we do not intend to remove, because engineering liability does not automate.
Deliverables
What is actually produced and issued
Any of these can be appointed on their own or combined. Nothing here depends on buying the intelligence layer, which is not for sale in any case.
DeliverableAutomated QA rule sets
The project standards pass — parameter validation, naming, family audit, system integrity — run as a rule set with an element ID against every finding.
DeliverableQuantity extraction routines
Quantities measured from geometry and parameters, classified, with the measurement rule visible per line and traceable back to elements.
DeliverableDocumentation pipelines
Sheets, views and schedules derived from model state, so a model change and a drawing change are one event.
DeliverableParameter and data management
Bulk population, correction and migration of model data, run as documented routines.
DeliverableModel health and audit reporting
Scheduled reporting on warnings, naming compliance, parameter completeness and file health.
DeliverableData export and integration
Structured exports to the formats your downstream systems actually consume.
How it runs
The sequence, and why it is in this order
Sequence is not a formality on this kind of work. Most of the expensive rework we are asked to fix was produced by doing step four before step two.
02
Write the rule down
Turn the check into an explicit, reviewable threshold. This step produces most of the value even before anything is automated.
03
Build and calibrate
Develop the routine and run it against known-good and known-bad models to establish its false-positive rate.
04
State the false-positive rate
A checker with an unstated false-positive rate cannot be evaluated. We measure it and publish it to you.
05
Design the review point
Decide explicitly where the engineer reviews and what they are reviewing. Automation without a designed handover point is just faster error production.
06
Handover
Routine, documentation and the rule set, so your team can run and amend it.
What we need to start
The inputs that decide whether a start is a real start
Missing any of these is survivable. Not knowing which of them are missing is not, so we establish it at enquiry stage rather than at forty per cent.
- A model, or a representative sample of the models the routine has to run against
- The check you currently perform by hand, described as you currently describe it
- The threshold or standard the check applies — or a session to write it down
- The format the output has to arrive in
- Who reviews the output, so the handover point is designed rather than assumed
Automation
Where automation applies to this work
Every line carries its real status. Three of the four states on this site mean "not yet", and we use them.
AutomationModel QALive
The standards pass before every issue, run as a rule set instead of a person opening views one at a time, with failures clustered by cause.
AutomationClash intelligenceLive
Findings classified by cause and responsible discipline rather than counted.
AutomationEngineering calculations from model dataLive
Sizing and load calculation driven from model parameters and reconciled against the as-modelled network.
AutomationDocumentationLive
Draft sheets and schedules derived from model state for engineering review.
AutomationQuantity intelligenceLive
Measured from geometry, classified, every line traceable.
AutomationDesign automationIn development
Generating model content from engineering intent and rules — routing, supports, penetrations, repeated typologies. In development and used on our own delivery; not offered as a product.
Scope boundary
What this appointment does not include
Published because a scope boundary discovered at month three is a dispute, and the same boundary stated at enquiry stage is just information.
- We do not deliver a routine without stating its false-positive rate.
- We do not build automation that commits changes to a live model unattended.
- We do not automate a workflow where the honest answer is that it is not worth automating — we will say so, and that has cost us work.
- We do not licence the internal intelligence layer. Routines built on your appointment are yours; the platform is not a product.
FAQ
Questions we are asked at enquiry stage
What can realistically be automated on a BIM project today?
Model QA, clash classification, quantity extraction, documentation generation, parameter management and calculation reconciliation are live and running on client appointments now. Generative design content is in development and used internally. Anything further is roadmap and labelled as such on this site.
How do you price an automation engagement?
Against the defined workflow and its deliverable — the rule set, the routine, the documentation and the engineering behind it. Not as a licence, because there is no product to licence.
What is a false-positive rate and why do you publish it?
It is the proportion of findings a checking routine raises that turn out on review to be wrong. Every rule set has one. A provider who does not state theirs is asking you to trust a checker you cannot evaluate, and we think that is the wrong way round.
Does automation replace engineers?
It replaces the part of an engineer's day spent doing something a rule could do more consistently. The engineering judgement about what to check, at what threshold, and what a finding means is the part that is not automatable — and it is also the part that carries the liability.
Will you tell us if a workflow is not worth automating?
Yes, and we do. A routine that takes four weeks to build and saves two hours a month is a bad trade, and saying so is cheaper for both parties than discovering it afterwards.
Related
Where this connects
AI and automationThe agents, the workflows and where the engineer signs.
MCP for RevitWhat connecting an AI assistant to a model would require, and what it would not do.
BIM coordinationWhere clash intelligence is applied on live appointments.
Capability statusThe four-state legend behind every badge on this page.