CelinQ Insights · No. 62

How to generate a Sparx Enterprise Architect model from a prompt with CelinQ

A walk-through of what happens between describing an architecture in a sentence and seeing it land, reviewed and validated, in your own repository.

Take a concrete example, the kind of request that comes up constantly in early design work: "create a three-tier application architecture with a presentation layer, an application layer and a data layer, with the presentation layer calling the application layer and the application layer reading and writing to the data layer." As a sentence, it takes ten seconds to type. As a model, built by hand in Sparx Enterprise Architect, it is perhaps twenty minutes of work — three packages, several elements with the right types, a handful of connectors drawn in the right direction, a diagram laid out well enough to show someone. None of those twenty minutes involve a decision. The decision — three tiers, this shape of dependency — was made before the typing started. What follows is transcription, and it is exactly the kind of transcription CelinQ's generation capability is built to remove, without removing the governance a shared architecture repository needs.

This article walks through what actually happens to that sentence, stage by stage, because the interesting part is not that a model gets built quickly. It is what stands between the request and the write, and why that sequence is what makes the speed trustworthy rather than merely fast. The general shape of this pipeline — intent, context, proposal, validation, approval, revision, sync — is set out in full in AI for Sparx Enterprise Architect; this article follows one request through it in detail.

Choosing where the work lands

The first step is not typing the prompt. It is selecting the package the new content should belong to — the point in your existing containment tree where a three-tier architecture makes sense as a child. This is a small step but not a cosmetic one. A generation capability that invented its own top-level location for new content would immediately start fighting your repository's existing organisation, scattering new packages wherever seemed convenient to it rather than where your team's conventions expect them. By anchoring generation to a package you choose, CelinQ ensures the new content is placed exactly where you would have placed it by hand, and that anything it references from elsewhere in the model — an existing identity service, an existing gateway — is resolved against your actual repository rather than assumed into existence.

Parsing the intent, not just the words

Once you submit the request, CelinQ retrieves the model context relevant to it — the package you selected, its existing children if any, and the parts of the workspace the request appears to reference by name — and passes that context alongside your description to the AI layer. This retrieval step matters more than it looks. A request phrased in isolation, with no knowledge of what already exists, would have no way to tell the difference between "create an application layer" meaning brand-new content and "create an application layer" meaning attach to the application layer that was modelled last month under a different package. Giving the AI layer the surrounding context is what lets it distinguish those two cases and, where something relevant already exists, propose a reference to the real element rather than manufacturing a near-duplicate — the same reuse discipline that matters throughout the series, and the reason a generation capability without this step is worse than no capability at all.

From there, the AI layer's job is narrow: turn the description into element types, names, and relationships expressed in terms the model already understands. For the three-tier example, that means recognising "presentation layer" as a package or component grouping rather than a single element, recognising that "calling" and "reading and writing to" describe two different relationship semantics, and selecting element and connector types that are legal within your workspace's modelling language. None of this is guesswork dressed up as intelligence — it is pattern interpretation constrained immediately afterwards by a deterministic check, which is the subject of the next stage.

What the proposal actually looks like

The output of this stage is not a finished model. It is a proposal: a structured, specific description of packages, elements, connectors, stereotypes and tagged values that would be created if you approved it, held for your review and not yet applied to anything. For the three-tier request, a reasonable proposal contains three packages — Presentation, Application, Data — each containing one or more elements of an appropriate type for your profile, a connector from the presentation element to the application element carrying a dependency or call semantic, and a connector from the application element to the data element carrying a data-access semantic. Where your workspace's conventions call for stereotypes — marking something as a "Web Application" or a "Database" rather than a bare component — the proposal applies them, and where your organisation tags elements with values like an owner, a status or a technology, the proposal fills in what it reasonably can and leaves the rest for you to complete, rather than inventing values it has no basis for. Workspaces modelling in ArchiMate rather than UML follow the same sequence with one further layer of discipline, covered separately in prompt-to-ArchiMate generation, because ArchiMate's own relationship rules are stricter than a generic component-and-connector diagram needs to be.

A diagram is generated alongside the elements, using an auto-layout that groups the three tiers left to right or top to bottom in the order the dependencies flow, so the picture reads the way the architecture does — the same automatic-diagram idea covered in more depth in the series' piece on generating EA diagrams automatically from the model. Auto-layout in this context is doing something genuinely useful and genuinely modest: it is not trying to produce a beautiful diagram, only a legible first arrangement that saves you the twenty minutes of manual dragging that turns a correct-but-tangled auto-arrangement into something you would put in front of a colleague. You are always free to rearrange it afterwards; the diagram is ordinary model content the moment it exists, not a locked artefact.

Previewing before anything is committed

