CelinQ Insights · No. 61

AI for Sparx Enterprise Architect: turning a sentence into a governed model change

A plain-language request is not the dangerous part of AI-assisted modelling. What happens between the request and the write is.

An architect types a sentence: "add a payment gateway component under the Checkout package, with a dependency from Order Service." Somewhere behind that sentence sits a Sparx Enterprise Architect repository with years of accumulated structure, naming conventions nobody wrote down but everyone follows, and relationships that other diagrams and other people quietly depend on. The question that decides whether AI belongs anywhere near that repository is not "can a model understand the sentence?" — large language models are now comfortable with far harder text than that. The question is what happens in the gap between understanding the sentence and a row changing in the model. That gap is where trust is either earned or lost, and it is the subject of this article.

Sparx EA has offered scripted and programmatic ways to create model content for a long time, through its Automation API. Anyone who has written an EA script knows how unforgiving that surface can be: create the wrong object, forget to save a GUID, leave a relationship pointing at nothing, and the repository does not politely refuse — it simply now contains something a human has to notice and clean up later. Handing an AI system direct access to that same surface, and trusting its output as if it were a careful engineer's script, is a way of importing all of that unforgiving behaviour and combining it with a system that occasionally makes things up with total confidence. That combination is precisely what CelinQ's AI integration is built to avoid, and the way it avoids it is the actual story worth telling — more interesting, and more defensible, than "the AI writes your model for you."

Why the request cannot become a write directly

It helps to be specific about the failure modes a naive integration would invite. A large language model can mis-hear the boundary of an instruction and touch more of the model than was asked. It can invent a plausible-sounding element name that collides, almost but not quite, with something that already exists — creating exactly the kind of near-duplicate that a mature repository spends years trying to clean up. It can propose a relationship type that is structurally invalid for the two element types involved, or attach a tagged value to something that does not carry that tag in your organisation's profile. None of these are exotic edge cases. They are the ordinary, statistically expected behaviour of a model that generates plausible text, applied to a domain where "plausible" and "correct" are not the same thing.

A model repository is not prose. It is a set of interconnected facts with real constraints: containment cannot form a cycle, a relationship's endpoints have to resolve to real entities, an identity has to remain unique and stable across everyone who references it. A system that writes directly into that structure needs to respect those constraints every single time, with no exceptions, because a single silently broken invariant does not stay contained — it propagates into every diagram, every report, and every downstream analysis that reads the model afterwards. This is the reason CelinQ treats "the AI writes the model" as a design error rather than a convenience worth allowing. The value of AI here is real, but it has to be captured without exposing the raw repository to a system that cannot guarantee it will always be right.

The pipeline: proposal, not permission

The way CelinQ resolves this is by inserting a series of deterministic, inspectable stages between the request and the write, and by never letting AI itself be one of the stages that actually changes the canonical model. The shape of the pipeline is the same regardless of which specific AI capability is in use — generating new content, as covered in how CelinQ generates a model from a prompt, or reading existing content back, as covered in AI-assisted model analysis. In every case, the flow is: the architect states an intent; CelinQ gathers the relevant model context; the AI proposes a set of changes; CelinQ validates that proposal deterministically; a human approves it where the change is ambiguous or significant; and only then does a canonical revision exist, which synchronises out to local EA repositories through the ordinary add-in path.

Notice what that sequence deliberately does not contain: a stage where the AI system itself opens the repository, or a stage where its output is applied without anyone or anything checking it first. The proposal is the AI's entire contribution. Everything downstream of the proposal is either deterministic code that either accepts or rejects the change on structural grounds, or a human being who looks at what is proposed and decides whether it is what they meant. That separation is not a compliance afterthought bolted on for the sake of appearances. It is the only way to get the genuine convenience of natural-language modelling without inheriting the unreliability of the system that interprets the language.

What a semantic change set actually contains

It is worth being concrete about what "proposal" means, because the word can sound abstract. A proposal is a structured description of intended changes expressed in the same terms the model already understands: new packages and where they sit in the containment tree, new elements with a type drawn from the profile your repository actually uses, connectors between specific elements with a relationship type and a direction, tagged values with the keys your organisation has defined, and — where useful — a diagram that lays the new content out. Nothing in a proposal is free text dropped into the model as an afterthought. Every field maps onto a real construct EA already recognises, because the proposal is built to become an ordinary EA write once it is approved, not to become some parallel representation that has to be reconciled with the model later.

