CelinQ Insights · No. 11

Reviewing change before it lands in the shared model

Governance that catches mistakes without turning every edit into paperwork.

There is a version of architecture governance that every experienced modeller has lived through and quietly resented. It usually begins well, as a reasonable response to a real problem: someone changed something in the shared model that they should not have, or that was wrong, or that broke a diagram three teams depended on, and the organisation decided that this must not happen again. The remedy is a process. Changes now require a form, or a ticket, or a place on a weekly board agenda, and an architect who wants to correct a mislabelled interface finds themselves writing a justification for a two-minute edit and then waiting a week for permission to make it. The mistakes do reduce, for a while. But so does the modelling, because the friction is now high enough that people simply stop touching the model unless they absolutely must, and a model that people avoid touching drifts out of date, which is the very failure the governance was meant to prevent.

This is the central tension in governing a shared architecture repository, and it is genuinely hard rather than merely a matter of getting the balance right. Governance that catches mistakes tends to add friction, and friction suppresses exactly the frequent, small, corrective edits that keep a model true. The instinct is to treat this as a dial to be tuned — a little more review here, a little less there — but tuning a single dial cannot resolve a contradiction. What is needed is a way to review the changes that warrant review without imposing that review on the changes that do not, and to do it in a way that fits how architects actually work rather than how a change-management framework imagines they work.

Why the shared model is where governance has to live

It is tempting to think governance can happen anywhere — in a meeting, in a naming convention, in a document that says how the model ought to be structured. But the only place governance has any real force is at the boundary where a change becomes part of the shared, authoritative model. Everything upstream of that boundary is advisory. An architect can be told how things should be done, and they can intend to do it that way, and they can still, in the middle of a busy afternoon, save something that is wrong. The question that matters is what happens between the moment they save and the moment their save becomes the version everyone else builds on. If nothing happens in that gap — if the save simply is the shared model the instant it is made — then there is no boundary at which to govern, and governance is reduced to hoping people are careful.

In the common single-shared-database arrangement, that is precisely the situation. There is no gap. Whatever an architect saves is immediately the shared truth, visible to and depended upon by everyone else. Governance, in this world, can only be retrospective: you find out that something wrong landed after it has already landed, after other work has already been built on top of it, and after the person who made it has moved on to something else and forgotten the context. Retrospective governance is expensive precisely because the mistake has had time to spread and to be built upon. The cost of a bad change is not the change itself but everything that accreted around it before anyone noticed.

The alternative that organisations reach for — a heavyweight approval process in front of every change — creates the gap but fills it with the wrong thing. It treats every edit as equally risky, which no experienced architect believes, and it locates the review in a workflow tool that is disconnected from the model itself, so that the reviewer is often approving a description of a change rather than the change. Approving a description is close to useless. The description says "corrected the classification of the payments system"; the actual change might have done that and also, inadvertently, detached a relationship that three diagrams relied on. The workflow tool cannot see that, because it is not looking at the model. It is looking at a sentence about the model.

The two failure modes, stated plainly

It is worth naming the two failure modes precisely, because a good design has to avoid both simultaneously rather than trading one for the other. The first failure mode is the ungoverned model, where every save is instantly authoritative and review is impossible because there is no moment at which to conduct it. Here mistakes land freely and are discovered late. The second failure mode is the over-governed model, where review is mandatory, uniform, and heavy, and applies with equal weight to a typo fix and a structural redesign. Here mistakes land less often, but the model calcifies, because the people best placed to keep it accurate are discouraged from doing so by the sheer cost of each interaction.

Most organisations oscillate between these two modes over the years, swinging toward heavy governance after an incident and then quietly relaxing it once the friction becomes intolerable, only to swing back after the next incident. The oscillation itself is a symptom that the underlying model of governance is wrong. If the only control available is how much process to require, then any setting is a compromise between catching mistakes and permitting work, and no compromise is stable because both failure modes are painful. The way out is not a better compromise on a single axis. It is to separate the axes — to make the decision about whether something needs review independent from the decision about how much the review costs when it does happen.

Separating the routine from the consequential

The premise CelinQ starts from is that most changes to a well-run model are routine and low-risk, and a minority are consequential and warrant a second pair of eyes, and the two should not be forced through the same gate. Achieving this requires a foundation that most sharing arrangements lack: a genuine gap between the individual's work and the shared model, within which review can happen without blocking the individual from continuing to work.

