CelinQ Insights · No. 79

AI-Assisted Conflict Resolution in Enterprise Architect Without Giving AI Control of the Model

Fusion resolves what it can prove safe and escalates what it cannot; only then may an AI recommendation appear beside a decision a human still has to make.

There is an obvious, seductive idea sitting at the intersection of merge conflicts and large language models, and it goes roughly like this: conflicts in a model are hard for a machine to resolve mechanically because they require judgement, and judgement is exactly the thing modern AI is supposed to be good at, so why not let the AI just decide. It is worth taking that idea seriously for a moment, because dismissing it out of hand would be too easy, and then explaining precisely why CelinQ does not build it that way, because the reasoning matters more than the conclusion.

The trouble with letting AI decide a conflict outright is not that AI is unreliable in some vague, general sense. It is that a merge decision in an architecture model is not really a single judgement call — it is a claim about what actually happened in reality, made on behalf of two people who are not in the room to confirm it. When two architects both change the lifecycle status of the same application component to different values, the correct resolution depends on which of them was reflecting a decision that had actually been made, and that fact does not live in the model. It lives in a meeting, an email thread, or someone's memory. An AI asked to resolve that conflict outright is not reasoning about the model; it is guessing about a fact it cannot access, and presenting that guess with the same confident fluency it would use for a fact it could access. That confidence is the dangerous part. A wrong guess delivered fluently is more damaging than an honest "I don't know," because it is more likely to be believed.

Deterministic first, by construction rather than by policy

CelinQ's answer is to make deterministic resolution do as much of the work as it possibly can before AI is ever consulted, not as a matter of preference but as a matter of architecture. The Fusion engine classifies every incoming change against the current state of the model using a fixed rule matrix, and the overwhelming majority of concurrent edits resolve automatically because they are not actually in conflict at all once you look at them at the right granularity. Two architects editing different scalar fields on the same element — one updating a description, another updating a status — are recognised as disjoint property writes and merged without anyone being asked anything. A rename combined with a move is recognised as a single coherent operation rather than two colliding ones. A tagged-value map with different keys touched by each side merges cleanly because the keys do not overlap. None of this is AI. It is graph-aware, rule-based logic operating on the specific shape of what changed, and it is the same logic described in detail in the articles on merge atoms and model-aware merge rules.

This automatic tier is formally proven safe rather than merely assumed safe, which CelinQ's engineering documentation labels F0 — decisions a deterministic proof establishes as compatible, with no ambiguity to resolve. A second tier, F1, covers decisions that are safe only because a workspace has explicitly adopted a policy that makes them safe — a rule that the last writer to a diagram object's geometry wins when two people move the same shape in ways that would otherwise conflict, for instance, adopted deliberately by a workspace that has decided that outcome is acceptable for its own working style. Both F0 and F1 resolve automatically, and both record exactly which rule did the resolving, on the revision, so that "the system decided this was safe" is never an unverifiable assertion — the proof-carrying record described in the proof-carrying merges article means anyone can look at a resolved conflict later and see precisely why it did not need a human.

Where AI actually enters: after F3, never before it

What remains after F0 and F1 have done everything they safely can is the genuinely hard category — F3, a human decision required, because no deterministic rule can establish that a particular resolution is safe without knowing something about intent that only a person has. A scalar field changed to two different values by two different people. A package deleted by one architect while another created new children inside it. Two structural moves of the same element to different destinations. These are the cases CelinQ never tries to resolve automatically, because doing so would mean guessing at intent and presenting the guess as fact, exactly the failure mode this article opened with.

It is only once a conflict has been classified as F3 — genuinely requiring a human, with no safe automatic path available — that an AI advisor may be consulted at all, and this ordering is not a convention that could drift over time; it is enforced by the flow of the code itself, where the deterministic engine's classification happens first and completely, and only its output is available to the advisory layer afterwards. This is what the plan for this article calls F2: not a fourth tier that resolves conflicts automatically, sitting between the deterministic tiers and human judgement, but an optional annotation that can be attached to an F3 case that a human is already going to decide. Calling it a "tier" is slightly misleading if it suggests AI gets a turn at automatic resolution the way F0 and F1 do — it does not. F2 is best understood as advisory ink on top of an F3 capsule: a labelled, confidence-qualified suggestion that the human resolving the capsule may read, weigh, and disregard, never a decision that takes effect on its own.

What an F2 recommendation actually contains

