CelinQ Insights · No. 24

Who can see and change the model: roles that make sense

Access control that protects the model without getting in the way.

Access control is the part of collaborative modelling that everyone agrees is necessary and almost nobody enjoys thinking about. It arrives late, usually when a model that started as a small trusted effort has grown enough that "everyone can change everything" stops feeling comfortable. A stakeholder wants to see the model but should not be able to alter it. A contractor needs to work in one area but has no business in another. A reviewer needs to approve changes without being the person who makes them. Someone has to own the whole thing. These are reasonable needs, and the instinct is to reach for a permission system to satisfy them. The trouble is that permission systems have a way of solving the stated problem and creating a worse unstated one, and the unstated one is that the controls become friction that people spend their energy working around rather than working within.

The failure mode is familiar to anyone who has lived with heavy access control. The permissions are set up carefully at the start, mapped to a org chart that was accurate that month. Then reality moves. Someone needs access to a part of the model they were not originally granted, and getting it requires a request to whoever administers the system, who is busy, so the person waits, and while they wait they do the work anyway in a copy off to the side, intending to fold it back in later. The control that was meant to protect the model has instead pushed a change outside the model's governance entirely. Access control that is too rigid does not prevent ungoverned work; it relocates it to where nobody can see it, which is precisely the outcome the control existed to prevent.

What access control is actually for

It helps to be clear about what access control is genuinely trying to achieve, because the failures usually come from confusing several different goals and building one mechanism that serves none of them well. There are really three distinct concerns hiding under the single heading of "who can see and change the model," and they have different shapes.

The first is protection against accident. Most damage to a model is not malicious; it is someone changing something they did not understand, or deleting something they did not realise was load-bearing, or editing in a place they had no reason to be. Protection against accident is about matching people's ability to change things to their actual responsibility for those things, so that the blast radius of a mistake is bounded by design. The second concern is confidence for the reader. A stakeholder or an auditor or a client needs to be able to look at the model and rely on what they see without any risk that their looking might change it, and without needing anyone to trust them with more than viewing. The third is accountability: knowing who changed what, and being able to say that the changes to the model went through whatever level of scrutiny the organisation requires. These are three different jobs, and a good access model keeps them distinct rather than collapsing them into one blunt instrument.

Access control fails when it is designed as a wall to keep people out. It succeeds when it is designed as a way of matching what each person can do to what they are actually responsible for.

Roles that describe responsibility, not suspicion

The most important design decision in any access system is the vocabulary of roles, because the roles are the model of who these people are and what they are here to do. Get the vocabulary wrong and every subsequent decision inherits the mistake. Roles that are too fine-grained become a bureaucracy nobody maintains, drifting out of date the moment the team changes shape. Roles that are too coarse fail to make the distinctions that actually matter, forcing administrators to choose between giving someone too much and giving them too little. The right set of roles is small enough to hold in your head and expressive enough to describe the real distinctions people care about.

CelinQ works with a deliberately small set: Viewer, Editor, Administrator, and Owner. The value is in how cleanly they map onto the three concerns. A Viewer can see the model but not change it, which is exactly what the reader needs, and crucially it means giving someone visibility costs nothing in risk. This matters more than it sounds, because when viewing is safe and easy to grant, organisations stop being stingy with it, and a model that more people can see is a model that gets used, checked, and trusted rather than one that is hoarded behind access requests. An Editor can do the actual modelling work, which is the role most of the team lives in day to day. An Administrator manages the arrangement itself, the membership and the permissions, without that management being conflated with either owning the whole thing or doing the modelling. And an Owner carries ultimate responsibility for the workspace. Four roles, each describing a kind of responsibility rather than a level of trust, and that framing is the point. The question a role answers is "what is this person here to do," not "how much do we suspect them."

The tension between control and speed, and why it is usually false

The reason access control gets a bad reputation is the assumption that more control necessarily means more friction, that every gate you add is a delay you impose. In many systems this is true, because the control is implemented as a check that stands between a person and their work: before you can edit, the system asks whether you are allowed, and if the answer is uncertain or the permission is missing, you stop and wait. The control lives on the critical path of everyone's work, so tightening it slows everyone down. This is the mechanism that drives people to the side copies and the ungoverned workarounds.

