CelinQ Insights · No. 09

Baselines, projects and parallel lines of work in one repository

Reconciling a project branch with the baseline without a manual merge marathon.

Every architecture practice of any size eventually confronts the same tension, and it is a tension born of success rather than failure. On one side there is the baseline: the current, agreed, authoritative description of how the enterprise is and how it is meant to be. This is the model that other people quote in decisions, the one a governance board has blessed, the version the organisation treats as true. On the other side there is a project: a specific initiative that is going to change some slice of that landscape, a new platform, a consolidation, a migration, and that needs to model its intended future state in detail before any of it is real. The project cannot be allowed to scribble directly on the baseline, because half-formed proposals would pollute the agreed truth and nobody could tell settled fact from speculative intent. But the project also cannot work in total isolation, because a design that drifts too far from the real landscape becomes a fantasy that will not fit back into reality when the time comes to land it.

So teams do what teams do: they make a copy. The project takes a snapshot of the baseline and works against it, off to one side, free to propose and revise without disturbing the agreed model. For a while this feels like the obvious solution and it works well enough. The project modellers get their sandbox, the baseline stays clean, everyone is happy. The trouble arrives later, and it arrives on the day the project's work is ready to fold back into the baseline, because both the project copy and the baseline have moved on since the copy was taken, and now somebody has to reconcile two versions of the same model that have diverged in ways nobody has been tracking. That day has a name in most practices, whispered rather than spoken: the merge marathon.

Anatomy of a merge marathon

It is worth describing the marathon honestly, because architects who have not lived through one tend to underestimate it and those who have tend to have quietly stopped branching at all to avoid it. When the project copy was taken, it was a faithful reflection of the baseline. Then two things happened in parallel and neither side watched the other. The project modelled its intended changes, restructuring components, adding relationships, refining the future state. Meanwhile the baseline itself kept living: other work landed in it, corrections were made, other projects folded their own results in, the agreed truth moved forward. By the time the project is ready to reintegrate, the two models are cousins rather than twins. They share an ancestor but they have each grown, and folding one back into the other means finding every place they differ and deciding, difference by difference, what the combined truth should be.

Doing this by hand is exactly as grim as it sounds. Someone, usually the most senior and therefore most expensive architect available, sits down with two versions of a large model and works through them element by element. For each difference they have to reconstruct what happened: did the project change this deliberately, or is this a place the baseline moved and the project simply never saw? Is this new relationship a considered part of the future state or an artefact of the copy being stale? Did both sides touch the same element, and if so, which intent should win, or should both survive? Every one of these is a judgement, every judgement takes context the reconciler may not have, and the sheer volume of them turns what should be an act of design into an act of tedious archaeology. The work is slow, it is error-prone in the specific way that tired people making hundreds of small decisions are error-prone, and its worst failures are silent.

The merge marathon is not merely slow. It is the one moment in a project's life where a mistake is most likely to happen and least likely to be noticed, because the person making the decisions is drowning in volume precisely when each decision matters most.

The silent failures are the real danger. A merge done by hand under time pressure loses things. A project change gets dropped because the reconciler misread it as noise. A baseline correction gets reverted because the project version looked more complete. Two contributions to the same element collapse into one and the loser vanishes without a trace. None of these announce themselves. The merged model looks finished, it gets blessed, and the loss surfaces weeks later when someone notices that a decision everyone remembers making is simply not reflected in the model, and nobody can say when it disappeared. This is the deep cost of the marathon: not the days it consumes, expensive as those are, but the erosion of trust in the model that follows from everyone knowing, somewhere in the back of their mind, that the last big merge probably lost something.

Why the pain is really a merge problem in disguise

Here is the observation that reframes the whole situation. The difficulty of running parallel lines of work is not fundamentally a difficulty of branching. It is a difficulty of merging. Branching is easy; anyone can make a copy. The hard part is bringing the copy back, and the hard part is hard entirely because the reconciliation is being done by a human doing work that is mechanical in its bulk and only occasionally genuinely a matter of judgement. If the mechanical bulk could be handled reliably and automatically, leaving the human to adjudicate only the genuine conflicts, the marathon would shrink to a manageable review. The reason teams fear parallel work is that the tooling they have makes the reconciliation entirely manual, so the fear is rational and the retreat from branching is a sensible response to bad tools rather than a failure of nerve.

