What is a build boundary in process automation?

A build boundary is a documented line separating what automation handles from what a human decides. It is drawn before code is written, during the scoping phase, and attached to the outcome record so stakeholders can see exactly what was automated and what was deliberately left to human judgment.

Why should the build boundary be defined before development?

Because it is a governance decision, not an engineering decision. Drawing the boundary during scoping ensures it reflects regulatory requirements, operational realities, and strategic choices — not just what the automation happened to be able to do.

How does the build boundary affect reported savings?

The boundary provides context for the savings number. A $500K savings figure means something different depending on whether 60% or 95% of the workflow was automated. Attaching the boundary to the outcome record ensures the number is interpreted with full context.

The Build Boundary: Why We Decide What Not to Automate Before Writing Code

What the build boundary is

The build boundary is a documented line in a workflow that separates what the automation handles from what a human decides. It is drawn during the Prove It Sprint, before any code is written, and it becomes a first-class artifact in the delivery.

It is not a scope limitation — it is a design decision. The boundary says: “The automation processes steps 1 through 7. At step 8, the system presents the assembled information to a human who makes the decision. Steps 9 and 10 execute based on that decision.”

The boundary exists because not every step in a workflow should be automated. Some steps require judgment that changes with context. Some steps carry regulatory risk that the institution — not a vendor — should own. Some steps are better done by a person who understands the member.

Why we draw it before writing code

In most automation projects, the boundary emerges accidentally — it is wherever the automation happened to stop working. That creates two problems: (1) the institution does not know what the automation is “supposed to” handle versus what it just could not handle; (2) when the automation improves, nobody re-evaluates whether the new capability should be exercised.

We draw the boundary deliberately during the sprint because it is a governance decision, not an engineering decision. The sprint maps the workflow end-to-end, identifies every step, and then asks: at which steps should a human remain in the loop, and why?

The reasons might be regulatory (the institution must own the final lending decision), operational (exception rates are too high for automation to handle reliably), or strategic (the member relationship benefits from human contact at this moment). All three are legitimate. None of them are “we could not figure out the automation.”

How the boundary lives in the outcome record

The build boundary is attached to the outcome record — the same artifact that carries the projected and recorded savings. This means anyone reviewing the outcome can see exactly what was automated, what was deliberately left to humans, and why.

This matters because a $500K savings number means something different if the automation handles 60% of the workflow versus 95%. The boundary provides context that the number alone cannot.

It also creates an honest starting point for future phases. When the institution considers expanding the automation, the boundary document shows what was deliberately excluded and the reasoning behind each exclusion. Some of those reasons may have changed — new regulation, better data, different risk appetite. The boundary makes that conversation concrete instead of abstract.