A design change starts as a one-line edit, but it never ends there. Change a single material name in the finishes schedule and the substrate, the thickness, the details, the quantities, the unit rates, the lead times, the schedule and the quality inspections all move with it. Yet most projects are far more exposed on finding and communicating those consequences than on making the change itself. Engineering Change Intelligence addresses exactly that gap.
The Day One Line in the Finishes Schedule Changed
Suppose the wall finish in a guest room changes from water-based paint to large-format porcelain tile. In terms of design intent this looks like a trivial change. Swap the material code in the finishes schedule, refresh the renderings and the sample board, and it appears to be done. From a construction standpoint it is an entirely different scope of work.
The flatness and plumb of the concrete substrate have to be re-verified, and plaster or board correction may be required. As the combined thickness of tile and adhesive grows, the door frame and skirting details, the projection of outlet boxes and the clearances to joinery all shift. Areas and waste factors change, and so do material lead times, mock-up approval, labour productivity, curing and the sequence of the following trades.
What Engineering Change Intelligence Is
Change management systems typically record approval requests and document revisions. The actual engineering impact, however, is usually left to people to uncover through meetings and checklists. Change Intelligence starts from the changed object and property, then follows the relationship graph and the calculation dependencies to propose what has to be re-examined.
The point is not automatic correction. The first question is “what changed,” the second is “which objects and calculations are affected,” and the third is “who has to check them, and in what order.” The system presents candidate impacts with their evidence, risk level and recalculated results, and the responsible engineer confirms the final scope.
Separate Impact Into Three Layers
Not every impact is of the same kind. The first is direct impact: a section dimension or a material changes, and the linked calculations and drawings change with it immediately. The second is derived impact — the downstream movement in quantities, cost and schedule that follows from those calculation results. The third is procedural impact: the items that require re-approval, such as the class society, the supervisor, the client, samples and mock-ups.
Separating these three layers makes priorities obvious. Direct impact can be confirmed quickly through automatic recalculation; derived impact has to be read together with the contract and the state of the site; procedural impact has to be managed against document issue and approval lead times. Telling the reviewer what kind of action is required is far more useful than reporting “12 affected documents.”
Document-Centric Change List
Change Package With Separated Impact Layers
Case 1: A Change in Groundwater Level
A change in the design groundwater level is a case with wide cross-trade impact. The direct impact falls on earth and water pressure against the retaining system, uplift, foundation bearing capacity and liquefaction calculations. The derived impact reaches cut-off wall depth, dewatering pump capacity, rebar and concrete quantities, and the earthworks and temporary works schedule. The procedural impact is the re-review by the geotechnical and structural designers, the supervisor and the client, and the reissue of the reports.
The system locates the zones where the groundwater object applies and the calculation sheets linked to them, then runs a sandbox calculation with the input cell replaced by the new value. Where the difference in results falls outside the allowable range, the item is flagged as high risk, and the water level annotation on the related drawings and the body text of the reports are compared as well. The value of this automation should be judged by how many missed connections it eliminated, not by how much calculation time it saved.
Case 2: A Change in Structural Beam Section
Suppose the depth of beam B3-214 is reduced from 700 millimetres to 650 millimetres. The direct impact is the review of flexure, shear, deflection, rebar development and fire protection. The derived impact covers concrete and rebar quantities, ceiling height and the space available for services to pass, formwork and buildability. The procedural impact is the structural drawing revision, coordination with the services engineer, the supervisor's review and closing out the site RFI.
If the BIM object, the analysis element, the calculation sheet cell and the detail drawing number are linked, the system can find the related items quickly. What it must not do is jump automatically to the simple conclusion that “a smaller section means less quantity.” Additional rebar or strengthening, MEP rerouting and schedule delay can raise the total cost instead. Change Intelligence does not decide the conclusion in advance; it opens the required calculations and judgments in the right order.
Case 3: A Change in Finish Material
In finishes, the gap between BIM geometry and real installed quantity has to be handled directly. The net area for a tile change can be taken from the model, but pattern, cutting, corners, breakage and minimum order quantity all change the purchased quantity. Add substrate correction and both the plastering quantity and the number of working days increase. If the product lead time is 10 weeks, a delay in design approval becomes a risk to the whole schedule.
Impact analysis therefore needs state and time as well as technical relationships. Before the order is placed the cost of a change is small; once the material is in production or already delivered to site, scrap and rework follow. The same design change carries a different impact depending on the Effective Date and the state of the site.
What a Reviewer Must See on One Screen
A change screen must not be a complicated network graph and nothing else. The reviewer first needs the key values before and after, the reason for the change and who requested it. Next, the direct, derived and procedural impacts must be laid out together with their risk levels. Every item must open into the supporting drawing, the calculation sheet and the sandbox result.
An “approve all” button should also not be offered lightly. Each trade owner must confirm their own scope, and while conflicting opinions or unresolved items remain, the commit to the official baseline must be blocked. Automation is not about reducing clicks; it is about making judgment happen in the right order with nothing left out.
If this change is approved, what is still outstanding?
Measure Performance by Omissions and Waiting Time, Not by Automatic Edits
It is dangerous to measure Change Intelligence solely by the number of files it edited automatically. The metrics that matter more are the rate of missed impacts, the time from detecting a change to assigning an owner, the recalculation and review lead time, the number of times a wrong version was used, and the reduction in site RFIs and rework.
The share of proposed impacts that proved genuinely valid, and the impact items people found on top of them, should also be collected continuously. That data is what improves the change graph and the rules for each trade. The model should not be trained indiscriminately on project data; it should learn from approved corrections and their documented reasoning, in structured form.
The Value of Construction AI Shows in the Last Meter of a Change
Reading drawings and computing quantities matters. But a project's real risk arises after the change. Rework and dispute follow when it is missed who has to re-examine what, which calculations and documents still run on the previous conditions, and where procurement and the schedule are about to stall.
Engineering Change Intelligence is not a system that processes every change automatically. It is a system that makes the radius of a change visible, connects the required calculations to the required people, and keeps unapproved changes out of the official baseline. Once that final control is in place, AI becomes a tool for reducing project risk rather than merely improving design productivity.
doAZ Point of View
The ultimate differentiator in AEC AI is not drawing recognition accuracy alone, but the ability to combine Object Graph, Formula Dependency, Cost and Schedule Link, and Risk-based Approval to control the full lifecycle of a change.