Why your EA repository quality determines your AI output quality

Every team evaluating AI for architecture work asks how good the answers will be. Most of that is decided before any model runs, by how cleanly the repository is structured. Point a capable assistant at a messy EA repository and you get answers that are confident, plausible and sometimes wrong. Point the same assistant at a disciplined one and you get answers people can act on. This article is about the architect’s job of making the repository fit for AI, and how AI helps with that job too.

The repository decides whether an AI answer about your architecture can be trusted.

The MDG is the instruction manual

When you ask an AI something like “what data sources feed our customer service system?”, it does not understand “customer service system” the way you do. It reads the Sparx EA repository: elements, attributes, connectors and tagged values. The phrase you typed lives somewhere in there, in an element name, probably spelled or abbreviated a little differently in three places.

What turns that raw content into something the AI can reason about is the MDG Technology, Sparx EA’s Model Driven Generation mechanism, which carries the metamodel for your repository. It defines what kinds of things can exist, which attributes they carry, how they relate and what each means in architectural terms.

Read it as a manual the AI consults: a System is a kind of Application Component; Application Components carry Technology Stack, Owner and Criticality; an Application Component can connect to another; a connection represents a logical data or control flow. Without that manual, the assistant sees fields and has to guess what they represent. With it, the assistant can turn your business question into queries against the model and turn the results back into architecture answers. That is why metamodel quality is the biggest single factor in whether AI output is useful.

Implicit metamodel versus clean metamodel

Picture two repositories that look equally impressive from the outside.

The implicit one

The architects have modeled the estate extensively: hundreds of application components, dozens of technology platforms, elaborate connection diagrams. But ask where the metamodel defines what a “Technology Platform” is, which attributes it must carry and what may connect to it, and the answer goes fuzzy. The definition lives partly in the MDG, partly in conventions only the senior architects remember, and partly in the data itself.

Some platforms map cleanly to a Business Capability and some do not. Some declare a Technology Type and others bury it in a description. Some connections are formal relationships and others are sentences in a notes field. Nothing enforces the pattern, so it is inconsistent. When the AI is asked “what platforms support our e-commerce capability?”, it works through contradictory signals and infers what the data probably means. The answers are sometimes right and sometimes wrong, in ways nobody can predict, and stakeholders learn not to trust them.

The clean one

Here the metamodel defines Technology Platform explicitly, with mandatory attributes: Name, Technology Category, Vendor, Lifecycle Status, and Business Capability at a defined cardinality. Every Technology Platform has them filled in. The allowed values for controlled fields are listed. Dependencies are always modeled with the formal Supports relationship and never described in notes.

Ask the same question and the AI follows the Supports relationship from the capability to each platform that realizes it. The answer is reliable because the data underneath it is structured and consistent. One repository produces answers that need a person to verify them. The other produces answers you can act on.

What this means for the AI tools on Sparx EA

Sparx EA core has no built-in MCP server. AI reaches the repository through products added alongside it, all launched in 2026. Kernaro AI Hub from Sparx Systems includes a read-only MCP server for enterprise-wide access. Kernaro Assist works inside the EA client. AI Power Tools for Sparx EA, free from NovoCircle, gives Claude or GitHub Copilot read and write access from the architect’s own machine. The AI tools for Sparx EA page compares the options.

All of them depend on the modeling language to make sense of the repository. Kernaro AI Hub’s MCP server, for instance, needs an MDG Technology that maps the Sparx schema into the GraphQL layer it serves. If the metamodel is explicit and the data follows it, the semantic layer is accurate and the answers hold up. If the metamodel is implicit, the layer can only approximate what your data means, and the AI’s confidence outruns its accuracy.

A concrete example

Suppose you want to know which systems with a criticality of High or above depend on the legacy database platform.

With a clean metamodel, the path is unambiguous. Start from the Database Platform, an explicitly defined element type filterable by Technology Type, follow every Depends On relationship to a System, and keep the systems whose Criticality is High or Critical. The result is dependable.

With an implicit metamodel, the same question becomes a stack of guesses.

• Is “Database Platform” a Technology Platform or a Technology Component? The metamodel does not distinguish.
• Is the legacy database called “Legacy DB”, “Oracle Legacy” or something else? Naming is not enforced.
• Are dependencies formal relationships, lines on a diagram, or sentences in a description?
• Is criticality an attribute on System, and is it called Criticality, Business Impact or something else?

The AI can make educated guesses, and sometimes they land. Stack four of them together and a plausible wrong answer becomes likely. What separates the two outcomes is the data discipline behind the metamodel.

Making the metamodel explicit, today and AI-augmented

Today, by hand. An architect works out which element types and attributes matter, writes the conventions down, then opens element after element to find the ones that do not follow them. On a large repository the clean-up stalls long before it finishes, and the conventions drift again.

AI-augmented. The architect designs the governance intent: which element types exist, which attributes are mandatory, which relationships are allowed, and which values are permitted. That goes into the MDG and a set of validation rules. The AI then applies and checks it across the model. It reports every element that breaks a rule, proposes fixes where the evidence supports one, and makes them once the architect approves. Automation checks completeness, people own correctness.

The skill it asks. Deciding what the model must say and stating it precisely enough to check. That means focusing on the elements and relationships people ask about, the ones that come up in governance decisions and drive technical choices, and leaving the rest for later. Remodeling everything is never the goal.

Four questions to ask of your repository

Is your data consistent? Do all System elements carry a Technology Stack attribute? Do all dependencies use the same relationship type? Or do you keep finding one-offs and workarounds where the metamodel did not fit?

Are the concepts that matter modeled as first-class things? If business capability drives how you reason about the estate, is it a real element type with explicit relationships to systems and technology, or is it scattered across descriptions and diagrams?

How much meaning is implicit? How much of the architecture lives in diagrams, notes and architect memory rather than in structured data an AI can traverse?

If your metamodel is clean, connected AI tools will give you reliable answers. If it is implicit and inconsistent, you can make it explicit first, with AI doing much of the checking, or accept that every answer needs a person to verify it. A clean metamodel pays off well beyond AI, because everything that touches the repository gets easier.

The right sequence

The AI conversation should follow the metamodel conversation. A repository that is mature but has an implicit metamodel is a solvable problem. Make the important parts explicit, have AI bring the data into line under the architect’s review, put validation in place so it stays that way, and then widen what you ask of the AI. The first conversation is with your architects, about whether the metamodel is ready. If you want a structured way to find out, Paralysis to a Plan scores repository and metamodel readiness before any tooling decision, and AI-Augmented Architecture shows what the practice looks like once the foundation is sound.