CelinQ Insights · No. 07

Keeping the model on your own soil: data residency for architecture

For public-sector and regulated work, where the model lives is not a detail.

There is a moment in most public-sector engagements that has nothing to do with modelling and everything to do with whether the engagement can proceed at all. It usually arrives late, after the diagrams have been agreed and the workshops have gone well, when a security officer or a data-protection lead asks a plain question: where does the model actually sit? Not the deliverables, not the exported reports, but the working repository itself, the living thing that the architects open every morning. And more often than the tooling vendors would like to admit, nobody in the room has a crisp answer. The repository is on a shared drive that turns out to be backed by a cloud tenant in another jurisdiction. Or it is in a hosted service whose terms reserve the right to move data between regions for operational reasons. Or it is on a laptop that travels, syncing through whatever consumer file-sharing account the architect happened to have. The question is simple; the answer is a shrug; and the engagement stalls while people who were never in the workshops decide whether the work can continue.

Architects tend to treat this as somebody else's problem, a compliance formality that gets sorted out by the people whose job titles contain the word governance. That instinct is understandable and it is wrong. The model is not neutral. An enterprise-architecture repository for a government agency, a hospital network, a defence supplier or a regulated financial institution is a description of how that organisation actually works, where its data flows, which systems hold what, where the weaknesses are and how the parts connect. It is, in a real sense, a map of the attack surface and a map of the dependencies at the same time. If an adversary could commission one document to understand where to push, the architecture model would be a strong candidate. Treating the location of that map as a detail to be settled later is treating the most sensitive artefact of the whole practice as the least important.

Residency is not the same as security, and both matter

It helps to separate two ideas that are frequently confused. Data security is about whether the model is protected: encrypted in transit and at rest, reachable only by the people who should reach it, resistant to interception and tampering. Data residency is about where the model physically lives and under whose legal jurisdiction it falls. You can have excellent security and poor residency, and the combination will still fail an audit. A repository can be perfectly encrypted and still be sitting in a datacentre governed by a foreign legal regime that can, under its own laws, compel disclosure without ever notifying your organisation. For a private company selling widgets, that might be an acceptable risk. For a ministry, a health authority or anyone handling citizen data under a residency obligation, it is not a risk to be weighed. It is a line that cannot be crossed, and crossing it quietly is worse than crossing it openly.

The regulatory backdrop has only sharpened this. Public bodies across Europe increasingly operate under explicit requirements that certain categories of information remain within national or Union borders, processed by entities subject to local jurisdiction and shielded from extraterritorial reach. The details vary by country and by sector, and they keep moving, but the direction of travel is unmistakable. What was once a preference expressed by a cautious procurement officer is now, in many tenders, a hard eligibility criterion. A tool that cannot demonstrate where the data lives does not lose points; it is disqualified before the evaluation of its features begins. Architects who have watched a strong technical proposal fall at this hurdle rarely make the same mistake twice.

The uncomfortable truth about most collaborative tooling is that convenience and residency pull in opposite directions, and the convenient default almost always wins until someone forces the question.

The reason the convenient default wins is worth dwelling on. Collaboration, in the ordinary sense, means a central place that everyone reaches. A shared server, a hosted workspace, a cloud repository: something in the middle that holds the truth and that every contributor connects to. The moment you accept that architecture, you have accepted that the sensitive artefact lives in one specific place, and now the whole residency question rests on the properties of that one place. If that place is operated by a third party, on infrastructure you do not control, under terms you did not write, then residency is a promise made by someone else, and it is only as good as their contract, their subprocessors, and their willingness to tell you when things change. The organisation has outsourced not just the hosting but the sovereignty.

Where the local-first shape changes the argument

This is where the structure of the tool starts to matter more than any single feature, because the shape of the collaboration determines the shape of the residency problem. CelinQ is built local-first, and that phrase carries a specific consequence for sovereignty rather than being a performance boast. Each architect works against their own local repository, a real and complete copy of the model that lives on their own machine. The editing, the reading, the day-to-day modelling all happen locally, at full speed, whether the network is present or not. Collaboration is achieved not by everyone reaching into a distant shared brain but by a background companion that reconciles each person's saves with a shared workspace. The shared workspace is real and it is necessary, but it is not a service you rent from a stranger. It runs on a server the organisation stands up on its own infrastructure.

Read that last sentence slowly, because it is the whole argument. The shared workspace runs on infrastructure the organisation controls. It can be a machine in the organisation's own datacentre, a virtual server in a sovereign cloud region the organisation has chosen deliberately, or a box in a locked room with a single network cable. The point is that the decision about where the model lives is returned to the organisation, where it belongs, rather than being an inherited property of a vendor's operational choices. When the security officer asks where the model sits, the answer is a place the organisation itself picked, running software the organisation itself deployed, reachable only across links the organisation itself configured. That is a very different conversation from a shrug.

