CelinQ Insights · No. 65

AI-assisted Enterprise Architect model analysis: finding problems before the review meeting

The most useful thing an analysis tool can tell you is not an opinion. It is where to look, and why.

There is a specific, dreaded moment in architecture governance that most experienced architects have lived through more than once. You are two minutes into presenting a package you thought was solid, and a reviewer asks a question you cannot answer cleanly: "what owns this component?", or "why does this depend on something three layers away that looks unrelated?", or simply "is this actually still used by anything?" The honest answer, too often, is that you do not know, because the package has been touched by four people over two years and nobody has looked at the whole of it with fresh eyes since. The review meeting becomes the moment the problems are discovered, in front of an audience, rather than the moment they are confirmed and discussed, which is what a review meeting is actually for. This article is about closing that gap — finding the orphaned element, the missing owner, the naming drift and the circular dependency before the meeting, not during it — and about being precise regarding which part of that work is deterministic checking and which part is AI doing something a rule cannot.

Two different kinds of finding, and why the difference matters

It is tempting to describe model analysis as a single capability, but doing so obscures the distinction that actually makes it trustworthy. Some things a model can tell you about itself with total certainty, because they are structural facts a program can check exhaustively: an element with no incoming or outgoing relationships is, by definition, orphaned, and no interpretation is required to establish that. Two elements with identical names and the same type are, at minimum, worth flagging as possible duplicates, because the coincidence is itself a fact, checkable without ambiguity. A containment cycle either exists in the tree or it does not. These are deterministic findings — the kind CelinQ's own shadow validation already relies on when it checks a proposed change for containment cycles and dangling references before committing it, described in the series' coverage of AI for Sparx Enterprise Architect — and the same category of check, run as a standing pass over an existing model rather than only at the moment of a write, is what a rule-based analysis over your repository can offer without needing AI at all.

Other things a model cannot tell you with the same certainty, because they require interpreting what the structure means rather than merely observing that it exists. Whether a dependency represents a genuine architectural coupling worth worrying about, or an incidental reference that happens not to matter, is a judgement call that depends on context a graph traversal does not have access to. Whether a cluster of similarly-named elements represents careless naming or a deliberate, well-understood pattern your team uses is likewise not something structure alone settles. This is where a grounded AI reading adds something a rule cannot: not a more sophisticated rule, but an interpretation, offered as a suggestion rather than a fact, of what a structural pattern might mean — always clearly distinguished from the deterministic findings sitting alongside it, never blended into a single undifferentiated list where a certain fact and a plausible guess look the same on the page.

What deterministic checking already does

The invariants CelinQ's validation already enforces on every write are a smaller and stricter set than a full model-quality analysis needs, but they establish the discipline the rest of a rule-based pass follows: parents must exist, relationship and diagram endpoints must resolve, containment must not cycle, identity must stay unique. Extending that same disciplined checking into a broader standing analysis — orphan detection across a whole package, missing-ownership checks against your organisation's tagging convention, naming-pattern conformity, dangling references left behind by an incomplete edit — is a natural direction for the same deterministic layer to grow into, because none of those checks require anything beyond graph traversal and pattern matching over facts the model already contains. A check like this either finds the thing or it does not; it does not have an off day, it does not phrase an uncertain finding more confidently than the evidence supports, and running it again tomorrow on the same model produces the identical result it produced today.

This matters enormously for the kind of finding that ends up in a governance report, because a governance report that says "fourteen elements have no recorded owner" needs to be exactly right, not approximately right, or it undermines the credibility of everything else in the report alongside it. Deterministic checks are the right tool for exactly this category of finding — countable, checkable, arguable only about the policy behind the rule (should every element really need an owner?) and never about whether the finding itself is accurate.

Where a grounded AI reading adds something different

A deterministic pass tells you that fourteen elements lack an owner. It does not tell you which of those fourteen matters most, or notice that six of them cluster around a part of the model that looks, structurally, like it was meant to be retired but never formally was, or that a naming pattern shift halfway through a package coincides with a change of author visible in the revision history — the kind of pattern a person skimming the whole picture might notice and a rule checking one invariant at a time would not surface on its own. This is the territory where a grounded model summary, of the kind described in the series' earlier piece on reading an unfamiliar landscape, earns its place, reading across the deterministic findings and the surrounding model content to offer a plain-language account of what the pattern might mean, clearly marked as an interpretation rather than a fact.

