10.3 covered naming an automated check inside a BIM Execution Plan, a process commitment that a check will run at a specific point. What it didn't cover is what actually starts that check running. A script sitting on a hard drive, however well built, still needs a person to remember to open a terminal and run it. This lesson covers a pattern that removes that dependency on memory: automated pipelines that trigger a check on an event, rather than waiting for someone to get around to it.
Continuous integration and continuous delivery, CI/CD, is a software-engineering practice in which automated pipelines build, test, validate, and potentially deliver changes through repeatable stages. In continuous integration specifically, those checks are commonly triggered by changes submitted to a shared repository, so verification happens consistently rather than depending on a person to perform it manually. Continuous delivery extends that idea further: keeping a change in a state ready for release once it's passed those checks, rather than assuming every passing change gets deployed automatically, which is a stronger practice usually called continuous deployment.
Worth being precise here rather than oversimplifying: a pipeline can be triggered by more than just a push, a pull request, a scheduled run, a manual trigger, or another pipeline finishing can all start one. For this lesson, the specific pattern that matters is event-triggered checking, something changing, and a pipeline responding automatically. That's the piece worth carrying into how this maps onto IFC.
From the automation system's perspective, a model file being committed to a repository has the same useful shape as source code being committed: an event occurs, a pipeline is triggered, and automated checks run against the changed content. The automation pattern is the same. The project semantics behind it aren't necessarily identical, a BIM team's real information workflow isn't automatically a Git repository, which matters enough to come back to directly in a moment. But the underlying shape, event happens, pipeline responds, holds regardless.
This isn't a hypothetical extension of software practice into an unrelated field. Working examples already exist of IFC repositories using continuous-integration workflows to automatically validate IFC files, including schema-level checks and evaluation against a project's IDS specifications, when changes are pushed, with the result reported directly back on that push.
Two kinds of trigger are worth knowing at a conceptual level. A version control push, a model being committed to a shared repository, the same event that triggers CI in software development. Or an event exposed by a CDE workflow, which is worth being precise about rather than assuming it works like a folder being watched for new files. A CDE-triggered workflow doesn't require the CDE itself to behave like a Git repository. The integration can expose an event, a new or revised container reaching a particular workflow state, for instance, which then starts automation elsewhere. The important concept is the event and its defined consequence, not the storage technology generating it. Treating "CDE" as simply "cloud folder plus CI/CD" misses this.
Setting up the specific tooling behind either kind of trigger, configuring a particular CI/CD platform, connecting a specific CDE to a specific automation service, is real, detailed technical work that depends heavily on which tools a project is actually using. That's outside what this lesson covers. What matters here is the pattern itself and why it fits, not a platform-specific walkthrough.
The trigger doesn't need new checking logic. It calls the same batch-and-QA pipeline built across this module, extraction from 10.1, checks from 10.2, the exact process 10.3 described being named in a BEP, just invoked automatically rather than by a person typing a command. Nothing about the checking logic itself changes. What changes is what starts it running.
This is the actual shift CI/CD adds beyond simply automating a check's timing. In every version of this pipeline built so far, a failed check produced a CSV, a file a person could open and read, if they chose to. A report informs a decision. A gate makes passing a prerequisite for a defined next step, blocking a specific transition rather than merely recommending against it. A push that fails its automated checks can be prevented from merging. Where the CDE or workflow system exposes an appropriate integration, a check's result can be used as a prerequisite for a status transition, rather than assumed to control it automatically regardless of what the underlying system actually supports.
That distinction matters more than it sounds. A report only works if someone reads it, and reading it is optional in a way a blocked merge isn't. Turning a check into a gate is what makes "this must be verified before it proceeds" something the process guarantees, rather than something that depends on a person's diligence.
Worth adding one qualification here, since it's easy to overreach in the other direction: not every failed rule has to be a hard gate. A mature pipeline can distinguish blocking failures from warnings or issues that need human review, depending on the consequence a project actually defines for that specific check. Turning every result into an automatic block isn't itself the goal. Making the consequence of failing a check a deliberate, defined choice rather than an accident of whether someone happened to read a report is.
Worth being explicit rather than implying more than this lesson actually delivers. Setting up a real CI/CD system, choosing a specific platform, configuring its triggers, writing the actual workflow file that runs a script on every push, is genuine tooling knowledge with its own real depth, specific to whichever platform a team ends up using. This lesson covers the pattern and why it fits IFC checking naturally. It doesn't walk through building one.
This module built one continuous line, worth seeing as a whole now that it's complete. 10.1 turned a single-file script into something that processes a whole folder without breaking on one bad file. 10.2 added judgment on top of that extraction, explicit rules that flag what actually needs attention rather than treating every value as equally fine. 10.3 stepped back from code and placed that same process inside a project's actual governance, a named commitment in a BIM Execution Plan rather than something happening invisibly. This lesson closed the loop by triggering the same pipeline automatically on a defined event, with the option to make its result an actual gate rather than just a report waiting to be read.
Everything built across Modules 9 and 10 has been about static files, files sitting still, extracted from, checked, and reported on. The next module moves toward something genuinely different: information that keeps changing after handover, and what happens when the target isn't a file anymore but a live, ongoing asset. That's where Module 11, Digital Twins, picks up.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.