CelinQ Insights · No. 18

Holding modelling conventions steady across a growing team

Consistency is a team problem before it is a tooling problem.

A modelling convention is a small agreement that a team makes with itself. We will name services this way. We will decompose capabilities to this level and no further. This relationship type means this specific thing, and we will not use it to mean something almost-like-it because that was convenient one afternoon. When there are one or two of you, these agreements barely need to be spoken; you hold them in your head and you apply them by habit, and the model comes out consistent because the same mind made all of it. Consistency at that scale is free, and because it is free it is invisible, which is exactly why it becomes a shock when it stops being free.

The moment the team grows — a third architect, a fourth, a contractor brought in for a busy quarter — the convention stops being a habit and becomes a coordination problem. Each new person brings their own instincts about how to name things and where to draw boundaries, instincts formed on other projects with other conventions, all perfectly reasonable and all slightly different from yours. Nobody sets out to break the conventions. They simply do not know them, or know them imperfectly, or know them and forget them under deadline pressure, and each small deviation looks harmless in isolation. The model does not degrade in one dramatic event. It drifts, one reasonable-looking local decision at a time, until one day you open a package and realise that three people have modelled the same kind of thing three different ways and the model no longer speaks with one voice.

Why drift is so hard to see coming

The insidious thing about convention drift is that no individual instance of it is worth stopping. An architect names a service in a way that departs slightly from the pattern, and it would be faintly absurd to raise it — it is one element, the meaning is clear, everyone has a deadline. So it passes, as it should, because the cost of policing that single instance exceeds the cost of the instance. The problem is that the same reasonable calculation is made independently by everyone, all the time, and the sum of all those individually-justified passes is a model that has quietly lost its coherence. Drift is not a series of mistakes. It is the accumulated residue of a thousand sensible decisions not to make a fuss, and that is precisely what makes it so hard to govern: there is no villain and no single moment to point at.

By the time the drift is visible enough to alarm someone, it is expensive to fix, because inconsistency compounds. A convention that has been followed loosely for six months has produced content that other content now depends on. You cannot simply rename the odd elements and redraw the odd relationships, because diagrams reference them, other packages point at them, and downstream consumers of the model have built their own understanding on top of the inconsistent structure. Fixing drift late means untangling dependencies, and untangling dependencies means risk. So the fix gets deferred, the drift gets normalised, and the team quietly lowers its standard for what a consistent model looks like — which is the worst outcome, because a lowered standard drifts faster than a held one.

Convention drift is never a series of mistakes. It is the accumulated residue of a thousand individually sensible decisions not to make a fuss about one small deviation.

The temptation to solve it with rules

The instinctive response, when a team feels the drift starting, is to write it down. A modelling standards document appears, thirty pages of naming rules and decomposition guidance and relationship semantics, and everyone is asked to read it. This is not wrong, exactly, but on its own it rarely works, and it is worth being honest about why. A document is a snapshot of an agreement at one moment, and it is only ever read carefully once, if at all, usually on someone's first day when they have the least context to understand it. It does not travel with the work. It sits in a folder while the actual modelling happens elsewhere, and at the moment of decision — the moment an architect is naming a service under deadline — the document is not in the room. Its influence decays from the day it is published.

The second instinctive response is enforcement by a person: a lead architect who reviews everything and corrects deviations. This works, up to a point, and then it does not scale, because it makes one person the bottleneck for the whole team's consistency and burns them out in the process. It also arrives too late in the day. Review that happens long after the work is done catches drift only after it has already been built and depended upon, which is exactly when it is expensive to fix. And it puts the reviewer in the unhappy position of the convention police, which is corrosive to a team's relationships in a way that has nothing to do with the quality of the model. Neither the document nor the human enforcer is a bad idea; they are simply insufficient on their own, because consistency is not really a knowledge problem or an authority problem. It is a coordination problem, and it wants a coordination solution.

Consistency is a team problem before it is a tooling problem

This is the point that matters most, and it is the one teams most often get backwards. No tool makes a team consistent. Consistency is a shared intention held by people who have agreed what good looks like and who care enough to hold each other to it. If that intention is absent — if the team has never genuinely agreed on its conventions, or does not really believe in them — then no software will manufacture the agreement, and reaching for a tool first is a way of avoiding the harder human conversation about what the team actually wants its model to be. The agreement has to come first, and it has to be real.