Before any of this touches the canonical model, it is shown back to you as a preview: the packages, elements, connectors and tagged values the proposal contains, laid out so you can check them against what you actually meant. This is the moment to catch the gap between "described" and "meant." Perhaps you intended the presentation layer to call a specific existing API gateway rather than a fresh application element — the preview is where you notice that and correct it, either by adjusting the request and regenerating or by editing the proposal directly before applying it. Perhaps the connector direction is backwards, or a stereotype does not match your convention. None of this is unusual or a sign that the generation failed; it is the normal texture of working with a system that interprets language rather than reading your mind, and the preview step exists specifically because that gap is expected, not exceptional.

The proposal is not the model. It becomes the model only when you say so, and only after it has already been checked against the structural rules the model itself enforces on everyone.

Validation: the part that has nothing to do with AI

Underneath the preview, before you ever see it, the proposal has already passed through CelinQ's deterministic validation — the same shadow validation applied to every change reaching the canonical model, described in the series' coverage of semantic conflict resolution. Do the referenced parents exist? Do the connector endpoints resolve to real entities, whether newly proposed or already present in the model? Does the proposed containment introduce a cycle? Are the identities involved genuinely unique, or does the proposal collide with something that already has that name and type? A proposal that fails any of these checks is rejected before it reaches your review screen at all — not silently repaired, not applied with a warning, simply refused, exactly the way a hand-typed EA script that tried to do the same thing would be refused by the repository's own integrity rules.

This separation is what makes the whole capability trustworthy rather than merely convenient. The AI layer is good at recognising intent and proposing structure; it is not, and does not need to be, infallible about repository-level integrity, because integrity is enforced by code that has no opinions and makes no mistakes of the kind a language model can make. You are never in the position of trusting the AI to have got the structural details right. You are only ever in the position of trusting deterministic validation to have caught it if it did not, which is a much easier thing to trust, because it is testable, reproducible, and the same for every proposal that ever passes through it.

Applying through semantic commands

Once you approve the preview, CelinQ applies the proposal the same way it applies any other change: as an ordinary semantic ChangeSet, run through the same command path a manually typed edit would take, producing a canonical revision recorded in the workspace's ordered history. There is no separate "AI apply" mechanism with its own rules. This matters because it means the three-tier architecture you just generated is, from the moment it is applied, indistinguishable in standing from anything you built by hand — it participates in Fusion's merge logic the same way, it shows up in the Control Plane's revisions view the same way, and it is subject to the same review and governance any other model change would be.

Reaching your desktop

The canonical revision now exists in the shared workspace, but your local Sparx EA repository has not changed yet — that happens through the ordinary synchronisation path, the same background agent and add-in that keep your repository in step with every other change your team makes. If you generated the architecture yourself and are sitting at the same machine, this typically happens within moments, governed by the same debounce and notification behaviour that drives any other Smart Sync push. If a colleague generated and approved it while you were offline, the change waits in your durable queue and applies the moment you reconnect, replayed exactly once regardless of how long you were away. If you had been independently editing the same package, Fusion's deterministic merge reconciles your work with the newly arrived generated content using the same merge-atom logic that handles any other concurrent edit — there is nothing about AI-originated content that requires a different reconciliation path, because by the time it reaches your repository it is simply a revision like any other.

The practical outcome, from your seat in Sparx EA, is that a package you were watching suddenly contains the three tiers you asked for, correctly typed, correctly connected, with a diagram already laid out — appearing the same way any colleague's synchronised change would appear, through the Project Browser and the diagram surface you already use every day. Nothing about the experience of receiving the change requires you to think about how it was produced.

Iterating, not starting over

A single request rarely captures a whole design, and it does not need to. Once the three-tier skeleton exists, a follow-up request — "add a caching component between the application layer and the data layer" — retrieves the now-updated model context, recognises the application and data elements that already exist, and proposes a new element and two new connectors that attach to them rather than rebuilding the neighbourhood from scratch. This incremental behaviour is what makes the capability usable for real design work rather than only for one-shot skeletons: you can build a rough shape quickly, look at it, and refine it with further plain-language requests, each one going through exactly the same preview, validation and approval sequence as the first. The context retrieval that grounds each request in what is actually there, described earlier, is precisely what stops iterative use from producing a slowly diverging pile of near-duplicate content.

A second example: wiring into what already exists

The three-tier example is a clean-room case — nothing in the target package existed before the request. Most real requests are not that tidy. A more typical afternoon looks like this: your repository already has an Order Service, a Payment Gateway, and a Customer Database, built up over months by several people, and you want to add "an inventory service that checks stock before an order is confirmed, connected to the existing Order Service." This is where the context-retrieval stage stops being a background detail and becomes the whole point. If CelinQ passed only your sentence to the AI layer with no knowledge of what already exists, the safest and most likely outcome would be a brand-new, disconnected "Order Service" element sitting awkwardly next to the real one — a near-duplicate born from a perfectly reasonable sentence, and precisely the kind of mess a mature repository spends years cleaning up after.

