CelinQ Insights · No. 67

Natural-Language Queries for Sparx EA: Asking Your Architecture Model Questions Through CelinQ

A question like "which applications depend on Oracle" is really a graph traversal wearing plain English, and the honest way to answer it keeps the traversal deterministic while the language model stays strictly downstream.

Every architect who has sat through a governance meeting knows the moment. Someone asks a perfectly reasonable question — which applications still depend on the Oracle instance we are decommissioning, which systems in the portfolio have no listed owner, which services touch the payment platform — and the honest answer is "give me twenty minutes." Not because the information does not exist. It almost always exists, scattered across relationships and tagged values in the repository. It is that getting to it means opening Enterprise Architect, remembering which query or search feature covers this particular question, possibly writing a bit of SQL against the underlying database if the built-in tools do not stretch that far, and running it while the room waits. The gap is not between having the data and not having it. It is between the shape the data lives in and the shape the question was asked in.

That gap is exactly what a natural-language query layer is meant to close, and it is worth being precise about what closing it actually requires, because the term invites a lazy shortcut. The lazy version hands the whole model to a language model and asks it to answer questions about what it read. That approach is fast to build and unreliable in exactly the way that matters most for architecture governance: it can produce an answer that sounds complete and confident while being subtly, silently wrong, because a language model summarising a large body of text does not check its own arithmetic and has no way to guarantee it saw every relevant relationship. CelinQ's answer keeps the two halves of the problem apart — understanding what was asked, and answering it correctly — and only lets a language model near the first half.

Three questions, and what they really are underneath

Take "which applications depend on Oracle." Underneath the plain English, this is a graph query: start from the technology or platform element representing Oracle, follow dependency and usage relationships inward, and collect the distinct set of application elements reachable by that traversal, filtered to relationships of the right type so that a passing mention in a note does not get counted as a dependency. It has a precise, checkable answer, and running it twice against an unchanged model should produce the same list both times.

Take "which systems have no owner." This one is a filter rather than a traversal. Walk every element classified as a system or application, check whether the field the organisation uses to record ownership is populated, and collect the ones where it is not. Simple, but only simple once someone has correctly identified which field counts as "owner" for a given workspace's conventions, because different organisations tag this differently, some using a formal Owner attribute, others a tagged value, others a relationship to a business-role element. Getting the filter right is a modelling-conventions problem, not a language problem.

Take "show applications connected to payment services." This combines both: identify the elements that match "payment services" — probably by name pattern, stereotype, or membership in a particular package — and then traverse outward from each of them to find connected applications, again constrained to relationship types that represent a real architectural connection rather than an incidental one. Three different questions, each resolving to a different underlying operation, and not one of them requires anything resembling reasoning about meaning once the mapping from English to structure has been made. The hard work is entirely in that mapping, and in the traversal and filtering logic underneath it — never in guessing the answer.

Deterministic query generation

This is the core discipline CelinQ applies to the whole idea of asking a model questions in plain language: the step that turns a question into an actual query against the graph must itself be deterministic and inspectable, even when a language model is involved in producing it. In practice this means the flow works less like "the AI reads the question and gives you an answer" and more like "the AI (where enabled) helps translate a question into a structured query against the model's typed query surface, and that structured query is what actually runs, against the canonical model, producing a result set that traces back to specific elements and relationships." The distinction sounds subtle until you consider what it rules out: an AI component in this design cannot silently miscount, cannot include an element it merely thinks belongs, and cannot omit one it should have found, because the counting and the finding are not things it is doing. It is doing translation, and translation is checkable against the query it produced.

That pattern matches the rest of the AI positioning across CelinQ, described in the piece on AI for Sparx Enterprise Architect: an architect asks, CelinQ retrieves model context deterministically, an AI proposes a structured interpretation of what was asked, and CelinQ validates and executes that interpretation against the real model rather than trusting a free-form answer. For change generation that structured interpretation is a semantic change set awaiting human approval. For a query, it is a traversal or filter specification awaiting execution against the model and query API — the same typed REST and gRPC surface, built for exactly this kind of structured, programmatic access to workspace content, that underlies the deterministic analysis discussed in the companion piece on private, AI-free model analysis.

Graph traversal and semantic filtering under the hood

It is worth dwelling on what makes this practical rather than aspirational, because "graph traversal" can sound like a research problem when in an EA repository it is closer to a well-understood, tractable one. The model that CelinQ synchronises is already structured as typed elements connected by typed relationships — the same representation Fusion reasons about when deciding whether two concurrent changes to a model genuinely collide, and the same one the deterministic analysis layer walks to compute dependency chains and quality checks. A query engine sitting on top of that representation does not need to invent graph semantics from scratch; it needs to expose a controlled, well-tested set of traversal and filter primitives — follow relationships of type X from a starting set, filter elements by stereotype or tagged-value pattern, intersect or union result sets — and compose those primitives according to a structured specification, whether that specification was typed directly by an architect who knows the primitives or translated from a plain-English question by an AI-assisted step.