CelinQ provides that gap by design. Each architect edits a local repository at full speed, entirely uncoupled from the pace of anyone else and from the state of the shared workspace. A background companion syncs each save with the shared workspace on a server the organisation runs itself. Because the architect's local work is decoupled from the shared model, there is a natural, non-blocking interval between "I made this change" and "this change is part of the shared truth" — and that interval is exactly where change review lives. The reviewer is not standing between the architect and their keyboard. The architect keeps working locally while the review happens; the review governs what enters the shared model, not what the architect is allowed to do at their own desk.

This decoupling is what makes it possible for review to be selective rather than uniform without creating chaos. Because contributions flow through the shared workspace as discrete, attributed events, the organisation can decide which parts of the model, or which roles, or which kinds of change, require review before landing, and let the rest flow through. An Editor correcting a label in an area they own can have that change land directly, while a change to a governed core package, or a change proposed by someone with a narrower role, is held for review. The roles CelinQ defines — Viewer, Editor, Administrator, Owner — give this policy something concrete to attach to, so that "who can change what without review" is a configured property of the workspace rather than an informal understanding that erodes under time pressure.

Reviewing the change, not a description of it

The other half of making review effective is ensuring the reviewer sees the actual change against the actual model. This is where CelinQ's approach diverges most sharply from ticket-based governance. Because CelinQ Fusion works at the granularity of individual model facts, a change is not an opaque new version of a file; it is a precise, legible set of alterations — this element gained this property, this relationship was created, that one was removed. The reviewer is looking at what genuinely changed, expressed in terms of the model itself, and can see the things a prose description would never mention, including the inadvertent side effects that are the real danger in architectural change. The classification correction that also detached a relationship shows both facts, because both are in the change, and neither can hide behind a summary sentence.

This granularity also changes the emotional character of review, which matters more than it sounds. Reviewing a whole exported model to find what someone changed is miserable work, and miserable work is done badly. Reviewing a small, exact set of model-fact changes is quick and comprehensible, and quick comprehensible work is done well and willingly. Governance that is pleasant enough to actually perform is worth more than governance that is thorough in principle but skipped in practice because everyone dreads it. The point is not to make reviewers more diligent by exhortation. It is to make the review small enough that diligence costs almost nothing.

There is a further benefit that comes from the merge engine being deterministic and reproducible. When a change is held for review and other work continues in parallel, the eventual integration of the reviewed change is not a fresh, uncertain merge conducted by hand. It is the same three-way merge at model-fact granularity that CelinQ performs throughout, keeping non-conflicting changes and isolating genuine conflicts explicitly rather than resolving them by last-write-wins. This means a reviewer never has to worry that approving a change will silently clobber someone else's parallel work, or that the change they reviewed will be subtly different by the time it lands. The thing that was reviewed is the thing that integrates, and where it genuinely collides with other work, that collision is surfaced as an explicit conflict rather than being papered over.

Governance as a record, not just a gate

Review that catches mistakes is valuable in the moment, but review that also leaves a record is valuable indefinitely. Every reviewed change in CelinQ becomes part of the complete, ordered revision history the workspace maintains, attributed to its author and, where review occurred, carrying the trace of that review. This turns governance from a purely preventive control into something that also answers questions later. Six months on, when someone asks why the model was changed in a particular way, the answer is not a vague recollection or a lost email thread. It is in the history, alongside the change itself and the review it passed through.

This matters because governance in architecture is not only about stopping bad changes; it is about being able to explain good ones. A great deal of architectural friction comes from decisions being revisited endlessly because nobody can remember why they were made the first time. When the review that accompanied a change is preserved with the change, the reasoning is available to whoever inherits the model, and the model becomes self-documenting in a way that a separate governance system, living in a different tool, never achieves. The governance and the artifact it governs are the same record, which is the only arrangement that stays coherent over years.

Being honest about what review cannot do

I want to resist the temptation to present review as a solution to the problem of bad architecture, because it is not, and pretending otherwise would set up exactly the disappointment that discredits governance in the first place. A reviewer can catch a change that is inconsistent with the rest of the model, or that has an unintended side effect, or that violates a convention the organisation has agreed. A reviewer cannot, by reviewing, supply architectural judgement that the organisation does not possess, and no amount of process turns a team that does not understand its own systems into one that does. Review is a filter on change, and a filter can only work with the changes that pass through it; it cannot generate the good ones.