When a workspace has enabled AI-assisted conflict recommendations and a genuine F3 capsule is raised, the request built for the advisor follows the same minimum-necessary policy described throughout this AI cluster: the entity name, the specific field in conflict, and the competing values, without the broader neighbourhood of notes and unrelated tagged values that are not needed to say anything useful about this particular disagreement. The advisor's response comes back as a labelled suggestion — which value it considers more likely correct, and why, expressed with an appropriate degree of hedging rather than false certainty — and it is displayed next to the capsule, not instead of it. The resolution options presented to the human are exactly the same ones available in a workspace with AI disabled entirely: keep the mine-side value, keep the server-side value, restore the original state, restore as a new element, or restore to the parent, the same vocabulary used across every Fusion capsule regardless of whether an AI suggestion happens to be present.

The distinction that matters most here is what the recommendation is not permitted to do. It cannot pre-select an option. It cannot auto-apply after a timeout if the human does not respond. It cannot be configured to apply automatically above some confidence threshold, because a confidence threshold is exactly the kind of numeric-sounding reassurance that quietly reintroduces automatic AI resolution through the back door, and CelinQ does not offer that configuration at all — there is no setting that turns an F2 suggestion into an F0-equivalent auto-merge, because doing so would collapse the very distinction this design exists to protect.

An AI recommendation that a human can override in theory but that quietly shapes every decision in practice is not really advisory. CelinQ keeps the resolution actions, the audit trail, and the human's attention identical whether or not a recommendation is present, so that "advisory" describes what actually happens, not just what the interface claims.

A worked example: the status field that went two ways

It helps to follow one concrete conflict all the way through, because the tier names can start to feel abstract without a scenario attached to them. An architect working from a client site changes an application component's lifecycle status from "Active" to "Retiring," reflecting a decommissioning decision made in a steering meeting that morning. At the same time, a colleague back at the office, unaware of the meeting, updates the same element's description field to correct a typo, and separately touches a tagged value recording the technology platform. Three changes land on the same element from two people working concurrently.

Fusion decomposes this into its constituent atoms rather than treating the whole element as one contested object. The description correction and the tagged-value update touch fields the first architect never touched, so those resolve immediately as disjoint property writes — F0, proven, recorded, no capsule raised, nobody's attention required. The status change is different: had the second architect also touched status, there would be nothing to disagree about; but in this scenario status was only touched on one side, so it is not actually a conflict at all, and it too applies cleanly. Change the scenario slightly — suppose the office-based colleague had also updated status, to "On Hold," reflecting a different, earlier conversation — and now the two status values genuinely collide. That single field, and only that field, becomes an F3 capsule. Everything else that happened to the same element in the same window has already been merged and is not waiting on anyone.

If conflict recommendations are enabled for the workspace, the capsule may carry an F2 suggestion: a short note observing, for instance, that the "Retiring" value was recorded more recently and asking whether that reflects the latest decision. The architect resolving the capsule reads it or does not, checks their own knowledge of the steering meeting against it, and picks one of the standard resolutions. Nothing about the suggestion shortens the list of options or pre-fills a choice. What it does, when it is useful, is save the person a small amount of the investigative work of figuring out which change is more likely to be current — work a human would otherwise do by checking timestamps and asking around, compressed into a sentence they can accept, adjust, or dismiss entirely, without the tool ever pretending to know something it does not.

Why this boundary is a trust decision, not just a technical one

It would be possible to build a more aggressive version of this feature — one where a sufficiently confident AI recommendation applies itself after a short grace period unless a human intervenes, framed as a convenience for busy teams. CelinQ deliberately does not offer that mode, and the reasoning is about what kind of trust a merge system needs to earn over time. A team that discovers, months into using a tool, that some fraction of its "human-reviewed" conflicts were actually auto-applied by an AI recommendation nobody explicitly approved has every reason to stop trusting the audit trail altogether, because the trail no longer means what it claims to mean. Once that trust is gone, teams tend to overcorrect by distrusting even the genuinely safe F0 and F1 automatic merges, which is a much worse outcome than the modest convenience an auto-apply mode would have bought. Keeping F2 strictly advisory, with no configuration path to anything stronger, protects the credibility of the entire Fusion pipeline, not just the AI-assisted corner of it.

Root-cause grouping and the honesty of not multiplying advice

Some of the hardest conflicts to resolve well are not single, isolated disagreements but cascades: a package deleted by one architect while a colleague, working offline, created several new elements and diagrams inside it. Resolved naively, this produces dozens of technical conflicts — one for each derived element, connector, and diagram affected by the deletion — even though they all trace back to the same underlying decision. CelinQ's root-cause grouping, covered in full in the article on turning many technical conflicts into one human decision, collapses these into a single capsule wherever the derived conflicts genuinely share one cause, so a person resolves the real question once rather than working through a list that obscures how repetitive it actually is.

