Compare declared and observed usage

Goal

Compare what a modeling technology declares (element and connector stereotypes, base types, tags, permitted values) with what the repository actually uses, and report the gaps as findings. This is for an MDG owner or architecture governance lead. You end with a list of findings of defined kinds, for elements and for connectors, each with its subject and evidence, and a decision per group on whether to fix the model or extend the technology.

Where it runs

This scenario needs the MCP server and local code execution. Computer use covers its UI steps.

How it works

The technology declares what should exist. The repository shows what does. The gap is reported, never corrected. Two code engines shipped with the skills do the work. The census counts elements and connectors by the stereotype they are actually bound to, read from EA's binding records rather than from the bare stereotype name an element shows, and measures how many elements actually fill in each tag. The comparison sets that census against the technology definition read from the running session, separately for elements and for connectors, and produces findings sorted by kind and subject. A stereotype counts as the technology's only when it is bound to the technology; the same name carried ad hoc, or bound to another language, is reported as such.

The kinds of finding, for elements:

The same kinds apply to connectors (declared but unused, ad hoc, from another language, base type mismatch, and the tag and value kinds for connector tags), plus two that only connectors have:

On the Westbrook reference model, the connector comparison illustrates the point: of the connectors that store Uses, most are bound to the WBA technology and some to a shipped business-motivation language, which is a "declared name, not bound" finding, while extends and part-of are bound to nothing, which makes them "observed, never declared". The stored name is the same in every case; only the binding tells them apart.

Before you start

• EA is running and the technology is readable in the session. Without it there is nothing to compare against. Installed, embedded, loaded and enabled are different states; see ea-mdg-assess.
• A scope: the whole repository, or root packages to compare. Take the census over the scope you care about, not the whole repository, when only part of it is governed by the technology.
• Local code execution, with Python 3 on the machine (see Supported clients). The engines use Python's standard library only. They are described in Census, inclusion choice and governance gate. Without local code execution the comparison is not available.

Steps

1. AI with computer use; otherwise you If EA is not running or the model is not open, start EA and open it. AI Power Tools ea-start-here and ea-mdg-assess confirm the technology is loaded and read its definition (get_mdg_from_runtime, Discovering technologies). You choose the technology and the scope.
2. AI Power Tools ea-mdg-assess reads the in-scope elements, connectors, their stereotype bindings and their tags with direct queries (Direct queries).
3. Engine The census counts elements and connectors by bound stereotype, and how filled in each tag is.
4. Engine The comparison runs, declared against observed, for elements and for connectors. It is rule-based. Without the tag figures it produces stereotype-level findings only; with them it also produces the tag and value findings.
5. AI ea-mdg-assess interprets the findings and separates accident from intent. You decide what counts as drift here.
6. AI ea-mdg-assess reports the findings with counts, grouped by kind, including the values outside a declared list.
7. AI ea-mdg-model-build or ea-mdg-author is the follow-up, per group. You decide: fix the model, or extend the technology.

Steps 3 and 4. The engines are pure: they read rows already fetched and return a list. They never touch EA. Elements carrying several stereotypes are counted correctly, and a tag counts as covered only where it is filled in, not merely present.

Step 5, reading the findings.

• A finding of a stereotype from another language, with a few instances, is usually the wrong toolbox item. Several languages in light use is usually accident, not design, and extending the technology to bless it makes it permanent.
• A probable misassignment is a suggestion with a reason, not a fact. Where the evidence is weak, the comparison returns nothing rather than guess.
• A value observed but not declared is the finding the organization cannot see in EA's interface. One typo and a whole undeclared convention look different in the count per value.
• A declared connector name that is not bound to the technology is usually a connector drawn from another language's toolbox, or typed by hand. Re-applying the stereotype from your technology's toolbox binds it.
• Casing matters. realizes and Realizes are different names to the comparison, as they are to EA.

Prompts to use

Opening:

Follow-ups:

• Interpret: "For the stereotypes from other languages, tell me which look like toolbox mistakes and which look deliberate."
• Connectors: "Which connectors carry Uses but are not bound to WBA? What are they bound to?"
• Values: "Show me every value outside the declared criticality list and how many elements use it."
• Decide: "For each group, tell me whether I should fix the elements or extend the technology."

Recommended models

Ratings are guidance based on the kind of reasoning the scenario needs, not measured benchmarks.

Checking the result

• Correct. For a sample of findings, check the detail in EA: an undeclared value actually on the elements named, an ad hoc stereotype actually bound to nothing, a connector actually bound to another language. Red flag: a finding for a stereotype that EA shows as correctly bound.
• Complete. The comparison covered every element and connector stereotype the technology declares, and every observed one in the scope. EA's own machinery and profile-authoring stereotypes are left out of the census, and the exclusion is counted rather than silent.
• Nothing unintended changed. Read-only. The report is the output; model changes happen only if you then act on it, with a baseline.

Variations

• Refresh drift in the business layer. Every build and refresh of the business layer (Build a reporting database) flags stereotypes and connector kinds that the saved inclusion choice does not cover, and a changed technology version. That is the reporting-side signal; this scenario is the full comparison.
• Before extending a technology. Run this first; findings of "observed, never declared" are the candidates.
• Merge into the assessment. Assess the language situation covers assessing the language situation; this is its quantitative companion.

Limitations

• Declared ranges only. A value can be outside a list only where the technology declares one. Free-text tags are not enumerations, so the tag and value findings apply only where a value list is declared.
• Without the technology readable in the session, nothing can be compared.
• Names are compared exactly. A spelling or casing variant is a different stereotype to the comparison.
• The engines need local code execution. Without it this scenario is not available.