CelinQ Insights · No. 74

Using AI to Explain Enterprise Architect Models to Non-Architects

A rigorous model and a sponsor who actually understands what it says are two separate achievements, and most repositories only manage the first one.

There is a moment familiar to almost every architect who has ever presented a model to someone outside the discipline. You have spent weeks getting the structure right — the components correctly decomposed, the interfaces correctly typed, the relationships correctly distinguishing dependency from association from realisation — and you open the diagram in front of a sponsor, a business stakeholder, or a steering committee, confident that the rigour will speak for itself. It does not. What the room sees is a dense arrangement of boxes and arrows in a notation they were never trained to read, and within about ninety seconds the conversation drifts away from what the model actually says and toward the one or two elements whose labels happen to be recognisable English words. The rigour that took weeks to build is, in that room, almost entirely wasted, not because the model is wrong but because the model was never written in a language that room could read.

Multiply that ninety-second drift across every steering committee, every funding review and every audit interview an organisation runs over a year, and the cumulative cost of the gap between what the model precisely says and what the room actually understands becomes substantial, even though no single instance of it ever shows up as a line item anywhere. Decisions get made on the strength of a half-remembered impression from a diagram nobody in the room could fully parse, rather than on the strength of the careful architectural work that diagram was meant to represent.

This gap is not a communication failing on either side. Enterprise Architect diagrams are precise instruments, and their precision comes from a formal notation that deliberately avoids the ambiguity of ordinary prose. A dependency arrow means something specific and different from an association arrow, and that specificity is exactly what makes the model useful for the people who need to reason rigorously about the architecture. But specificity of that kind is acquired through training, and most of the people whose decisions actually depend on understanding an architecture — budget holders, business sponsors, risk committees, auditors — have never had that training and have no reason to get it. Asking them to read the notation is asking them to learn a second skill just to receive information that a good architect could, in principle, restate for them directly. The trouble has always been that restating it well, for the right audience, at the right length, takes real time, and it is exactly the kind of task that gets compressed into a rushed five minutes before a meeting rather than done properly.

What the model already knows that the diagram does not say

The starting observation behind AI-assisted model explanation is the same one that underlies automatic diagram generation: the information a good explanation needs usually already exists in the model, recorded as element names, notes, stereotypes, relationships and tagged values. What is missing is not the content but the translation — turning a precisely typed graph of elements and relationships into continuous prose that answers the specific question a specific audience actually has. A sponsor asking "what does this package do and why does it matter to the business" is not asking for a list of components and their stereotypes. They are asking for a narrative that a diagram, however correctly drawn, was never designed to provide on its own.

Audience-specific explanations from the same source

The same package can honestly support several different explanations, because different audiences are asking different questions of it, and none of those explanations is more true than the others — they are simply answering different things. An executive summary answers "what is this, in business terms, and why should I care," compressed to a handful of sentences that a sponsor can absorb in the time it takes to glance at a slide, deliberately leaving out implementation detail that would only distract from the point being made. A business-language explanation goes one level deeper, describing what the package does in terms of business capability and process rather than technical structure, useful for a stakeholder who needs enough understanding to make a decision without needing to understand the architecture itself. A technical summary, by contrast, is written for an audience that does understand architecture but has not worked in this particular package before — a new team member, an auditor from another part of the organisation, a reviewer preparing for a governance board — and can safely use the vocabulary a business summary has to avoid.

A dependency summary answers a narrower, more specific question: what does this system rely on, and what relies on it, phrased as a readable account of the neighbourhood around a package rather than a raw list of relationship rows. A system-context explanation situates a package within the wider landscape it sits in — what feeds it, what it feeds, where its boundaries actually are — which is often exactly what a stakeholder needs when they are trying to understand the blast radius of a proposed change before authorising it. And an architecture-risk explanation, drawing on whatever the model actually records about lifecycle status, ownership gaps or known issues, gives a risk-focused audience a narrative account of concerns the model captures as scattered facts rather than as a coherent story, which is usually how a risk committee actually wants to receive that information.

Generated from a selected package, on request

The entry point for all of this, inside Enterprise Architect, is the same Analyze Selected Package menu item that drives duplicate detection and model-quality analysis, together with the more conversational Ask CelinQ AI entry point for a specific question rather than a general summary. An architect selects the package that needs explaining, chooses — or simply states in natural language — the kind of explanation the situation calls for, and CelinQ retrieves the model context relevant to that package: its elements, its notes, its relationships to the rest of the model, whatever tagged values the workspace's policy permits being used at all. That context, and only that context, is what an AI-assisted step draws on to produce the explanation, following the same pipeline used throughout the product's AI features — a proposal built from retrieved model context, not a general answer produced from the model's name alone.