But once the intention exists, tooling stops being irrelevant and becomes decisive, because the thing that defeats a genuine shared intention is not disagreement. It is friction and invisibility. Conventions erode not because people stop believing in them but because the environment makes it easier to deviate than to conform, and because deviations are invisible until they have accumulated into a problem too big to ignore. The right role for tooling is not to enforce the convention from above but to remove the friction of following it and to make deviations visible early, while they are still one element and still cheap to correct. Tooling that does that turns a shared intention into a maintainable reality. Tooling that pretends to be the intention itself, replacing agreement with automated rules nobody discussed, produces resentment and clever workarounds. The distinction is everything.

What CelinQ contributes, and what it does not

CelinQ does not hand you your conventions; those are yours to decide, and it would be presumptuous of any tool to claim otherwise. What it changes is the environment in which conventions either hold or erode, and it does so in a few specific ways that address the actual mechanisms of drift rather than the symptoms.

The first is that every change to the model is captured in a complete, ordered history. Drift thrives in the dark, on the fact that no one can easily see the accumulation of small deviations until it has become a large one. A full record of what changed, when, and by whom turns that darkness into something you can look at. It means a deviation is not an anonymous fact discovered months later in a package with no clear origin; it is a visible change with a time and an author, which makes it discussable while it is still recent and still cheap to address. The history does not fix drift, but it removes the invisibility that lets drift compound, and invisibility was half the problem.

The second is change review and governance. Because each architect works in their own local repository and their saves are synchronised into a shared workspace, there is a natural seam at which changes can be reviewed before they become part of the team's shared understanding, rather than long after. This is the crucial difference from the lone lead architect catching drift weeks late: review at the point of synchronisation catches a deviation close to the moment it was made, when correcting it means changing one element that nothing yet depends on, not untangling a web of dependencies that grew up around it. Governance that arrives early is proportionate and cheap. Governance that arrives late is expensive and adversarial, and the timing is determined entirely by where in the flow the review sits.

The third is roles. Not everyone on a growing team should have the same authority over the model, and pretending otherwise is a common source of drift. A structure of Viewer, Editor, Administrator, and Owner lets a team match authority to responsibility — so that the people who hold the conventions have the standing to steward them, and so that a new contributor's work flows through review rather than straight into the shared model as though they had been there for years. This is not about distrust; it is about giving a growing team the shape it needs to stay coherent, the same way any organisation gives more scope to people as they earn it. The roles make the team's actual structure legible to the tool, so the governance can follow the structure the team already believes in.

Why the merge matters for consistency, of all things

There is a less obvious contribution that is worth drawing out, because it connects consistency to the deepest part of the platform. CelinQ's merge engine reconciles the team's work at the granularity of individual model facts, deterministically and reproducibly, never by letting the last write silently win. This sounds like a purely technical property about not losing data, and it is that, but it also has everything to do with consistency, and the link is not obvious until you see it.

Consider what a crude reconciliation does to conventions. If two architects touch the same area and the tool resolves the overlap by simply keeping whichever save arrived last, then one person's careful, convention-respecting work can be silently overwritten by another person's hurried deviation, and nobody ever knows it happened. Consistency, under those conditions, is not just hard to maintain; it is actively unsafe, because the environment can destroy correct work without a trace. A team living with last-write-wins learns, correctly, not to trust the shared model, and a model nobody trusts is a model nobody bothers to keep consistent. Why polish something the system might quietly clobber tomorrow?

A merge that works at model-fact granularity, that is deterministic and reproducible, and that isolates genuine conflicts for a person to resolve rather than guessing, removes that particular corrosion entirely. Two people editing genuinely different things both succeed, and neither one's careful work is at the mercy of the other's timing. The only moments that require a human are the moments where two people really did change the same fact in incompatible ways, and those are surfaced honestly rather than resolved by accident. This is what makes it safe to invest in consistency at all: you can polish a package knowing the polish will survive, and a team that trusts the shared model to preserve their careful work is a team that keeps doing careful work. The merge does not enforce a single convention, but it makes the whole enterprise of maintaining conventions trustworthy, which is the precondition for anyone bothering.

The contractor problem, and the return