This is the same problem, at a larger grain, that a good collaborative modelling engine already solves for everyday work. When two architects edit the shared model at the same time, their changes have to be combined, and the whole point of a proper collaboration engine is that this combination happens reliably rather than through one person overwriting the other. CelinQ's reconciliation, CelinQ Fusion, performs a deterministic, reproducible three-way merge at the granularity of individual model facts. Reconciling a project line of work with a baseline is that same operation writ large: two lines of development that share a common ancestor, brought back together by comparing each against what they both started from and combining the differences.

What three-way, fact-level reconciliation actually does

The phrase three-way matters, and it is the difference between real reconciliation and guesswork. A two-way comparison sees only the two current versions and has to guess at intent: this element differs between project and baseline, so which one is right? It cannot know, because it does not know where the two started. A three-way merge brings in the common ancestor, the state of the model at the moment the project line diverged from the baseline. With that ancestor in hand, the engine can distinguish the cases that a human otherwise has to reconstruct laboriously and error-prone by hand. If an element changed on the project side but not the baseline since they diverged, the project's version is the considered intent and it flows through. If it changed on the baseline side but the project never touched it, the baseline's version carries. If it changed on neither, nothing needs deciding. Only when both sides changed the same element in incompatible ways is there a genuine conflict, and that is the only case that actually requires a human judgement.

Working at the granularity of model facts rather than whole diagrams or whole files is what makes this precise enough to trust. If two people changed different attributes of the same element, that is not a conflict; both changes are kept, because they do not actually contradict. A cruder tool that compares at the level of a diagram or a document would see the element as touched on both sides and force a false choice between two versions that could perfectly well coexist. Fact-level granularity means the engine only raises a conflict when two changes genuinely cannot both be true, which keeps the pile of things a human must adjudicate as small as the situation honestly allows. Most of what made the old marathon exhausting was false conflicts, differences that a person had to examine only to conclude that both sides were fine. Remove those and what remains is the real work, which was always a fraction of the total.

Two further properties matter for anything that governs an authoritative model. The reconciliation is deterministic and reproducible: the same inputs produce the same result every time, which means the outcome of folding a project into the baseline is not a matter of who ran it, in what order, on which afternoon. It can be examined, and if examined again it will say the same thing. And deletions are handled explicitly through tombstones rather than by absence. This closes a notorious trap in naive merging, where something deleted on one side simply reappears because the other side still has it and the merge cannot tell an intentional deletion from a thing that merely was not added. A tombstone records that a fact was deliberately removed, so that a considered deletion in the project is respected when it lands in the baseline rather than being silently undone by the baseline's older copy.

A concrete shape for the abstract idea

The mechanics are easier to trust with a concrete situation in mind, so consider an ordinary one. A project is chartered to consolidate a scatter of overlapping systems into a single platform, and it takes its line of work from the baseline to model the target state in detail. Over the following weeks the project reshapes a cluster of application components, redraws the relationships between them, and retires a handful of interfaces that the consolidation makes redundant. Meanwhile the baseline does not stand still. A separate correction lands in the same broad area because someone noticed that an ownership attribute had been recorded wrongly for years, and an unrelated initiative adds a new integration to one of the components the project is also touching.

When the project reconciles, most of this sorts itself out without anyone deciding anything. The project's restructuring of components it alone touched flows straight through. The baseline's ownership correction, on an attribute the project never went near, carries into the result untouched. The retired interfaces, recorded as deliberate deletions rather than mere absences, stay retired rather than springing back to life because the baseline's older copy still remembered them. The one place that genuinely needs a person is the component that both sides changed in ways that interact: the project restructured it and the baseline added an integration to it. That is a real question about how the future state should accommodate a relationship that appeared after the project began, and it is surfaced as a conflict for an architect to resolve deliberately. One decision, made with the full picture in view, in place of an afternoon of reading two models side by side to find that one decision buried among a hundred non-events.

Baselines as first-class, not as frozen exports

Part of what makes the traditional marathon so grim is that the baseline itself is usually treated as a static thing, a version frozen and exported at a moment in time, against which the project's copy is later compared as though the baseline had politely stopped moving in the interim. It never did stop moving, and the whole difficulty flows from pretending otherwise. A more honest arrangement treats the baseline as what it actually is: a living line of work with its own ordered history, evolving continuously as corrections and other initiatives land in it. The project's line is simply another living line that shares an ancestor with it. Neither is a frozen snapshot; both are moving, and reconciliation is the operation of bringing two moving lines back into agreement given the point at which they parted.

