CelinQ Insights · No. 85 · Last technically reviewed: August 2026

How to Resolve coArchi Conflicts

A conflict dialog is not a failure — it is coArchi correctly telling you it can't safely guess. Here is what to actually do when you see one.

Why the conflict happened in the first place

coArchi's Grafico format splits an Archi model into many small, per-asset XML files specifically so that most concurrent changes never collide — two architects editing two different elements are, from Git's point of view, editing two different files, and a Publish combines both automatically with no dialog at all. A conflict only appears when both architects touched the same file — the same element, the same relationship, the same diagram — since the last time both were in sync. That is a much narrower situation than "two people worked on the model at once," and it is worth internalising that distinction before you even open the dialog: most of a team's day-to-day work does not produce conflicts, and the ones that do are specifically about genuine overlap, not general activity.

A worked example

Take a concrete case. Two architects, both working from the same last-published state of an Application A element:

These two changes touch the same element's underlying file, but they change different properties — Owner in one case, Lifecycle in the other. Whether coArchi's own merge resolves this automatically or asks a human depends on exactly how the two properties are laid out inside that element's XML file and whether Git's line-based diff can tell the two edits apart cleanly; in practice, changes to genuinely different properties on the same element often do merge automatically, precisely because Grafico keeps each file small and Git's own text merge is reasonably good at combining non-overlapping line changes within one file. When it can, no dialog appears at all, and the result is exactly what you would want: Owner = Team Y, Lifecycle = Strategic, both changes kept.

Now change one detail:

This is a genuine conflict. Both architects changed the same property to different values, and there is no automatic way to combine "Team Y" and "Team Z" into a correct answer — someone has to decide. This is exactly the case coArchi's conflict dialog exists for, and it is the right outcome: a tool that guessed here, silently picking one architect's answer over the other's, would be actively worse than one that stops and asks.

What to actually do in the dialog

The instinct to just pick your own version, or to always defer to whoever published first, is understandable and usually wrong. A few habits make conflict resolution reliable rather than a coin flip:

It also helps to reduce how often you end up in the dialog at all, rather than only getting good at resolving it. Publishing more frequently — in smaller batches, rather than accumulating a day's worth of changes before sharing — shrinks the window in which two people can collide on the same concept. Agreeing informally on who "owns" which part of the model for a working session, the same convention distributed teams already use for other shared documents, prevents most of the genuinely contentious conflicts before they happen, even though coArchi obviously can't enforce that convention itself.

When a conflict is really a modelling disagreement

Occasionally what looks like a coArchi conflict is really two architects who disagree about the model, not a synchronisation accident. Team Y and Team Z might both have a real claim to owning Application A, and resolving the file conflict does not resolve the underlying governance question of who should actually own it. coArchi will faithfully let you pick a winner in the dialog, but it has no way to tell you the two architects need a five-minute conversation first — that judgement stays with the team, not the tool, whichever collaboration approach you use.

Related reading