The model-type constraint matters more than it might appear to. If your repository uses UML for one workspace and ArchiMate for another, the vocabulary of legal element and relationship types is different, and a proposal generated for one is not simply reusable in the other. CelinQ's proposal generation is scoped to the profile of the workspace it is working against, which is what stops it from, say, offering a UML "Boundary" class inside a strictly ArchiMate application layer. The detail of how that plays out for ArchiMate specifically — layers, viewpoints, and which relationship types are legal between which concepts — is its own subject, covered in prompt-to-model ArchiMate generation. The point to hold onto here is narrower: a proposal is not vague. It is a concrete, typed set of intended entities that could, in principle, be read and understood by a person who has never heard the word "AI" at all, because it is expressed entirely in modelling terms.

Deterministic validation: the part that does not trust anyone

Before a proposal is shown to a human for approval, it passes through the same validation discipline CelinQ applies to every change that reaches the canonical model, regardless of where the change originated. Parents have to exist. Relationship and diagram-node endpoints have to resolve to real entities. Containment cannot form a cycle. Identities have to stay unique. This is not a special AI-only check bolted on as a precaution — it is the ordinary shadow validation every ChangeSet goes through, the same discipline described in the series' coverage of semantic conflict resolution, applied here to a proposal instead of to a human's own edit. A proposal that would violate one of those invariants is rejected before a human ever sees it, not silently corrected and not applied with a warning. This matters because it means the validation layer does not have to trust that the AI got things right; it only has to be strict, and strictness is a property software is genuinely good at, in a way that language generation is not.

What validation cannot do, and does not attempt to do, is judge whether a structurally valid proposal is the right one. A perfectly well-formed element with a slightly wrong name, or a relationship that is technically legal but architecturally questionable, will sail through structural checks without complaint, because those checks were never meant to substitute for architectural judgement. That is precisely why validation is followed by a second gate rather than being the only gate.

Human approval: not everywhere, but where it counts

A proposal is held for review before anything is written to the canonical model. What the reviewer sees is not a wall of technical output but a preview expressed in the same modelling vocabulary the proposal was built from: the packages, elements, connectors and tagged values that would be created or changed, laid out so the architect can check them against what they actually asked for. This is the moment where the difference between "described" and "meant" gets caught. If the request was ambiguous — perhaps it is genuinely unclear whether a new component should attach to an existing service or create a near-duplicate — the proposal makes a choice, and the review is where a human either confirms that choice or corrects it before it becomes permanent.

AI proposes architecture changes. CelinQ validates, governs, records and applies them through semantic operations. The proposal is not the change; the human's approval, following a deterministic check, is what makes it one.

It would be fair to ask whether requiring approval on every proposal defeats the point of using AI at all — if you have to check everything anyway, where is the time saved? The honest answer is that review is fast precisely because the proposal is expressed in the model's own terms rather than in prose you have to interpret. Checking a list of typed elements and connectors against your intent takes a fraction of the time it would take to build those same elements by hand, click by click, and it is a fundamentally different kind of task: recognition rather than construction. The labour that AI removes is the transcription labour, not the judgement labour, and the review step is exactly where the judgement labour still happens, on your terms, at your pace.

Revision, audit, and why nothing here is invisible

Once a proposal is approved, applying it does not create a special, second-class kind of model content that behaves differently from anything else in the repository. It creates a canonical revision through the same mechanism any other change goes through — the ordered, causally-based revision history that underpins Fusion and the rest of CelinQ's synchronisation. That revision is visible in the Control Plane's revisions view alongside every human-authored change, with the same author, timestamp and change-count accounting. There is no shadow ledger of "AI changes" that lives outside the normal audit trail; there is one history, and an AI-originated change earns its place in it exactly the way a manually typed one does, by being reviewed and applied through the identical path.

This matters for a reason that goes beyond neatness. A team six months from now, looking at why a particular component exists and what it depends on, should not have to first work out whether it was created by a person or proposed by AI and approved by a person, because the answer to "is this a trustworthy part of the model" is the same either way: it went through validation, it was approved, and it is recorded in the revision history like everything else. The provenance is available if anyone wants to look, but the model does not treat AI-originated content as suspect forever afterward. Once it clears the gate, it is simply part of the model.

Why the write happens through the EA add-in and nowhere else

