Reference6-minute read

Which rules shape the design first?

The architecture practice · Checked 20 Oct 2026

In short

Your regulator, the core you can't replace, where your data must live, and the weeks you close the books are design inputs, not friction to price around. We draw them onto the plan before anything is built. Each one changes where a piece runs, what it may touch, or when it may ship, and each becomes a rule the control plane checks.

Our position

We find your hardest constraints in the first week. A constraint found in the final security review costs a redesign.

Chapter 1 · constraints on the planEvery constraint becomes something you can see on the plan

A residency rule becomes a boundary. A plant network with no internet becomes a zone of its own. Two entities that must stay apart get a line between them, and the quarter close becomes a window with no releases.

Each constraint becomes something you can see on the plan: a boundary, a zone, a line two entities never cross, or a window with no releases.fig 1 · constraint-plan

Chapter 2 · the six we see mostSix constraints come up in almost every plan

The constraint	What it changes on the plan
Data must stay where it is	The plan shows where every store lives, and we check residency at the boundary, not in a contract appendix.
Some systems have no internet	Air-gapped zones get their own place on the plan, with their own way to deploy and update.
Separate entities stay apart	Five legal entities and three regulators can still share one plan. We decide on it what's shared and what must never touch.
The core stays	Your system of record stays load-bearing, and everything new works with it, not around it.
An acquired company joins	We join the two pictures on purpose, so the systems don't sit side by side for a decade.
The books close on a calendar	We plan releases around the weeks you close the books.

Chapter 3 · constraints as rulesWe write each constraint as a rule the control plane checks

A constraint that lives only in a document gets broken by the first workload that didn't read it. So each one is written as a rule, with an owner and the evidence that proves it held.

constraints.yaml

constraint: eu-residency
applies_to: [customer, policy, claim]     # personal data
rule: stores and model calls stay in the EU region
checked_at: the gateway, on every call
evidence: a residency report each month
owner: data protection officer

constraint: quarter-close-freeze
window: last 5 and first 3 working days of each quarter
blocks: releases to finance systems
allows: fixes the controller signs
owner: group controller

When a rule changes, the change is dated and recorded, so you can show which rule held on any day.

Chapter 4 · what we ask in week oneWe ask seven questions before we draw anything

Which regulators oversee each part of the business?
Which legal entities share systems today, and which must never share data?
Which data can't leave which country?
Which systems can't be replaced or changed in the next three years?
Which networks run with no internet connection?
When do you close the books, and which systems freeze while you do?
Which acquisitions are still running their own systems?

Questions architects ask

Does a regulated business need a different stack?

No. It uses the same board. The constraints change where pieces run and which rules the control plane checks.

Can an agent run in an air-gapped zone?

Only when the agent and its model are installed inside the zone. The zone gets its own place on the plan, with its own way to deploy and update, and we decide on the plan whether the job is worth that.