A particular version of the drift problem deserves naming because it is so common and so under-handled: the contractor brought in for a busy stretch and gone again three months later. This is the sharpest possible test of a team's conventions, because the contractor has the least exposure to them, the most pressure to produce quickly, and no long-term stake in the coherence of the model they are contributing to. None of that is a criticism of contractors, who are usually conscientious; it is simply the structural reality of a short engagement. They cannot absorb by osmosis a set of conventions that the permanent team holds mostly in its collective head, and they will be gone before the drift they introduce becomes visible in the ordinary course of things.

The mechanisms that address ordinary drift address this case with particular force. Because a new contributor works in their own local repository and their changes flow through review at the point of synchronisation, a contractor's work is examined close to when it is made, by someone who holds the conventions, before it becomes indistinguishable from everything else in the shared model. The roles make it natural for a short-term contributor to have exactly the scope their engagement warrants and no more, without anyone having to make an awkward decision about it case by case. And when the contractor leaves, the complete ordered history means their contributions are not an anonymous stratum of the model that nobody can later account for; they are attributable, reviewable changes with an origin. The knowledge of what they did does not walk out of the door with them, which is the usual and costly outcome.

Consistency and the confidence to refactor

There is a further connection between the platform's foundations and a team's conventions that is worth making explicit, because it runs against the grain of how people usually think about consistency. Holding conventions steady is not only about preventing new deviations; it is also about being able to repair old ones. A model that has drifted needs, periodically, to be brought back into line — elements renamed, structures regularised, a convention re-applied across a package that predates it. That kind of housekeeping refactoring is exactly the work that teams avoid, because in a fragile shared repository it feels dangerous. Touching a lot of elements at once, across an area other people also depend on, is precisely where the fear of clobbering someone's work or corrupting the model is strongest.

Because CelinQ reconciles at the granularity of individual model facts and preserves a full history, a large regularising change is far less frightening than it is in a single shared store. You can make the sweep in your own local repository at full speed, the reconciliation handles the overlap with other people's genuinely different work rather than pitting your save against theirs, and the history means the change is reversible and accountable rather than an irrecoverable event. The practical effect is that repair becomes thinkable. A team that can safely refactor its own model toward consistency will do it; a team that is frightened of its own repository will let the drift stand and lower its standard instead. Consistency, in the end, is as much about the courage to fix as the discipline to avoid, and courage is a function of how safe the environment makes the fixing.

Growth without a governance cliff

Put these together and the picture is a team that can grow without hitting the governance cliff that so many teams hit — the point at which the informal, in-your-head consistency of two people fails and there is nothing built to replace it. The history makes drift visible early. The review seam catches deviations while they are cheap. The roles give the team a structure proportionate to its size. The merge makes the shared model trustworthy enough to be worth keeping consistent. None of these is the convention itself; the convention remains a human agreement that the team has to genuinely make and genuinely believe in. What the platform does is make that agreement maintainable at a size where it would otherwise quietly fall apart.

The shift is worth stating plainly because it is easy to mistake for mere process. In a team without these supports, holding conventions is an act of constant vigilance by a few conscientious people, and vigilance is exhausting and unevenly applied and fails the moment those people are busy. In a team that has them, holding conventions becomes a property of how the work flows rather than a burden anyone has to carry personally. The deviation surfaces in the history without anyone hunting for it. The review happens at the seam where changes enter the shared model, as a normal part of the rhythm rather than a special intervention. The authority sits with the roles rather than resting informally on whoever happens to care most. Consistency stops depending on heroics, and anything that depends on heroics is one bad quarter away from collapse.

It is worth being honest about the limit of all this, because overselling it would be its own kind of drift. A team that does not actually agree on its conventions will not be rescued by any of these mechanisms; visibility of deviations is only useful to people who share a standard for what counts as a deviation, and governance is only welcome to a team that wants to be governed. The tooling amplifies a genuine intention and is useless in its absence. If the harder human work of agreeing what good looks like has not been done, the sensible thing is to do that work first and reach for the tool second. The order matters, and getting it backwards — hoping software will supply an agreement the team never made — is how governance initiatives fail.

Done in the right order, though, the effect is quietly transformative in the least dramatic way possible: the model simply keeps speaking with one voice as the team grows, and nobody has to become the convention police to make it happen. The consistency that was free when there were two of you does not stay free — that was never on offer — but it becomes cheap enough to maintain that a team of six holds its standard as steadily as a team of two once did. Consistency is a team problem before it is a tooling problem, and it always will be. The right tooling does not pretend otherwise. It just makes sure that a team which has solved the human problem is not defeated by the mechanical one.