Semantic filtering is the part that keeps the results honest for real-world model conventions, which are rarely as tidy as a textbook example. "Payment services" is usually a naming convention, a package boundary, or a stereotype an architect applied deliberately, rather than a formal type most repositories define. A filter that only matched an exact stereotype called "PaymentService" would miss half of what any experienced modeller would recognise as belonging to that category by eye. Getting semantic filtering right means combining several signals — name patterns, stereotypes, package membership, tagged values — in a way that is still deterministic, still inspectable, and still tunable per workspace, rather than delegated wholesale to a language model's fuzzy sense of what "payment" probably means in this particular repository.

A query engine's job is not to sound like it understood the question. It is to produce the same, correct, traceable answer every time the same question is asked of an unchanged model — and to be honest about which questions it cannot yet answer at all.

Where AI-assisted interpretation earns its place

None of the deterministic discipline above is an argument against using AI in this pipeline; it is an argument about exactly where AI belongs in it. The genuinely hard part of natural-language querying, from a user's point of view, is the translation from loose, ambiguous, differently-phrased English into the small set of structured operations the query engine actually understands — not the traversal itself. "Which applications depend on Oracle" and "what's still running on top of our Oracle database" and "show me anything hooked up to Oracle" are three different sentences asking, in almost all cases, the same underlying question, and recognising that they are the same question is a language problem, squarely in the territory where a language model adds real value that hand-written parsing rules struggle to match.

So the honest place for AI-assisted interpretation in this feature is exactly that translation step, kept strictly upstream of execution: given a question phrased however an architect happens to phrase it, propose a structured query against the known set of traversal and filter primitives. The proposal is then executed deterministically, and — this is the part that matters most — the architect can see the structured query the AI proposed, not just the prose answer, which turns a black box into something closer to a search bar with autocomplete: fast to use, but never mysterious about what it actually did. When the AI's proposed interpretation is ambiguous or clearly wrong for the workspace's conventions, the architect corrects the query directly rather than having to re-phrase the English and hope for a different guess.

Source links back to model entities

An answer that cannot be traced back to specific elements in the repository is not useful for architecture governance, no matter how fluently it reads, because the whole point of asking the question was to act on the answer — decommission something, escalate something, flag something for review — and acting on an untraceable claim is how bad decisions get made confidently. Every result CelinQ's query layer returns is a set of actual model entities, not a paraphrase of them, and the natural presentation of that result links each item straight back to the element it came from: the specific application, the specific relationship, the specific package, each addressable and each inspectable in the workspace, in the same way the Control Plane's revisions view keeps every entry traceable to an author, a change count, and a timestamp rather than a summary that has to be taken on faith.

This matters just as much when an AI-assisted summary sits on top of the raw results — say, a short paragraph explaining what a list of forty ownerless systems implies for a governance review. That summary is clearly labelled as generated commentary, and every specific claim it makes should be checkable against the underlying list it was given, exactly the same discipline the product applies when an AI advisor summarises a Fusion decision or a revision history: the generated text explains facts that already existed and can be verified independently; it is never the sole record of what those facts were.

Avoiding hallucinated model facts

Hallucination is the failure mode that would make this whole idea unsafe to use for governance — far more than a minor quality issue. A language model asked to answer "which applications have no owner" by reading through model content in an unstructured way can, without any malice or unusual failure, simply miss elements, double-count others, or — worse — assert that an element has no owner when it does, because the ownership information lived in a field the model's attention happened to skim past. None of these are exotic edge cases; they are the ordinary statistical behaviour of a system that generates plausible text rather than executing a query.

The architectural answer, already implicit in everything above, is to never let a language model be the thing that actually counts or searches the model. It proposes a structured query; the query engine executes that query against the real, canonical model data using code that either finds an element or does not, with no probabilistic middle ground; the result set is exactly what the traversal found, nothing more and nothing less. If the translation step misunderstood the question, the visible symptom is a query that does not match what was asked — inspectable and correctable, the same way a wrong SQL query is wrong in an obvious way once you read it. What cannot happen, by construction, is a confidently stated fact about the model that does not correspond to any element that actually exists in it, because no step in the pipeline is generating facts; every step after translation is either retrieving them or it is not.

Permissions and workspace security