An explanation is only trustworthy if you can check it. The point of grounding every sentence in a specific element or relationship is not thoroughness for its own sake — it is what lets a reader who does not trust the summary yet verify it against the model in thirty seconds instead of taking it on faith.

A worked scenario: one package, three readers

The value of tailoring the same underlying package to different audiences is easiest to see with a specific example. Take a package modelling a claims-settlement subsystem: a handful of components, an integration with an external payment rail, a fraud-scoring service, and a handful of tagged values recording lifecycle status and technology stack. A technical summary of this package, aimed at a new architect joining the team, would describe the component decomposition precisely — which component owns which responsibility, how the fraud-scoring integration is typed, what the tagged values record about the technology stack — using the vocabulary a trained reader expects and would find unnecessarily padded without.

An executive summary of the identical package, generated from the same retrieved context but aimed at a budget sponsor deciding whether to fund a modernisation initiative, would instead open with something closer to: this subsystem settles insurance claims and depends on one external payment provider and one fraud-detection service; the technology underneath is approaching the end of its supported life, which is the reason modernisation is being proposed now rather than in two years. Both summaries are true. Both are drawn from exactly the same underlying model facts. Neither is a simplification of the other so much as a different selection and ordering of the same evidence, chosen because a sponsor deciding on funding and an architect ramping up on the codebase are, quite reasonably, asking different questions of the same package. A dependency summary generated from that same context, aimed at a risk committee assessing vendor concentration, would foreground the single external payment-rail dependency in a way neither of the other two summaries needed to emphasise — because it is the fact that specific audience actually needed to act on.

Evidence links back to the model, not a black box

A generated explanation that reads well but cannot be checked against the model it claims to describe is not actually useful to an architect who has to stand behind it in front of a sponsor. This is why every substantive claim in a generated explanation is meant to be traceable back to a specific element, relationship or note in the source model rather than presented as an unattributed paragraph of prose. A sentence stating that a package depends on an external payment provider should be checkable against the actual relationship that grounds it; a sentence describing a lifecycle risk should be traceable to the specific status field or note that the claim is drawn from. This matters for a reason beyond simple diligence: an architect presenting a generated explanation in a governance meeting is professionally exposed if that explanation turns out to contain something the model does not actually support, and grounding every claim in a specific, checkable model fact is what lets an architect review a generated explanation quickly and confidently before ever putting it in front of an audience, rather than having to independently re-verify everything from scratch or simply trust the output blind.

This grounding requirement is also what keeps a generated explanation honest about the limits of what the model actually contains. If a package has thin documentation — components with no notes, relationships with no description of why they exist — a generated explanation of that package should read as thin too, rather than inventing plausible-sounding detail to fill the gap. An explanation that quietly manufactures context the model never recorded would be actively worse than no explanation at all, because it would give a non-architect confident, well-written prose about details nobody actually verified. The discipline here is the same one that runs through every AI-assisted feature in the product: retrieved context in, grounded proposal out, nothing invented in between.

No model changes required, ever

It is worth stating plainly what this capability does not do: generating an explanation never writes anything to the model. There is no change set to approve here, no revision created, no synchronisation triggered, because reading a package and describing it in prose is fundamentally a read-only operation, unlike diagram generation or refactoring, which propose actual changes for a human to approve. An architect can generate and regenerate explanations of the same package as many times as a presentation needs refining, in whatever combination of audience-specific forms is useful, without any risk of accidentally altering the underlying architecture. This makes explanation one of the lowest-risk AI-assisted capabilities in the product, precisely because its output is prose for a human reader rather than a proposed edit to a canonical model.

Privacy controls apply to explanation the same as anywhere else

Because generating an explanation means sending some amount of model context to an AI provider when the optional AI path is enabled, the same field-level policy that governs every other AI-assisted feature applies here without exception. A workspace's administrator controls, per capability, what categories of information are permitted to leave the boundary of the retrieval step at all — names and the minimum context needed for the requested explanation by default, with notes, tagged values and the wider model neighbourhood excluded unless a workspace's policy explicitly opts them in. An administrator can preview exactly what would be sent for a given explanation request before ever enabling the capability, which matters enormously for a use case whose entire purpose is to be shown to people outside the immediate architecture team — a sponsor, an external auditor, a public body's oversight committee — where the sensitivity of what gets sent to a third-party provider deserves real scrutiny before the capability is switched on at all.