This matters for the AI boundary specifically because a poorly designed system might be tempted to generate a separate AI recommendation for each of those dozens of derived conflicts, producing a wall of advisory text that looks thorough but actually adds noise rather than clarity. CelinQ's grouping happens before any AI involvement, which means an F2 recommendation, when one is generated for a grouped capsule, addresses the actual root-cause question — was this package genuinely meant to be deleted, given that new work was added to it — rather than producing twenty near-duplicate suggestions about twenty symptoms of the same cause. Restraint here is not an incidental benefit of grouping; it is a direct consequence of doing the deterministic structural analysis first and only asking AI a well-posed question once that analysis is complete.

The path with AI switched off remains the same path, not a fallback

It is worth stating plainly what happens to conflict resolution in a workspace where AI has never been enabled, or where sovereign mode has removed it entirely, because the honest answer is: nothing changes about the resolution process itself. F0 and F1 resolve exactly the same share of conflicts automatically, because they never depended on AI to begin with. F3 capsules are raised in exactly the same circumstances, with exactly the same root-cause grouping, exactly the same resolution options, and exactly the same audit trail. The only thing absent is the labelled suggestion beside the capsule. This is not a degraded fallback mode that AI-enabled workspaces have grown past; it is the complete, self-sufficient design that AI-enabled workspaces are also running, with one optional layer of convenience added on top. Describing the AI-off path as a "fallback" would imply the AI-on path is somehow more correct, and that is precisely the framing this article is trying to avoid — the deterministic path is not a lesser version of the AI-assisted one. It is the whole thing, and the AI-assisted one is the deterministic path plus a suggestion a human is free to ignore.

Full audit regardless of which path a resolution took

Every conflict resolution, whatever tier resolved it, becomes part of the same revision history that the rest of CelinQ's audit and governance features rely on: which rule or policy resolved an F0 or F1 case automatically, or which human made which choice on an F3 capsule, and when. Where an F2 recommendation was involved, the audit record additionally notes that a recommendation was requested and shown, following the same conservative logging discipline as every other AI-assisted feature in the product — the fact of the recommendation is recorded, not a permanent copy of its full text folded into the model's own history. An organisation reviewing how a disputed decision was actually made can always answer two separate questions cleanly: what did the deterministic engine conclude, and did a human have an AI suggestion in front of them when they made their choice. Keeping those two questions separately answerable, rather than blended into one ambiguous record, is what makes the audit trail actually useful during a real governance review rather than merely present for the sake of appearances.

Honest limits

This design trades away something real in exchange for the safety it provides, and it is worth naming directly. An AI capable of resolving F3 conflicts outright, if it could be trusted to do so reliably, would save human attention that this design deliberately continues to spend — every genuine F3 conflict still needs a person, with or without a suggestion beside it, and for a very large, busy workspace that is a real, ongoing cost measured in the minutes architects spend making calls the system could not make for them. CelinQ's position is that this cost is the right one to pay, because the alternative is a system that occasionally, silently, confidently gets the underlying fact wrong, and a wrong automatic decision about which colleague's change reflected reality is a worse failure than an honest request for a human's time. Whether that trade is right for a particular team is a judgement about risk tolerance the team has to make for itself, informed by how often its genuine conflicts turn out to hinge on information the model itself could never have contained. What CelinQ will not do is make that trade invisibly, by quietly raising an AI's confidence threshold into a substitute for the human decision the deterministic engine correctly identified as necessary.

There is a second, quieter limit worth naming: an F2 recommendation is only as good as the narrow slice of context it is permitted to see under the workspace's field-level policy, and a workspace that has restricted that policy tightly for good reasons will get correspondingly thinner, more cautious suggestions than a workspace with a more permissive policy. That is the correct trade-off given everything the secure AI article describes about minimum-necessary data sharing, but it does mean the value of the F2 layer is not uniform across an organisation — it is deliberately shaped by the same governance decisions that shape everything else about how AI touches that particular workspace, and a team should not expect a tightly governed workspace's recommendations to be as detailed as a more permissive one's. That unevenness is a feature of consistent governance, not a bug to be engineered away.

Finally, it is worth being clear about what a recommendation can never carry, however well it is phrased: accountability. When a capsule is resolved, the audit record names the person who resolved it, and that name means something precisely because the decision was theirs. A team that grows into the habit of accepting every suggestion without reading it has not automated its conflict resolution; it has laundered an automatic decision through a human signature, and the audit trail will faithfully record a diligence that was not actually exercised. The design can surface the evidence, keep the advisory clearly marked, and refuse to auto-commit — but it cannot make anyone read before they click. That last step of genuine attention is the one contribution the tooling cannot supply, and an organisation adopting AI-assisted resolution should say so out loud when it introduces the feature, so that the convenience never quietly becomes the decision-maker.