The storage layer follows the same principle. The shared workspace keeps its data in an ordinary database: SQLite for a small team or a single server, PostgreSQL where an organisation wants the operational maturity of a proper database engine with its own backup regime, replication and monitoring. Both are technologies that any competent infrastructure team already knows how to host, secure and audit. There is no proprietary datastore that only the vendor understands, no opaque format that ties the organisation to a hosted arrangement, no place where the data quietly becomes someone else's responsibility. The organisation's own database administrators can point their existing tooling at it, apply their existing retention policies, and fold it into the same disaster-recovery plan that already covers everything else they consider important. Residency stops being a special case and becomes ordinary infrastructure the organisation already governs.

CelinQ is designed so that the answer to that test is yes. The core of the system, the local editing and the reconciliation against the organisation's own shared workspace, needs no external service to function. There is no call home, no licensing check that phones a distant server before letting people work, no dependency on a hosted component that sits outside the organisation's control. An air-gapped installation is not a heroic special configuration wheeled out for the most paranoid client; it is the ordinary system with its network boundary drawn tightly. For organisations that operate genuinely isolated environments, and there are more of them than the wider software industry likes to remember, this is the difference between a tool they can use and a tool they can only admire from behind a firewall.

The links between the parts, not just the parts

Residency of the stored model is necessary but not sufficient. The traffic between each architect's machine and the shared workspace also has to be protected, because a map of the model in flight is as sensitive as a map of the model at rest, and networks in large organisations are rarely as trustworthy as their diagrams suggest. CelinQ moves this traffic over encrypted transport with certificate pinning, which is a deliberately stronger stance than accepting whatever certificate a connection happens to present. Pinning means the companion will only trust the specific certificate belonging to the organisation's own workspace, not merely any certificate that a broadly trusted authority has signed. It closes the category of attack where a party positioned in the middle of the network presents a technically valid but illegitimate certificate and quietly reads or alters the exchange. Access to the workspace is gated by token authentication, so that reaching the server is not the same as being allowed to speak to it.

None of this is exotic. It is the ordinary hygiene one expects of any system carrying sensitive data, and it is described here plainly because architects have learned to be suspicious of tools that talk warmly about collaboration while staying vague about how the bytes actually travel. The point is not that these mechanisms are unique. The point is that they are present by default and that they operate entirely within the organisation's own boundary. Encryption and pinning protect a channel that runs from the organisation's machines to the organisation's server. There is no third leg of the journey where the data passes through infrastructure the organisation cannot see. The trust boundary and the residency boundary are the same boundary, which is exactly the property that makes the compliance conversation short.

The subprocessor question, and the chain nobody reads

There is a failure mode of hosted collaboration that deserves its own attention because it is where good intentions most often come undone. An organisation signs up with a vendor who is entirely reputable and who genuinely operates from the correct jurisdiction. The residency box is ticked and everyone moves on. What the ticking of that box quietly overlooks is that the vendor themselves depends on other providers: a cloud platform underneath them, a backup service off to the side, a monitoring tool that receives telemetry, a support arrangement that occasionally needs to look at real data to diagnose a problem. Each of those is a subprocessor, and each is a place where the model, or fragments of it, or metadata about it, can travel somewhere the original contract never quite examined. The chain of custody is longer than the front page of the agreement admits, and the parts of it that matter most for residency are usually the parts written in the appendices that nobody reads.

The only durable answer to the subprocessor problem is to have no subprocessors, and that is a property of shape rather than of contractual diligence. When the shared workspace runs on the organisation's own infrastructure, there is no chain to audit because there is no chain. The model sits in the organisation's database, on the organisation's server, backed up by the organisation's own regime, monitored by the organisation's own tools. The question of who else touches the data has a one-word answer, which is nobody, and that answer holds without anyone having to trace a subprocessor list through three layers of vendor and hope it stays accurate through the next renewal. This is the quiet advantage of a design that never centralised the sensitive artefact in someone else's care in the first place: there is simply no third party whose behaviour the organisation has to keep verifying.

Backups and recovery have a residency too

A point that is easy to get right for the live system and easy to get wrong everywhere else concerns where the copies live. A repository can be scrupulously resident in the correct jurisdiction while its backups quietly stream to storage in another one, and an organisation that has thought carefully about the former while ignoring the latter has a residency posture with a gap in exactly the place an auditor will look. Backups are full copies of the sensitive artefact by definition; a backup that crosses a border has crossed the same line the live model was forbidden to cross, and the fact that it happened automatically and invisibly makes it worse rather than better.

