Assess the language situation

Goal

Work out which modeling-language situation a repository is in, ad hoc stereotypes or a real MDG Technology, and whether a technology is installed, embedded, actually loaded and enabled, before choosing how to change anything. For an MDG author, or an administrator investigating a stereotype that behaves inconsistently. You end with a short written assessment with the evidence behind it, the suggested next skill checked against the routing table, and a clear statement of what could not be determined.

Where it runs

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

Before you start

• The start-of-session check done.
• Optionally, computer use or a person at EA, to open the Manage Technologies dialog.
• This scenario changes nothing. No baseline is needed.

ea-mdg-assess runs the rule-based assessment (assess_mdg_situation) and then checks the answer. The assessment classifies the repository into a numbered situation from its stereotype usage and the loaded languages. That answer is a starting point. The skill adds supporting reads and a recomputation, because "registered", "embedded", "loaded" and "enabled" are different states, and the difference between them is usually the bug.

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-mdg-assess runs the assessment (assess_mdg_situation, rule-based). It returns a situation number, a plain description, the loaded technologies, the Sparx-shipped languages loaded, the count of ad hoc stereotypes, the percentage of elements covered, and a suggested next skill. A technology disabled in Manage Technology is left out of the loaded technologies. For a model with a client technology loaded, a typical finding has this shape: a client-built MDG Technology exists, but ad hoc stereotypes are accumulating outside it (for example, 11 ad hoc stereotypes, with 91% of elements covered).
2. AI Power Tools ea-mdg-assess checks registration, embedding, load state and enabled state. Read the source of the runtime reading first. The reads cover both Locations: they report where the technology is stored (Project or Model), the version that stored copy declares, and, when the same id is stored at both Locations, the other copy and the fact that the Project copy shadows the Model copy. A stored copy that cannot be read is reported as unreadable and not skipped.
3. AI Power Tools ea-mdg-assess checks whether a file on EA's search path is shadowing the model's copy (get_mdg_search_paths, with a folder to check).
4. Engine ea-mdg-assess recomputes the assessment's numbers from the stereotype tally and the shared census module, to check that the covered share comes from stereotypes doing real work and not from one stereotype used everywhere plus a few edge cases. The census reports stereotype provenance for connectors as well as elements: each stereotype resolves to the profile it is bound to or is reported as ad hoc, and a qualified name typed into the stereotype field with no binding is reported apart as a data defect. Given the technology's definition, it also reports connector drift (see below).
5. AI with computer use; otherwise you Cross-check in EA's Manage Technologies dialog (Specialize, Technologies, Manage Technology, with "Hide disabled Technologies" unticked). Confirm exactly one entry for your technology id and read its Location (Model, Project, or a file name) and whether it is enabled. More than one entry means something is shadowing something else, as when the id is stored at both Project and Model. With computer use, the AI opens it (ea-help) and reads it back to you. Without, you look and report what you see.
6. AI ea-mdg-assess states its finding in the description's terms and checks the suggested skill against the routing table of ea-start-here. Never route on that field alone.
7. You Confirm the classification and the next skill. Override the suggestion when you know something it cannot: a source model exists, or the technology is small enough to write by hand.

A version mismatch in the reading means EA reports one version and the definitions declare another, so EA is loading a different build from the one read. Resolve that before trusting either side. A technology that declares no version reports none, so an empty version is a fact about the file and not a failed read.

Shadowing. Two kinds can hide the copy you meant to test.

• A file on EA's search path. EA auto-registers any MDG file it finds on its search path, which can include a Downloads folder. A build written there registers itself, shadows the model's own copy, and makes a deployment look right on the author's machine and wrong everywhere else. When the search path could not be read from the Windows registry, the check is marked unverified and the paths are unknown, not absent.
• A Project copy of the same id. When the model stores the id at both Locations, EA lists both in Manage Technology and answers from the Project copy. The runtime reading says so, names the other copy and the version it declares, and tells you to remove the copy you do not want in Manage Technology.

Profile-aware counts. The stereotype tally also resolves each stereotype to its profile and marks it bound or ad hoc, lists names that appear both ways, and counts elements carrying several stereotypes. The skill's census module gives a profile-aware count in the same terms, and gives the same for connectors.

Connector drift. Where a technology declares connector stereotypes, as the Westbrook technology does with Uses, Flows and realizes, the census compares what the technology declares with the connectors the model holds. It reports a declared connector stereotype that no connector uses; a connector that carries a declared name without being bound to the technology (a bare Uses or another language's Uses); a connector stereotype whose base type differs from the declared one; connector stereotypes bound to another shipped language, so you can check the choice was deliberate; connector stereotypes bound to no profile, which is ad hoc use; a qualified name typed into the stereotype field with no binding; and, as for elements, connector tagged values that are in use but not declared, declared but never filled in, or outside the declared list of values. EA stores the stereotype of a bound connector by its bare name, so the stored name alone cannot tell you which of these a connector is. The binding does.

Prompts to use

Opening

Follow-ups

The connector census and its drift findings, with local code execution.

Recommended models

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

Checking the result

• Accurate. The reported situation's numbers reproduce from the stereotype tally. The source and the Location of each technology agree with Manage Technologies, and a technology you see disabled there reads as registered but not enabled. Every skill named as a next step exists in the routing table.
• Complete. The assessment states: the situation and its reason, the loaded, enabled and registered technologies, where each is stored and whether a copy at the other Location shadows it, the shadow check result for the search path (or that it could not be determined), the connector provenance with any drift, and any state the tools disagree about.
• Nothing unintended changed. This scenario is read-only. If it wrote anything, something is wrong.

Variations

• Second opinion on a stereotype that behaves inconsistently. Start at step 2. A stereotype can come from a technology that is registered and not loaded, or loaded and disabled.
• Generation case. In situation 1 with real stereotype usage, continue to Generate an MDG Technology from current usage.
• Declared against observed. Comparing what a technology declares with what the model uses is Compare declared and observed usage.
• Version drift. Use the version-mismatch note, the Location of each stored copy and the shadow check together when only one user sees a different version of the technology.

Limitations

• Cross-check with Manage Technologies when it matters. assess_mdg_situation and the registered-technology list have been reported to disagree with EA's own view.
• A technology disabled by an unticked box, with no copy stored in the model, may be missing from the registered-technology list. EA's automation interface has no technology list, so such a technology cannot be told apart from "not registered" through that list. The result's completeness note says so. Asked for by id, the technology reads as registered but not enabled. The Manage Technologies dialog shows it, so the cross-check settles it: the AI opens the dialog with computer use, or you do.
• The list of available modeling languages is not exhaustive. It combines the technologies the model stores, fixed tables and a probe list.
• The embedded-technology list shows what the model stores. A technology loaded from a file on the machine is not stored in the model and is not in it. Use the runtime reading and the registered-technology list for that case.
• A stored copy can be unreadable. The reads then report the copy as unreadable. Export it from Manage Technology and have the AI read the exported file.
• The loaded check is scoped to the session. A technology loaded in this session may not be loaded after a restart.
• Setting an active technology records a preference only and enforces nothing. To enforce conformance, run Validate a model against a ruleset.