10.3 Where Automation Fits Inside a BIM Execution Plan

Introduction

Everything built across this module so far has been code, run by a person choosing to execute it. This lesson steps back from code entirely and asks where something like it actually belongs on a real project, specifically inside a BIM Execution Plan, the document Module 8 introduced as the delivery team's formal response to a client's information requirements. Automation doesn't invent a new category of activity a BEP has to make room for. It fills a slot that was already there.

Rebuilding the BEP

A BIM Execution Plan, BEP, is the document a delivery team produces in direct response to an Exchange Information Requirement, setting out how that team intends to meet it: who does what, using what software, following what standards, on what schedule, and how quality gets checked before information moves forward. There are two versions. A pre-appointment BEP is submitted during tender, a lighter, more proposed answer used to compare competing bidders. A post-appointment BEP is confirmed once a contract is signed, far more detailed, and becomes the actual working document the delivery team follows for the rest of the project.

Among its regular contents, a BEP typically covers technical standards, the delivery team's organizational structure, the information delivery schedule, and, directly relevant here, the quality control and assurance processes the team commits to following before information gets shared or published.

Where Quality Checking Already Lives in a BEP

This isn't automation inventing something new to write into a project's paperwork. ISO 19650-2 already names quality checking as its own explicit step in the information production cycle, clause 5.6.4, "undertake quality assurance check," sitting between generating information and reviewing it for sharing. Historically, and still very commonly, that step means a person opening a model and looking it over by eye. Nothing about the standard specifies how the check has to be performed, only that it happens, before information moves toward being shared, reviewed, and eventually authorized.

That's the exact slot a pipeline like the one built in 10.1 and 10.2 fills. It doesn't sit alongside the quality assurance step as something extra. It's a specific, automatable way of performing that same step, one already named and expected in the production cycle a BEP is meant to describe.

What a BEP Needs to Say About an Automated Check

Naming automation in a BEP means being specific about the same things a manual check would need to be specific about, just with a script standing in for a person's eyes. What's actually being checked. Against what rule set, whether that's a small set of hand-written Python rules like Module 10's, or a formal IDS specification from Module 7. At what point in the CDE lifecycle it runs, tying directly back to the states covered in Module 8.2, most naturally before a container moves from Work in Progress into Shared, catching problems while they're still cheap to fix rather than after other disciplines have started coordinating against them. And who remains accountable for the result, since running a check automatically doesn't remove the need for a named person or role responsible for what the check actually found, or missed.

An automated tool changes who performs the check. It doesn't change the fact that a check happened, and a BEP still needs to say so clearly enough that anyone reading it understands exactly what gets checked, when, and by what standard.

A Worked Example

A plausible BEP clause describing this might read:

"Prior to any structural model moving from Work in Progress to Shared status, the model shall be run through the task team's automated quantity extraction and QA pipeline. This checks that base quantities are present for all structural elements and that reported values fall within defined plausibility thresholds for each element type. Any element flagged by this check shall be reviewed and corrected by the originating modeler before the container is shared. The BIM Coordinator remains responsible for confirming this check has been run and reviewing the flagged issues log before authorizing the status change."

Every piece a manual quality check clause would need is still there: what triggers the check, what it actually verifies, what happens when something fails it, and who's accountable for the outcome. The only thing that's changed from a traditional clause is that the verification step itself is performed by a script rather than a person paging through a model by eye.

The Boundary This Lesson Doesn't Cross

Worth being precise about what naming automation in a BEP actually commits a team to. It's a process commitment, a statement that a specific kind of check will run at a specific point before information moves forward. It is not, on its own, a technical guarantee that the tool performing that check is correctly built, covers everything it should, or catches every real problem in a file. A BEP clause describing an automated check is exactly as trustworthy as the check it describes, no more, and writing the clause well doesn't retroactively make a weak or incomplete script into a reliable one. This is the same boundary that's run through this whole series since Module 8: a documented, well-governed process and a technically correct result are two different things, and naming a step in a plan confirms the first, not the second.

What's Next

This lesson covered automation as a documented process commitment, a line in a plan describing what happens and when. The next lesson goes back to something closer to code, but a different kind than anything built so far in this module: running a check automatically, on a schedule or a trigger, rather than by a person choosing to execute a script, the pattern most commonly known as CI/CD.