But this tension is largely an artefact of a particular architecture, not a law. It comes from the model being a single shared store that everyone reaches into, so that access control has to be a guard on the door of that store, checked on every action. When the model works differently, the tension mostly dissolves. In CelinQ each architect works in their own local repository at full speed, online or offline, and a background companion synchronises their saves with a shared workspace the organisation runs itself. The individual's editing experience is not gated by a permission check on every action, because they are working in their own repository; the access control lives at the boundary where their work meets the shared workspace, not on the critical path of their keystrokes. An Editor edits at full speed and the governance is applied to how that work enters the shared model, which is exactly where it belongs and exactly where it does not slow the person down.

This reframing is what lets protection and speed coexist rather than trade off. The Viewer who has no edit rights is not constantly bumping into locked doors; they simply have a view of the model. The Editor is not asking permission before each change; they work, and the governance applies when their work is reconciled into the shared workspace. The Administrator is not a bottleneck standing between the team and its ability to work, because the team's ability to work does not route through them on a per-action basis. The control is real and enforced, but it has been moved off the path where friction hurts, so it protects the model without taxing the work.

Review and governance as part of access, not a bolt-on

Access control is often thought of purely as a matter of who can do what, but the more interesting question on a serious model is how changes are scrutinised, and the two are really the same subject. Being an Editor is not the same as having every change flow unexamined into the authoritative model. CelinQ's change review and governance let an organisation decide that certain changes, or certain parts of the model, warrant explicit review before they are accepted, and this is where the roles and the workflow meet. A reviewer can be someone whose job is to look and approve rather than to author, and the accountability concern, knowing what went through scrutiny, is satisfied by the review process rather than by making the permission scheme carry a weight it was never suited to bear.

What makes this workable rather than obstructive is, again, that it does not sit on the critical path of individual editing. Because everyone works locally at full speed and synchronisation is continuous, review is applied where it earns its cost rather than as a universal gate that all work queues behind. An organisation can decide that a sensitive area of the model gets reviewed carefully while routine work in a well-understood area flows more freely. The governance is proportionate, applied by choice to the changes that deserve attention, instead of being a flat tax on all work that pushes people toward larger and less reviewable changes just to minimise how often they have to pass the gate.

Underneath all of this sits the complete, ordered revision history, and it is the quiet foundation of accountability. Every change is recorded in sequence, which means the question "who changed this, and when" always has an answer, independent of whatever review policy happens to be in force. This is what lets access control be relatively relaxed where relaxation is safe, because even the changes that did not go through explicit review are still recorded and attributable. A team does not have to lock everything down out of fear of untraceable change, because nothing is untraceable. The history turns accountability from something you enforce in advance by restricting people into something you can establish after the fact by looking, and that shift is what makes a lighter touch on the controls responsible rather than reckless.

Presence, and the difference between coordination and control

There is a distinction worth drawing between knowing what your colleagues are doing and controlling what they are allowed to do, because teams often reach for access control when what they actually lack is visibility. Much of the anxiety that leads to over-restrictive permissions is really a fear of collision: the worry that two people will unknowingly work on the same thing and tread on each other. The instinct is to prevent that by partitioning access so that people cannot overlap. But partitioning is a heavy and inflexible way to solve a problem that is really about awareness.

CelinQ addresses that with lightweight presence, which lets people see something of who else is active, and with a merge engine that reconciles concurrent work rather than forbidding it. This matters for access control because it removes one of the main reasons teams over-restrict. You do not need to wall people off from each other to prevent collisions when concurrent work is reconciled safely and people can see each other's activity. The access model is therefore free to be about responsibility rather than about collision-avoidance, which keeps the roles clean. Viewer, Editor, Administrator, and Owner describe what people are here to do; they do not have to double as a scheme for keeping people out of each other's way, because coordination is handled by presence and safe reconciliation rather than by restriction.

The contractor problem, and how roles earn their keep

The scenario that tests an access model most honestly is the outside contributor brought in for a defined piece of work. It is worth walking through because it exercises every part of the design at once. A contractor joins for a few months to build out one area of the model. They need to work in that area at full speed, they have no business elsewhere, they will leave when the work is done, and everything they do while they are here needs to be attributable long after they are gone. A crude access system handles this badly in one of two directions. Either it grants the contractor broad access because setting up something narrower is too much trouble, in which case the model's protection depends entirely on the contractor's goodwill and self-restraint, or it locks them down so tightly that they spend their first fortnight filing access requests and their productive time is eaten by the overhead of asking permission.