Because the retrieval stage looks at the package you selected and the names your request appears to reference, the proposal for this request typically contains one new element — the inventory service — and a connector from it to the Order Service that already exists in your model, referenced by its real identity rather than recreated. The preview makes this explicit: it does not just show you a new box and a new line, it shows you that the line's far end is the Order Service you already have, so you can confirm at a glance that the proposal reused rather than duplicated. This is the single most important thing to check in any review of a generation proposal that touches existing content, more important even than the new element's name or type, because a duplicate that slips through is far more expensive to fix later than a wrong stereotype is.

Worth naming honestly: reuse detection depends on the request giving the system something to recognise a name against, and on the target you meant genuinely being visible in the context that was retrieved — typically the package you selected and its near neighbourhood, not the entire repository regardless of size. A request that refers to something by a nickname nobody else uses, or that reaches for an element buried in an unrelated corner of a very large model, may not resolve the way you expect, and the proposal will say so by proposing a new element instead of a reference to an old one. This is exactly why the preview step matters as much for a wiring-in request as it does for a clean-room one: the failure mode to watch for is not a proposal that looks wrong, but one that looks plausible while quietly creating a second Order Service under a different name. Catching that at review time costs you a few seconds. Catching it six months later, after three more diagrams have been drawn against the wrong one, costs considerably more.

Applying this beyond three tiers

The three-tier example is deliberately simple because it makes the pipeline easy to follow, but the same sequence applies to considerably more elaborate requests — a microservice landscape with a dozen services and an event bus between them, a data-flow architecture through several transformation stages, an integration layer connecting a handful of existing systems to a new API gateway. The size of the request changes the size of the proposal, not the shape of the governance around it. A large proposal simply asks more of the review step, which is exactly the correct place for that cost to land: the bigger the change, the more scrutiny it deserves, and the pipeline scales that scrutiny automatically rather than letting a large change slip through on the same light-touch trust a small one might reasonably get.

Where it genuinely helps, and where it does not

The honest case for this capability is narrower than "AI designs your architecture," and it is worth being precise about the boundary. It helps enormously with the mechanical distance between a decision already made and that decision existing as model content — the three-tier skeleton, the microservice landscape, the integration layer, all cases where the shape was decided in a workshop, a conversation, or an architect's own head, and the remaining work is transcription. It does not help with deciding whether three tiers is the right architecture, whether the caching component belongs where you put it, or whether the dependency direction reflects a genuine business need rather than a convenient assumption. Those are architectural judgements, and nothing in this pipeline claims to make them for you. What it changes is how expensive it is to see a candidate decision as a real, inspectable model rather than a sketch in your head — which, in turn, changes how many candidates you are willing to build and compare before committing to one, a point explored further in the series' broader discussion of AI-assisted model generation.

The honest limits

Speed introduces its own temptation, and it is worth naming directly. Because generating a proposal is fast, there is a real risk of approving proposals with less scrutiny than a hand-built change would receive, simply because the tool has been reliable so far and the review feels like a formality. That risk is not hypothetical, and no amount of deterministic validation removes it, because validation checks structure, not intent. The discipline of actually reading a preview before approving it has to be a habit the team maintains, not an assumption the tool can enforce on your behalf. A pipeline this careful is only as careful as the humans using the approval step it provides.

There is also a plainer limitation worth stating: generation quality depends on how clearly you describe what you want, and an ambiguous or underspecified request produces an ambiguous or underspecified proposal, quickly. This is not a flaw to be engineered away so much as an honest property of any system that turns language into structure — the clarity you put in is close to the clarity you get out, and no amount of context retrieval substitutes for an architect who has actually decided what they want built. And as throughout this series, none of this is available unless an administrator has explicitly enabled it for the workspace; the capability is optional, off by default, and a restricted or Sovereign-mode workspace can keep it disabled entirely while every other part of CelinQ continues to work.

Go back to the three-tier sentence one more time. Typed on its own, it is ten seconds of text. Followed all the way through — context, proposal, preview, deterministic validation, approval, canonical revision, synchronisation into your local repository — it is a governed change that happens to have taken you a few minutes instead of twenty, with nothing about the governance skipped to buy that speed. That is the actual promise of generating a model from a prompt: not that the thinking gets automated, but that the distance between having thought and having modelled shrinks to almost nothing, without the shortcut costing you the integrity a shared repository depends on.