The word grounded is doing real work in that sentence, and it deserves to be taken seriously rather than treated as marketing gloss. A grounded reading is built from the model's actual content — the real element names, the real relationships, the real findings the deterministic pass already produced — rather than from a generic account of what architecture problems typically look like. When a summary names a specific element and a specific dependency, that element and that dependency genuinely exist in your workspace; the summary is not permitted to invent a plausible-sounding example to illustrate a general point, because doing so in the context of a specific customer's repository would be actively misleading rather than merely imprecise. Verified generation of this kind, run against a real demonstration workspace during development, produced a summary that named real elements and a real structural risk with no fabricated content — which is the standard the capability is held to, not an aspiration attached to it after the fact.

A rule tells you a fact about the model. A grounded reading tells you what a person who had time to look at the whole picture might notice about the pattern those facts form. Confusing the two is how a governance report loses its credibility.

Naming inconsistencies and lifecycle drift

Two categories from the plan for this kind of analysis deserve specific attention, because they sit right on the boundary between deterministic checking and interpretation. Naming inconsistency — "OrderSvc" beside "Order Service" beside "orderservice_v2" — is partly a rule problem, in that a pattern-matching pass can flag elements whose names deviate from a documented convention or cluster suspiciously close to another element's name without matching it exactly. But deciding whether "OrderSvc" and "Order Service" are the same thing under two names, two genuinely different things that happen to sound similar, or a rename that never finished propagating through the model, is exactly the kind of ambiguous case a rule should surface rather than silently resolve, and exactly the kind of case a grounded reading — looking at what each element connects to, not just what it is called — can offer a useful, clearly-labelled opinion on.

Lifecycle inconsistency works the same way. A rule can check, mechanically, whether an element's recorded status field is internally coherent — flagging something marked "Retired" that still carries active relationships, for instance, which is a structural contradiction a check can find with certainty. Whether a component's status genuinely reflects its real-world state — whether something marked "Active" has in fact quietly fallen out of use, or whether ageing technology tagged against an element represents a live risk or a documented, accepted exception — depends on operational knowledge the model was never asked to capture, and no reading, deterministic or AI-assisted, should claim to know it. The honest boundary here is the same one that runs through the whole series: the model can tell you what it says about itself, faithfully and completely; it cannot tell you whether what it says is still true in the world, because that is a fact about the world, not about the model.

Duplicate detection, done carefully

Duplicate and near-duplicate detection — the same concern that matters enormously during generation, covered in generating a model from a prompt — applies equally to analysing a model that already exists, and arguably matters more there, because a repository that has accumulated duplicates silently over years has no generation-time reuse check to have caught them in the first place. A deterministic pass can flag exact-name matches, near-name matches above a similarity threshold, and elements that share an unusual number of relationships or tagged values in common, all without needing AI to do any of it — these are countable, mechanical signals. What a rule cannot safely do on its own is merge anything; duplicate detection of this kind should always produce a list of candidates for a human to confirm, never an automatic consolidation, because merging two elements that were only superficially similar destroys information a rule has no way to know it is destroying, and because the two elements' full history of relationships and dependents needs a person's judgement to reconcile safely, not a similarity score's confidence that it found a match.

A package, walked through

It is easier to trust this distinction once it has been applied to something concrete, so take a package that will be familiar in shape to almost any architect who has inherited someone else's work: a claims-processing area, built up over three years by four different people, due for a governance review in a fortnight. Run the deterministic pass first, because it is the part with no ambiguity to argue about. It reports six orphaned elements — no incoming or outgoing relationships at all — three of which turn out, once you actually look, to be old reference types nobody deleted after a refactor two years ago, and three of which are more interesting: recently created elements that were plainly meant to connect to something and never did, most likely an edit that stalled halfway. It reports nine elements with no recorded owner against your organisation's tagging convention, four dangling relationship endpoints left over from a delete that predates CelinQ's own tombstone handling, and one containment cycle, which by definition should not exist and turns out to be exactly the kind of thing that only happens through a data-migration artefact rather than anyone's deliberate edit.

None of that list required interpretation to produce, and none of it is arguable in the way a judgement call is arguable — either the relationship endpoint resolves or it does not, either the owner tag is populated or it is empty. What it does require is triage, and this is where the value of having the list two weeks before the meeting rather than during it becomes concrete: the three stale reference types can be safely retired in an afternoon, the three stalled elements need a conversation with whoever was working in that area last, the nine missing owners are mostly a matter of five minutes' tagging once someone with the right knowledge sits down, and the containment cycle needs investigating properly before the meeting rather than being discovered live in front of a reviewer. A grounded summary layered on top of the same findings might additionally note that the stalled elements and four of the missing-owner elements cluster around the same sub-package, which is the kind of pattern worth mentioning in the meeting — "this corner of claims processing looks like it lost its owner around the same time" — precisely because it is the sort of observation that comes from looking at the whole picture rather than checking one invariant at a time, offered as a suggestion for the architect to confirm, not as an established fact standing alongside the six orphan elements that are.