Where a workspace's data sensitivity does not permit any external AI call at all, explanation generation simply is not available in that workspace, and nothing about the rest of the product's functioning changes as a result. This is the same AI-off boundary that governs every other optional AI capability: the deterministic core of CelinQ — synchronisation, Fusion, monitoring, presence, revision history — has no dependency whatsoever on the AI path, and neither, in a strict sense, does an architect's ability to write their own explanation of a package by hand, which remains exactly as available as it always was. What AI-assisted explanation adds, where it is enabled, is speed and audience-specific tailoring on top of a task an architect could always do manually and more slowly.

Iterating toward the explanation a specific meeting needs

A first generated draft rarely lands exactly right on the first attempt, and treating it as a single-shot output rather than the opening move in a short back-and-forth undersells what the capability is actually for. An architect preparing for a governance review might generate a technical summary, notice it dwells too long on an implementation detail nobody on that particular committee will care about, and ask for the same package explained again with more emphasis on the lifecycle risk and less on the internal component structure. Because each regeneration draws fresh from the retrieved model context rather than compounding edits onto a previous draft, the result stays grounded in the same underlying facts even as the framing shifts to match what a specific meeting actually needs. This iterative quality matters more than it might first appear, because the realistic alternative — an architect writing three different summaries of the same package by hand for three different meetings in the same week — is exactly the kind of repeated, low-variety writing labour that gets shortchanged when time is tight, which is usually when the summaries matter most.

It is also worth noting what iteration does not change: however many times an explanation is regenerated, in whatever framing, the underlying package remains untouched. The read-only nature of this capability means an architect can experiment freely with framing and emphasis, discard drafts that do not land, and settle on the version that actually serves the meeting, without any of that experimentation leaving a trace in the model's revision history or requiring anyone's approval along the way. That freedom to iterate without consequence is part of what makes the capability genuinely useful under time pressure rather than merely impressive in a demo.

The core works without any of this

It is worth being explicit that nothing about the value of a well-modelled package depends on generated explanation being available. An architect who prefers to write their own executive summaries, or who works in a sovereign workspace where external AI is blocked entirely, still has a fully governed, semantically synchronised, deterministically merged model to draw on — generated explanation is a convenience layered on top of that foundation, not a prerequisite for the foundation being useful. A restricted defence or public-sector workspace can disable AI entirely and lose access to fast, audience-tailored summaries while retaining everything else: sync, Fusion, monitoring, revisions, audit, the full deterministic model-quality analysis that requires no AI to run.

The honest limits

A generated explanation is a first draft written for a specific audience, not a finished communication an architect should hand over unread. It can misjudge tone — too technical for a sponsor, too simplified for a technical reviewer — and it can miss the one detail that a human presenter knows, from experience with this particular audience, actually matters most in this particular room, because that judgement depends on context the model itself does not and cannot record. An architect who has sat across the table from a specific steering committee before knows things about what will land and what will not that no retrieval of model facts can substitute for, and the sensible use of a generated explanation is as a strong starting draft to edit for that judgement, not as a final artefact to read aloud unreviewed.

There is also a subtler risk worth naming: fluent, well-structured prose reads as more authoritative than a diagram does, precisely because prose is the medium non-architects are used to trusting. A generated explanation that happens to omit a genuinely important risk — not because it invented anything false, but because the model itself never recorded that risk as a fact anywhere retrievable — can leave a reader more confident than the underlying evidence actually justifies, simply because it reads so cleanly. The grounding discipline described earlier mitigates this by making every claim checkable, but checking still requires someone to actually do it, and the ease of generating a polished explanation should not be mistaken for a reason to stop verifying what it says against the model before it goes in front of an audience who will make real decisions based on it.

None of this is a reason to avoid the capability; it is a reason to use it the way a competent architect would use any draft written by someone else on their team — read it fully, check the claims that matter most, and put your own name behind it only once you actually agree with what it says. The time saved is real, and it is significant, but it is time saved on the drafting, not on the professional responsibility of standing behind what gets presented. That responsibility was never going to be automated away, and nothing about this capability was designed to try.