A query layer is only as trustworthy as the access control sitting underneath it, and this is not a place where a natural-language interface should get a special exemption. Whatever a person asking a question in plain English can see through this feature has to be exactly what their role in the workspace already entitles them to see through every other path — the REST API, the Control Plane, the EA add-in — because workspace roles in CelinQ are enforced centrally, not re-implemented per feature. A viewer role does not gain broader visibility into a repository by asking a question conversationally instead of clicking through the Control Plane; the query engine executes against the same permission boundary either way.

This matters especially for an organisation running multiple workspaces with genuinely different sensitivity levels — a public-facing service catalogue in one workspace, a defence-sensitive systems map in another. A natural-language query interface that somehow bypassed workspace boundaries because "it's just a question" would be a serious regression from the access control the rest of the product enforces carefully, with token-based authentication and workspace-scoped roles from Viewer through Owner. The right design keeps the query layer downstream of the same authorisation checks as everything else, so that asking a question never becomes a way to see more than the asker was ever entitled to.

A worked scenario: preparing for a decommissioning review

Abstract descriptions of a query layer are easy to nod along with and hard to actually picture, so it is worth walking through how the three example questions this piece opened with would typically arrive together, in sequence, during a real piece of governance work rather than as three isolated demonstrations. Suppose a data platform team has decided to retire an ageing Oracle instance and has asked the architecture function to confirm nothing depends on it before the retirement date is locked in. The first question an architect actually needs answered is close to "which applications depend on Oracle" — the traversal described earlier — and the result is not the end of the exercise, it is the start of one, because a list of dependent applications immediately raises the follow-up question of which of those applications are still active. That second question, close in shape to "which systems have no owner," matters here for a slightly different reason than governance hygiene: an application with no owner recorded is also an application nobody can confirm is genuinely still in production rather than a stale entry nobody cleaned up, which changes how cautiously the decommissioning team needs to treat it.

The value of a query layer in this kind of exercise lies less in any single answer than in how quickly the second and third questions can follow the first, without the architect losing the thread rewriting queries by hand or re-opening a diagram to manually retrace a dependency chain they had already found once. Having confirmed which applications depend on Oracle and which of those lack a clear owner, the natural next step narrows further still — of the dependent, owned applications, which ones are also connected to anything the organisation classifies as a payment or financial service, because those carry a materially higher bar for sign-off before any change proceeds. This is exactly the combined traversal-and-filter pattern described earlier for "applications connected to payment services," now applied to a subset the previous two questions already produced rather than to the whole portfolio from scratch. Each step's result set links straight back to the specific elements involved, so by the time the review reaches a steering committee, the recommendation to proceed is backed by three traceable lists rather than a single architect's assurance that they checked and it looked fine.

This kind of chained investigation is also where the deterministic discipline described above pays for itself most visibly. If any one of those three steps had been answered by a language model reading through the model's content in an unstructured way rather than executing an actual traversal, the risk compounds with each step: a missed dependency in the first question becomes a missed application in the second, becomes a false all-clear in the third, and the decommissioning proceeds on the strength of an answer nobody can retrace. Keeping every step a structured, executed query against the real graph — whether an architect typed the query directly or arrived at it by asking a plain-English question that CelinQ translated — means the final recommendation is exactly as trustworthy as the underlying data, which is the only honest standard for a decision with this much downstream cost if it turns out to be wrong. The same chained pattern applies just as naturally to other governance tasks that follow this shape, from confirming an impact analysis is complete before a change window opens, to scoping which parts of a portfolio a given security review actually needs to touch.

Honest limits

It would be misleading to present this as a solved, ambient capability that simply exists today the way synchronisation or Fusion's conflict resolution do. The typed model and query API that a feature like this depends on is real and already exposes workspace and revision content in a structured, programmatic form — that surface is explicitly the value layer CelinQ is building for future AI-assisted capabilities, not an LLM wired directly into the synchronisation engine. Natural-language querying is the direction that surface is built to support: a genuinely useful version of it needs careful, ongoing work on the translation step, on the set of traversal and filter primitives it can express, and on tuning semantic filtering to each organisation's own modelling conventions, none of which is glamorous and all of which determines whether the answers are actually trustworthy rather than merely fluent.

The honest claim, then, is narrower than "ask CelinQ anything about your model and get a perfect answer." It is that the architecture is deliberately built so that whenever this capability matures, the hard-won trust the rest of the product has earned — deterministic behaviour, traceable results, permissions that mean what they say — does not have to be re-negotiated for it. A question phrased in plain English should never get looser guarantees than the same question typed as a structured query, and building the feature any other way would trade a real convenience for a governance risk no architect asking about their own portfolio should have to accept.