A canonical revision is not the same thing as a change in your local Sparx EA repository, and the distance between those two things is deliberate. The revision lives in the shared workspace on the CelinQ Server. It reaches your desktop the same way any other synchronised change does: your local CelinQ agent, running alongside EA, applies it through EA's own documented Automation API, the identical mechanism used for every ordinary edit that flows through the sync engine. If you happen to be offline when the proposal was approved by someone else, the change sits in the durable queue and is applied when you reconnect, replayed exactly once, exactly as any other queued change would be. If you have been editing the same area of the model concurrently, Fusion's deterministic merge reconciles your work with the incoming AI-originated change using the same merge atoms and rule codes covered in the series' coverage of proof-carrying merges — there is no separate, AI-flavoured conflict-resolution path, because there does not need to be one.

The practical consequence is that AI never has a direct line to your desktop repository, and it never needs one. It proposes into the shared workspace; your local EA repository receives changes through the same governed channel everything else uses. That single design choice removes an entire category of risk — a rogue or malfunctioning AI call cannot corrupt your local model, because it was never given the means to touch it directly in the first place.

AI switched off, and what still works

It is worth stating plainly, because it is easy to lose in an article about a new capability: everything described so far is optional. The core of CelinQ — local-first synchronisation, Smart Sync, Fusion's deterministic merge, presence, monitoring, revisions, backups — works completely without AI, and was built and proven before any AI capability existed at all. External AI is not switched on by default in a new workspace. An administrator has to explicitly enable it in the Control Plane, choose a provider and model, and opt into individual capabilities one at a time; nothing is on implicitly. A workspace can be restricted to keep it disabled regardless of the server-wide setting, and a deployment can be run in Sovereign mode, which forces AI off at the configuration level in a way that cannot be re-enabled from the console — while every other part of the platform, including sync, Fusion, users, audit, monitoring, revisions, backup and the API, continues to work exactly as it would in any other deployment.

The reason this matters for a technical audience rather than only a procurement checklist is that it changes what question you have to ask about the AI layer. You do not have to ask "what happens if we cannot use this at all" — you already know, because the answer is "the rest of the product, unaffected." You only have to ask the narrower, more tractable question of whether this specific optional capability, governed by this specific pipeline, is worth enabling for this specific workspace. For organisations that cannot answer yes to that question today — because of a data-sharing policy, a regulator, or simply caution while the capability is new — nothing about the rest of the platform is held hostage to the decision. The pattern of a customer-hosted or provider-abstracted AI layer, so that a future deployment need not depend on a public API at all, is discussed further in the series' coverage of secure AI configuration and sovereign deployment.

What this does not solve, and should not claim to

Honesty about the limits of this pipeline is not a hedge; it is what makes the rest of the claim credible. A validated, well-formed proposal is not the same thing as a good architectural decision. If an architect asks for the wrong thing, described clearly, the system will faithfully build a well-formed version of the wrong thing, and structural validation will not catch that, because structural validity and architectural correctness are different properties. The review step exists precisely because of this gap, and it only closes the gap if the human reviewing actually reads the proposal rather than approving it reflexively because the tool usually gets things right. A pipeline that makes approval too easy to rubber-stamp is a pipeline that has quietly reintroduced the risk it was built to remove.

There is also a latency cost that is worth naming rather than glossing over. A proposal, a review, and an explicit apply take longer, end to end, than a direct write would. For a genuinely trivial, unambiguous change, that overhead can feel like friction. CelinQ accepts that friction deliberately, on the grounds that the alternative — an AI system with standing permission to write to a shared architecture repository without anyone checking first — is not a trade worth making even for the sake of a few extra seconds saved. CelinQ treats that friction as the price of the guarantee rather than a bug to be optimised away, and it is a price that scales with how much the change actually matters, since a genuinely low-stakes addition is also the fastest kind of proposal to review.

Finally, none of this makes CelinQ an authority on what your architecture should be. It has no opinion, deterministic or otherwise, about whether a three-tier decomposition is the right call for your organisation, or whether a particular dependency represents acceptable coupling. What it offers is a governed way to turn a decision you have already made into model content quickly, and a governed way to surface information about a model you are trying to understand — never a substitute for the architectural judgement that decision required in the first place. That division of labour, between a system that is very good at mechanical transcription and validation and a person who is responsible for the actual architecture, is the whole design, and it is why the pipeline described here is worth trusting with a shared, governed Sparx EA repository in a way that a system without those stages would not be.

Go back to the opening sentence — "add a payment gateway component under the Checkout package, with a dependency from Order Service" — and it should now read differently. It is not a command that reaches into the repository. It is the first word in a short, visible conversation: a proposal built from it, checked against the model's own rules, shown back to the person who asked, and only then, if they agree, written into the model through the same governed path every other change takes. That conversation, not the sentence alone, is what makes AI for Sparx Enterprise Architect something a serious architecture practice can actually adopt.