The related honesty is about selectivity. Letting routine changes land without review is not risk-free — it is a considered acceptance that the cost of reviewing everything exceeds the cost of the occasional routine mistake, and that the routine mistakes are cheap to correct precisely because the history makes them easy to find and reverse. An organisation that has been badly burned may prefer to review more, and CelinQ lets it, because the policy is configurable rather than fixed. The claim is not that selective review is always right. The claim is that the choice should be the organisation's, made deliberately with knowledge of the trade-off, rather than forced by a tool that can only offer "everything is instantly shared" or "everything requires a ticket".

The optional in-EA design assistant sits inside this same governance frame rather than outside it, which is deliberate. When it generates content into a selected package or analyses existing parts of the model, whatever it produces is a change like any other, entering the same reviewable, attributed flow into the shared workspace. It is off by default and operates under the organisation's control, and the core of CelinQ governs change identically whether or not it is ever switched on. There is no privileged path by which generated content bypasses review; if a policy requires review for a given package, it requires review regardless of how the change to that package was produced.

Governance that scales with trust rather than fighting it

One of the quieter failures of heavy governance is that it treats every contributor as equally likely to cause harm regardless of what they have demonstrated over time. A person who has maintained a part of the model correctly for years is subjected to the same gate as someone touching it for the first time, and the message this sends is corrosive: that competence earns no latitude and that the organisation does not distinguish between its experienced hands and its newcomers. Experienced architects notice this, and they resent it, and their resentment expresses itself as disengagement from the model — the last thing a practice can afford from precisely the people who understand the model best.

A more sensible arrangement lets the amount of review track the actual distribution of risk, which is neither uniform across people nor uniform across the model. Some regions of an architecture are load-bearing in the sense that many things depend on them, and a mistake there propagates widely; other regions are peripheral, and a mistake is local and cheap to fix. Some contributors have earned, through demonstrated reliability in a given area, the latitude to make routine changes there without ceremony; others are still building that track record. Governance that recognises these differences concentrates its scrutiny where the risk actually is, and in doing so it becomes both lighter overall and more effective, because the reviewers' limited attention is spent on the changes that could genuinely hurt rather than diluted across a flat mass of edits most of which never could.

There is a subtler benefit to letting trust accumulate visibly, which is that it gives newer contributors a path rather than a permanent status. A person who joins the practice and is initially subject to review in a given area is not being distrusted so much as onboarded, and the history of their reviewed changes becomes the record on which their eventual latitude is granted. Review, in this framing, is not only a filter on mistakes but a way of building the shared confidence that lets the practice eventually govern itself more lightly. A team that never reviews has no basis on which to extend trust, because it has no record of how its members actually work; a team that reviews everything forever never converts that record into latitude and so never reaps the benefit of the trust it has earned. The sensible middle is to review where trust has not yet been established and to relax as it is, and that middle is only reachable when the review leaves a durable, attributed record of who has done what, well, over time.

CelinQ's roles and configurable review make this kind of differentiation expressible rather than merely aspirational. Because the workspace can require review for particular parts of the model or particular roles while letting the rest flow, an organisation can encode the judgement that a senior Editor working in an area they own is trusted to correct it directly, while a change to a governed core, or a change from someone with a narrower role, is held. This is not a relaxation of governance; it is a sharpening of it. The scrutiny is not reduced so much as redirected to where it earns its cost, and the experienced contributors are given the latitude their record has earned, which keeps them engaged with the model instead of driving them away from it. Governance that scales with demonstrated trust is governance a team experiences as fair, and fairness is what makes people willing to work inside a system of controls rather than around it.

A grounded takeaway

The governance most architecture practices actually need is narrower than the one they usually build. They do not need every edit to become paperwork. They need the consequential edits to be seen before they land, they need that review to be against the real change rather than a description of it, and they need the whole thing to leave a record that outlives the people who made it. The reason this is so rarely achieved is not that organisations lack the will. It is that their sharing arrangement gives them nowhere to put the review — either no gap at all, or a gap filled with a disconnected workflow tool that reviews sentences instead of models.

CelinQ's contribution is to create the right kind of gap: a non-blocking interval between individual work and the shared model, populated with review that is selective, legible at the level of individual model facts, and preserved in the history as a permanent part of the record. Architects keep working at full local speed while it happens, so the friction that kills governance never accumulates. Mistakes that matter get caught; mistakes that do not are left to the cheap, reversible correction that a complete history makes easy. That is governance that a working team can live with year after year, rather than a control that gets imposed after an incident and quietly abandoned once everyone remembers how much they hate it. The goal was never to review more. It was to review the right things, well, without making the model too painful to maintain — and that goal is reachable only when the tooling gives the review somewhere honest to stand.