A Framework for Repeatable Design Automation
This article outlines the 4-step design automation framework used in Exelsiv's Building Design Automation workstream. It is the same framework introduced in our MMC configuration work and applied consistently across all three Exelsiv workstreams.
Design teams in Architecture, Engineering and Construction (AEC) often have more automation activity than they realise. Scripts get written, parametric logic gets built, workflows get set up. But most of it stays project-specific, person-specific, or platform-specific. When the project closes, or the person moves on, the logic goes with them.
The problem is rarely a lack of technical capability. It is that automation gets treated as a task rather than infrastructure. Nobody writes down the logic. Nobody assigns ownership. Nobody asks whether the thing being automated is worth automating in the first place.
This is where a simple framework helps.
Why This Matters
Design teams make the same types of decisions again and again: what can be automated and what cannot, what data the automation needs to run, who is responsible for maintaining it, and how the logic moves through design and delivery. When that logic is not documented, each new project starts closer to first principles than it should.
The result is familiar. Teams spend time rebuilding the same automation, rechecking the same assumptions, and patching gaps later in the job. Even good software cannot fix that on its own, because automation only compounds once the rules, data, and ownership are clear enough to formalise.
At Exelsiv, we use the same four-step structure across all of our disciplines because the underlying problem is identical. Decisions are being made repeatedly, the logic behind them is not documented, and nothing compounds from one project to the next.
Whether the repeating decision is a product selection rule in an MMC configuration workflow or a parametric geometry logic in a design automation context, the structure needed to make it reusable is the same:
Define the rules
Set the required data
Map the decision flow
Embed and refine.
The 4 Steps
1. Define Rules
Start by listing your repeatable design workflows and flagging the tasks within them that are candidates for automation. Note where each can and cannot be automated, and what conditions need to be true for the logic to hold.
Then write down the decision logic behind each candidate clearly enough that someone else could follow it. This step sounds straightforward, but it is where most automation fails. Once those rules are explicit, they stop being dependent on memory, seniority, or whoever built the original script.
2. Set Required Data
For each automation candidate, define the minimum inputs it needs to run consistently. Tie those requirements back to your naming conventions, project standards, and delivery obligations so the data has a clear purpose rather than becoming admin for its own sake.
Just as importantly, check that the right data can be captured at the point where decisions are actually made. If the required information can only be filled in later, by someone else, on a different platform, the automation will break down quickly.
3. Map Decision Flow
Next, map who decides what, when, and on which platform across your design and delivery process. Mark the handover points where logic, data, or ownership currently breaks down. Highlight where automation is being bypassed, rebuilt from scratch, or siloed within individual team members.
This helps teams see the automation system they already have, even if it is informal and fragile. Once the real decision flow is visible, it becomes much easier to improve it deliberately instead of reacting to each issue one project at a time.
4. Embed and Refine
Finally, build the rules and logic into your templates, standards, and workflows so the automated path is the default. The aim is to make the standard approach easier to follow than the workaround, so the right behaviour is supported by the way work actually gets done.
Then trial it on live work, learn from what happens in practice, and update the rules and logic accordingly. That is how a framework moves from a useful idea to an operational default.
A Quick Self-Check
If you want a simple sense of where your current design automation approach stands, five questions are a useful starting point:
Are the repeatable tasks in your design workflows documented in one place?
Is the logic behind your automation written down clearly enough for someone else to maintain it?
When a team member leaves, does your automation continue to work without being rebuilt?
When something is built on one project, is it available as a starting point for the next?
Is there clear ownership for maintaining and updating your automation as projects and platforms evolve?
If several of those answers are “no”, you likely have automation activity but not an automation system, even if the capability is already in your team.
How to Use This Framework.
This framework is a practical way to identify where rules are undocumented, where data requirements are unclear, and where ownership is missing, so you know where to focus before building anything.
Most teams can see themselves in this framework straight away. Where they usually get stuck is finding the time and focus to run the conversations, make the trade-offs, and translate decisions into automation logic that actually fits their projects and platforms. That is the work Exelsiv leads: turning this simple structure into an automation standard your team can own and keep using.
Download the Free Framework
If this feels familiar, you do not need another lengthy report. You need a simple way to talk about rules, data, decision flow, and automation in one conversation.
That is why this design automation framework is available as a free download. It turns these four steps into a simple one-pager you can use in internal conversations, workshops, or pilot projects.
If you would like help applying it on a live project, Exelsiv runs a focused discovery and design sprint that takes you from scattered scripts and one-off automation to a documented system, ready to build on across your next projects.
Contact us to see whether this framework makes sense for your current design workflows.