Because CelinQ's shared workspace stores its data in an ordinary SQLite or PostgreSQL database on infrastructure the organisation controls, the backups are the organisation's backups, governed by the same retention and location policy the organisation already applies to everything else it takes seriously. There is no separate, vendor-managed backup process quietly depositing copies in a location chosen for the vendor's convenience rather than the organisation's compliance. The disaster-recovery plan that covers the model is the disaster-recovery plan the organisation already runs, extended to one more ordinary database. Residency, in other words, holds not just for the working model but for every copy of it, because every copy lives inside the same boundary as the original, under the same policy, on purpose.

The intelligent features, and the discipline of keeping them optional

Any honest discussion of sovereignty in modern tooling eventually has to address the features that generate and analyse content, because that is precisely where sovereignty is most often quietly surrendered. It has become almost routine for tools to offer help that works by shipping the user's material off to some external service, processing it there, and sending back a result. For architecture models this would be an extraordinary thing to do casually. It would mean the very map we have spent this whole piece trying to keep on home soil is being copied, in whole or in fragments, to a system outside the organisation's control, for reasons of convenience. A residency posture that is scrupulous about the stored repository and careless about the assistance features has a hole in the middle of it large enough to drive the entire compliance failure through.

CelinQ's approach here is deliberately conservative. There is an optional in-tool design assistant that can generate content into a package the architect selects and can analyse existing parts of the model. It is genuinely useful, and it is genuinely optional: it is off by default, the core platform works completely without it, and it is designed to be sovereign rather than to reach outward. An organisation that will not permit any such capability simply leaves it switched off and loses nothing from the collaborative core. An organisation that wants it can enable it within its own boundary, on its own terms, rather than accepting a design where the assistance is welded to an external dependency. The principle is that convenience must never be the thing that breaches residency. If a capability cannot respect the boundary, it should be optional and clearly marked, not enabled quietly and explained later.

This is also, frankly, a matter of institutional trust that outlives any single procurement. When an architect stands in front of a client and says the model never leaves the organisation's control, that statement has to remain true under every feature, every future release and every default. It cannot be true for the storage and false for the assistant. It cannot be true today and quietly false after an update flips a default. Building the intelligent features as optional and boundary-respecting from the start is what lets the claim stay simple and stay honest, and a claim that stays honest is the only kind worth making to a regulator.

What this changes for the person defending the work

Step back from the mechanisms and consider the human situation, because that is where the value actually lands. The architect on a public-sector engagement is usually the person who has to stand in the room and answer for the tooling. They did not write the data-protection regulation and they cannot change it, but they are the face of the decision to use a particular tool, and if that tool turns out to leak the model across a border, it is their credibility that pays, not the vendor's. What they need is not a brochure full of reassuring adjectives. They need to be able to give short, true, checkable answers to hard questions, and to give them without hedging.

Where does the model live? On a server the organisation runs, in a location the organisation chose. Who can reach it? Only holders of valid tokens, over encrypted and pinned connections, within the organisation's own network. What happens if the connection to the outside world is cut? Nothing; the team keeps modelling, because the work is local and the workspace is internal. Does anything about the model leave the boundary? No, and the one feature that could is optional, off unless deliberately enabled, and built to stay inside. Can your database team back it up, audit it and fold it into existing recovery plans? Yes, because it is an ordinary SQLite or PostgreSQL database, not a proprietary black box. Every one of these answers is a sentence, and every one of them can be verified rather than merely believed. That is what sovereignty actually buys: not a warm feeling, but the ability to be checked and to pass.

There is a broader shift underneath all of this that is easy to miss while staring at certificates and jurisdictions. For a long time the industry quietly accepted a trade in which teams handed over control of their most sensitive artefacts in exchange for the convenience of collaboration, on the unexamined assumption that you could not have the second without surrendering the first. Local-first collaboration is, at bottom, a refusal of that trade. It says the convenience of working together and the sovereignty of the data are not opposed, that you can have architects reconciling their work continuously and still have every byte of the model living somewhere the organisation controls. For most commercial software that trade-off might be an acceptable convenience. For the public sector and the regulated world it was never acceptable; it was only tolerated because the alternative had not been built in a form that respected how those organisations actually have to operate.

None of this makes residency effortless. An organisation still has to decide where its server sits, still has to configure the boundary, still has to run its database and its backups with the seriousness they deserve. Sovereignty is a responsibility, and a tool that promised to make the responsibility disappear would be lying. What changes is that the responsibility is now genuinely the organisation's to hold, rather than a promise held on its behalf by a party it cannot see and cannot compel. That is the honest version of the pitch, and it is the version that survives contact with a security review. Where the model lives stops being a question the tool cannot answer and becomes a decision the organisation gets to make on purpose, which is where a decision of that weight always should have been.