MDG Technology as Your AI Quality Gate: Why Model Governance Decides AI Output

An architect who wants reliable answers from AI, dashboards or reports has to start with the modeling language under the repository. MDG Technology is Sparx EA’s metamodel framework: the rules that define which element types exist, what properties they carry and how they connect. For anything that reads your repository as data, the MDG is the semantic contract between the repository and every system that queries it, whether that is a BI dashboard, a reporting layer or an AI assistant. If the MDG is inconsistent, with undefined stereotypes, missing tagged values and ad hoc element types, every query inherits that inconsistency. Poor MDG produces poor output.

MDG and its rules are part of building the model. The AI-augmented way to govern them is for the architect to design the governance intent and for AI to apply it and check the model against it. This article covers what that intent consists of, how to tell when it is missing, and how the work of fixing it divides between architect and AI.

What MDG Technology is and does

MDG Technology is Sparx EA’s built-in metamodel extension mechanism. Out of the box, Sparx EA supports ArchiMate, TOGAF, BPMN, UML, SysML and others. MDG lets you extend those notations, or build your own, by defining:

• Custom stereotypes on existing metaclasses (for example, a «CriticalCapability» stereotype on an ArchiMate Business Capability)
• Tagged values carrying structured properties on those stereotypes (CapabilityMaturityLevel, BusinessOwner, InvestmentCategory)
• Shape scripts for visual rendering
• Validation rules that enforce structural constraints

The result is a controlled vocabulary for your repository. Every element created under a governed profile is typed, named and annotated consistently, and that consistency is what makes a repository machine-readable. Without it, architects reach for whatever element type seems close enough, drop notes into free-text fields and use different naming conventions across packages. The repository still looks like architecture to a person scanning it. To anything parsing it for structure, it is noise.

MDG as the semantic layer for a query

When a query layer reads a Sparx EA repository, whether it feeds a BI tool or an AI assistant, it traverses the element graph: element types, stereotype names, tagged values and connector types. The mechanism is the same whatever sits on the far end, and the MDG defines the semantic layer it reads.

Consider a simple question: “Which applications support the Customer Onboarding capability, and what is their decommission status?” To answer it, the query layer needs:

1. An «Application» stereotype (or equivalent) with a tagged value called DecommissionStatus carrying a controlled vocabulary (Active, Under Review, Scheduled for Decommission).
2. A defined connector type, Realization or Serving, linking Application elements to Capability elements.
3. Consistent population of those tagged values across the application portfolio.

If DecommissionStatus exists on only some applications, uses three value formats (yes/no, true/false, Active/Inactive) and is missing on the rest, the query returns an unreliable partial answer. It will not invent a value. It reports what is there, which is incomplete and inconsistent. That is an MDG governance failure, made visible.

Five signs your MDG is holding back your AI work

1. Architects use base metaclasses instead of stereotyped elements. The repository has Application Components and Business Functions but no consistent stereotypes, so nothing can distinguish a critical ERP from a departmental spreadsheet tool.

2. Tagged values are populated inconsistently. Key properties (owner, lifecycle status, business criticality) exist on the profile but are empty or free text on most elements. Dashboards show tables full of blanks.

3. Naming conventions vary by team or project. The same application appears as “SAP ECC,” “SAP ECC 6.0” and “ECC Core” across packages, and someone has to deduplicate by hand before any query can be trusted.

4. Profiles are undefined or unlocked. Architects can create any element type in any package with no enforcement. The repository is valid Sparx EA with no consistent semantic structure.

5. Connector types are not enforced. Realization, Association, Dependency and Serving connectors are used interchangeably, so the relationship graph cannot be traversed meaningfully for impact analysis or any other query.

If you recognize three or more of these, the return on any analytics or AI investment is capped until MDG governance is addressed.

What well-governed MDG looks like

Controlled vocabulary at the stereotype level. Every significant element type has a defined, documented stereotype with a clear purpose: «Capability», «ApplicationService», «DataEntity», «BusinessProcess».

Tagged-value schemas with controlled values. Where free text is acceptable, it is intentional. Where structured data is needed (lifecycle status, maturity score, regulatory classification), the tagged value uses an enumeration with a defined list.

Validation that runs routinely. Rules check for missing mandatory tagged values and wrong connector types before a package is baselined or reviewed, so drift is caught early.

Named MDG ownership. One person or a small team owns the master profile and manages changes through a lightweight change process. New stereotypes go through that owner.

Documentation in the repository itself. The MDG pattern library (stereotype descriptions, tagging guidance, usage examples) lives as a governed package in the repository, where architects and AI can both read it.

Fixing MDG governance, today and AI-augmented

How long it takes depends on how long the repository has run without governance and whether you are correcting existing elements or only governing new ones. The work follows a predictable sequence.

What AI can and cannot do with bad MDG

AI speeds up MDG governance work. It suggests stereotype assignments, flags elements that are missing tagged values, applies consistent naming and backfills values once the decisions are made. It cannot make the governance decisions that need business context.

It cannot determine the correct value for BusinessCriticality on an application it has no context for, and it cannot decide whether two differently named elements represent the same real-world asset. Those are judgment calls for an architect with domain knowledge. The skill this asks is stating the rules precisely enough to check, and reviewing the AI’s proposals with knowledge of the estate. Automation checks completeness, people own correctness.

Is MDG governance the same as naming conventions?

Naming conventions are one part of it. They govern how elements are labeled, which improves search and query results. MDG governance covers the deeper structure: which element types exist, what properties they carry and how they relate. You can have perfect naming and still have a repository that cannot be traversed meaningfully, because the connector types are wrong, the stereotypes are undefined or the tagged-value schema is missing. Naming is the surface of governance and the MDG is the structure underneath. Both matter, and the MDG matters more for queryability.

Frequently asked questions

What is MDG Technology in Sparx EA? MDG Technology is Sparx EA’s metamodel extension framework. It lets you define custom element types (stereotypes), structured properties (tagged values), visual rendering rules and validation constraints on top of any base notation: ArchiMate, UML, BPMN or a language of your own. MDG profiles give a repository a controlled, machine-readable semantic structure.

Why does MDG quality affect AI output? Any tool that queries the repository traverses element types, connector types and tagged values to answer questions. If those are inconsistently applied, the query returns incomplete or contradictory results. The tool reports what is in the repository, so a poorly governed repository produces poor answers. Improving MDG governance is the most direct way to improve output quality.

What does a well-governed MDG look like? Defined stereotypes for every significant element type, tagged-value schemas with controlled vocabularies, a named owner who manages the profile through a lightweight change process, validation that runs routinely, and governance documentation that lives in the repository.

How long does it take to fix MDG governance? It depends on how much ungoverned content the repository holds. Designing the profile is the quicker part. Bringing existing content into line takes longer, and that is the part AI speeds up most, because it can check and correct elements in bulk under the architect’s review.

Can an AI assistant fix bad MDG? It can do much of the mechanical work: flagging non-conforming elements, suggesting stereotype assignments and backfilling values. It cannot make the governance decisions that need business context, such as which applications are critical, whether two elements are the same asset, or what the correct lifecycle status is.

Is MDG governance the same as element naming conventions? Naming conventions are part of it. They govern how elements are labeled, which matters for search and readability. MDG governance covers the deeper structure: which element types exist, what properties they carry and how they connect. Both matter, and MDG structure has more impact on whether the repository can be queried meaningfully.

For the wider picture for architecture leaders, including how we help teams build the MDG and rules alongside the model, see We build and update your architecture model for you.