The small role vocabulary handles this without either failure. The contractor is an Editor, working in their own local repository at full speed, online or offline, so their day-to-day experience carries no permission friction at all; they simply model. The scope of what their work can affect, and the scrutiny it receives as it enters the shared workspace, are matters of governance applied at the boundary rather than checks that interrupt their editing. Sensitive areas of the model can be set to require review before changes are accepted, so the contractor contributes freely while the organisation retains a deliberate say over what lands in the parts that matter most. And because every change is recorded in the ordered history and attributed, the accountability concern is satisfied automatically and permanently. When the contractor leaves, there is no scramble to reconstruct what they touched, because the record was never dependent on anyone remembering. The Administrator's involvement is a one-time act of adding and later removing a person, not a standing bottleneck that the contractor's every action has to pass through.

What makes this work is precisely the separation of concerns described earlier. The contractor's speed comes from local-first editing. The protection of the model comes from governance at the boundary and review on the parts that warrant it. The accountability comes from the history. No single mechanism is asked to do all three jobs, which is what allows each to be set at the right strength: generous where generosity is safe, strict where strictness is warranted, and always recorded so that a lighter touch never means an untraceable one.

Sovereignty: the control that sits above all the others

There is a level of access control that precedes all the role definitions, and it is the one that matters most to organisations doing serious architectural work, particularly in the public sector: the question of who controls the whole arrangement in the first place. It is a hollow kind of access control if the roles and reviews are carefully arranged but the model itself lives on infrastructure the organisation does not control, subject to terms it did not write. Genuine access control has to start with genuine ownership of the thing being controlled.

This is why CelinQ is built to stay under the organisation's control. The shared workspace runs on a server the organisation operates itself, with storage in either SQLite or PostgreSQL as suits their environment. Transport between the companion and the workspace is encrypted, with certificate pinning so that the connection can only be to the server the organisation intends, and access is authenticated with tokens. The optional in-EA design assistant, which can generate content into a package and analyse existing parts, is off by default and sovereign to the organisation, and the core works entirely without it. The point of listing these is not to parade features but to make a single argument: the entire chain of access control, from who can view a diagram up to who owns the infrastructure it lives on, stays within the organisation's own authority. Access control that you enforce but do not ultimately own is a courtesy extended to you by someone else; access control on infrastructure you run is yours.

For public-sector work in particular, this is not a preference but frequently an obligation. An organisation that is accountable for how it handles its own architectural record cannot fully discharge that accountability if the record and the controls over it live somewhere it does not govern. The comfort of a well-drawn role scheme evaporates if the underlying platform can change its terms, relocate the data, or interpose itself between the organisation and its own model. By keeping the whole arrangement on infrastructure the organisation runs, with the core needing no external service, CelinQ makes the access model something the organisation can actually stand behind when asked. The roles, the reviews, the history, and the encryption are all enforced within a boundary the organisation itself draws, which is the only place access control is ever genuinely under control.

Getting the balance right

The recurring mistake in access control is to treat it as a problem of keeping people out, and to measure success by how much is locked down. That framing produces systems that are simultaneously too restrictive to work with and too crude to actually protect what matters, because they spend their strictness on the wrong things and drive real work into the ungoverned margins. The better framing is that access control exists to match what each person can do to what they are responsible for, to let readers rely on the model without risk, and to make every change accountable, and that these are best served by controls that sit where they do not create friction rather than controls that stand in everyone's way.

A small, honest set of roles that describe responsibility; a placement of those controls at the boundary where local work meets the shared model rather than on the critical path of every edit; review and governance applied in proportion to what actually deserves scrutiny; a complete history that makes accountability a matter of looking rather than of restricting in advance; presence and safe reconciliation that remove the need to wall people off from each other; and, underneath it all, real ownership of the infrastructure so that the control is genuinely the organisation's own. That is access control that protects the model without getting in the way, and the reason it does not get in the way is that it was never designed as a wall. It was designed as a way of letting the right people do the right things, quickly, while the model stays safe and the record stays honest.