Turning findings into a review report

Two weeks and a fortnight's worth of triage later, the same package walks into its governance review in a genuinely different state: not perfect, because a three-year-old claims package built by four people is never going to be perfect, but honestly accounted for, with the stale references gone, the stalled elements either connected or explained, most of the ownership gaps closed, and the one real structural anomaly already understood rather than freshly discovered in front of the room. That is the entire value proposition of doing this ahead of time rather than during the meeting — a reviewer's question met with an answer instead of a promise to look into it, rather than a cleaner model in some abstract sense.

The practical output of running this kind of analysis ahead of a governance review is a report an architect can walk into the meeting already holding, rather than assembling reactively while a reviewer waits: the deterministic findings, precise and countable, listed plainly — orphan elements, missing owners, dangling references, naming and lifecycle contradictions — alongside a grounded summary that draws attention to the patterns among them worth discussing first, each clearly labelled for what it is. This is a materially different starting position than walking into a review meeting having last looked closely at the package six months ago. The questions that used to catch an architect off guard — what owns this, why does this depend on that, is this still in use — have answers prepared in advance, or an honest "the model does not record that" where the model genuinely does not, which is itself a more useful answer than an improvised guess offered under pressure.

The AI-off path stays complete

Everything in the deterministic category described above — orphan detection, missing-ownership checks, containment-cycle detection, exact and near-duplicate flagging, lifecycle contradiction checks — runs with AI switched off entirely, because none of it depends on AI to begin with; it is the same category of structural checking CelinQ's shadow validation already performs on every write, extended into a standing pass rather than a one-time gate. A workspace running in Sovereign mode, or one where an administrator has simply chosen not to enable AI, loses only the grounded prose summary layered on top — the interpretation of what the findings might mean — and keeps every deterministic finding intact.

This matters most for exactly the organisations that need model analysis the most seriously — regulated environments, public-sector clients, defence and healthcare contexts where sending model content to an external provider is either forbidden outright or requires a level of approval no project timeline can wait for. Those organisations can run the entire deterministic analysis layer, get the full list of orphaned elements, missing owners, dangling references and naming contradictions, and prepare for a governance review with real evidence, without a single byte of model content leaving their infrastructure. The AI layer, when it is available and enabled, adds an interpretive summary on top of findings that already exist; it is never the thing that makes the findings possible in the first place. The pattern of keeping analysis private end to end, including a customer-hosted model rather than a public provider, is covered in more depth in how CelinQ can analyse a repository without sending it to an external AI.

The honest limits

The most important limit to state plainly is the one implicit throughout this article: a finding, deterministic or AI-assisted, is a signal, not a verdict. An orphaned element might be genuine debt, or it might be a deliberately standalone reference type that has no relationships by design. A flagged duplicate might be two genuinely distinct things that happen to share a name by coincidence, common enough in large repositories built by different teams over different years. Treating every finding as automatically actionable, without an architect's judgement applied to each one, would trade the old problem — nobody looked closely enough — for a new one: everybody looked, but nobody thought about what they were looking at. The analysis is valuable precisely because it directs attention efficiently, not because it replaces the attention itself.

There is a second limit worth naming honestly, because it is easy to let a fluent AI summary earn more trust than it has demonstrated it deserves. A grounded reading is only as good as its discipline about staying inside what the model actually supports, and the responsibility for maintaining that discipline sits with the system generating the summary, not with the reader's ability to catch an overreach — precisely because the reader, asking about an unfamiliar corner of the model, is often not in a position to catch a confident-sounding but unsupported claim. This is why a grounded summary is designed to describe what the structure shows rather than assert why it got that way, or whether it is safe, or what should be done about it — those are questions for the architect reading the report, informed by the findings but not answered by them.

Finally, no analysis of any kind, deterministic or AI-assisted, substitutes for the review meeting itself. The goal of finding problems before the review is to change what the meeting spends its time on, not to make the meeting unnecessary. A well-prepared architect walking in with a clean report and a grounded summary in hand is still the one making the case for what the findings mean and what should happen next; the analysis got them there faster and with fewer surprises, and that is the whole of what it honestly promises. For a discipline that has spent years being caught out by exactly the kind of question a closer look would have anticipated, that is not a small thing to offer, even though it is a modest one.