Seeing both baseline and project as first-class lines of work, each with a complete and ordered history, is what lets the reconciliation be principled rather than a rescue operation. Because the history is continuous on both sides, the common ancestor is not a guess or a half-remembered export date; it is a known point in a recorded sequence. Because deletions are tombstoned rather than merely absent, the engine can tell an intentional removal from a thing that was never there. Because every change on both lines is attributable and ordered, a reconciliation that raises a conflict can show not just that two sides disagree but how each arrived at its position. The reintegration stops being an archaeological dig through two mysterious artefacts and becomes a comparison of two documented histories, which is a fundamentally more tractable thing to reason about and a far safer thing to approve.

Conflicts made visible instead of resolved in the dark

The word conflict has an unearned bad reputation in modelling, largely because most tools handle conflict so badly that people have learned to dread the word. But a conflict, properly understood, is not a failure. It is information. It is the tool telling you that two people, or two lines of work, formed genuinely incompatible intentions about the same part of the model, and that a human needs to decide which intent should prevail or how the two should be reconciled into something better than either. That is not a defect to be suppressed. That is exactly the decision an architect is paid to make, and the worst possible thing a tool can do is make it quietly on the architect's behalf by picking a winner and moving on.

The failure mode that must be avoided at all costs is last-write-wins, where the model simply keeps whichever change was saved most recently and the other is gone. Last-write-wins is not conflict resolution; it is data loss with a polite face, and it is precisely the mechanism behind the silent losses of the manual marathon. CelinQ Fusion never resolves a genuine conflict by guessing. It isolates the conflict explicitly, holds both sides, and presents the collision for a person to decide. When a project line is reconciled against the baseline, the automatic majority flows through untouched and the small set of true conflicts is surfaced for an architect to adjudicate with full context, seeing what the ancestor said, what each side did, and therefore what is actually in tension. The judgement is made once, deliberately, with the relevant information in front of the person, rather than hundreds of times under fatigue.

The change review and governance layer sits naturally on top of this. Because the reconciliation is legible and the conflicts are explicit, folding a project into the baseline can be an event that is reviewed and approved rather than a thing that happens in the dark corners of one architect's afternoon. An Administrator or Owner can look at what the reconciliation proposes, see how the conflicts were resolved, and approve the result into the shared workspace with a clear record of what happened. The complete ordered revision history means the reintegration is not a discontinuity where the model's memory resets, but simply another well-documented step in a continuous story, one that can be examined afterwards and, if something is ever questioned, traced back through.

The deeper shift: from big-bang events to a continuous rhythm

Once reconciliation is reliable rather than heroic, something changes about how a practice thinks about parallel work, and the change runs deeper than saved hours. The marathon exists partly because reintegration is so painful that teams put it off, and putting it off is exactly what makes it worse, because the two lines drift further apart with every week of delay and the eventual reconciliation grows in proportion to the divergence. It is a vicious circle: the pain encourages delay, and the delay increases the pain. When folding back is cheap and safe, there is no reason to delay it, and a project can reconcile with the baseline early and often, keeping the two lines close enough that no single reintegration is ever large or frightening. The big-bang merge at the end of the project dissolves into a steady rhythm of small reconciliations along the way.

That rhythm is healthier in every respect that matters. A project that reconciles regularly stays anchored to the real landscape and cannot drift into designing a future state that no longer fits the enterprise it is meant to change, because it keeps seeing what the baseline is doing. The baseline, in turn, gains early visibility of where the project is heading, so that other work can take account of it before it lands rather than being surprised by it. And the reintegration at the end, when it finally comes, is the last of many small merges rather than one enormous one, which is precisely how it should be. The organisation gets the thing it actually wanted from branching all along, the ability to explore and design in parallel without corrupting the agreed truth, without also getting the thing it dreaded, the periodic reckoning where all that parallel work has to be painfully stitched back together by hand.

It would be dishonest to pretend this makes parallel work free of judgement, and it should not. There will still be genuine conflicts, moments where a project's intended future and the baseline's evolving present have formed incompatible views of the same element, and resolving those still demands an architect who understands both and can decide well. That work is real and it is not going anywhere, nor should anyone want it to, because it is the part where architecture is actually practised. What changes is that this judgement is no longer buried under a mountain of mechanical reconciliation that never needed a human at all. The marathon was never really about the hard decisions; it was about the thousands of easy ones the tool refused to make. Hand those to a deterministic engine and let the architects spend their judgement where judgement is genuinely required, and parallel lines of work in a single repository stop being something a practice endures and become something it simply does.