ea-mdg-assess

Logic: AI + AI Power Tools checks. AI Power Tools reads the facts and one rule-based classifier gives a first answer; the AI adjudicates between them and makes the recommendation.

What it is for

Use it to find out what modeling language you actually have before you author, build or change one. You end with the repository's modeling-language situation, and the real state of each technology: installed, stored in the model, enabled and loaded.

ea-mdg-assess works out which modeling-language situation a repository is in, before anyone authors or builds anything. It answers two questions that are easy to run together:

1. How much of the stereotype usage conforms to a technology? A classifier compares the stereotypes in use with the languages EA has loaded and places the repository in one of three scenarios.
2. What state is a given technology actually in? A technology can be installed on the workstation, registered in EA's Manage Technologies list, stored in the model file (at Location: Model or Location: Project), enabled or disabled there, and loaded in the current EA session. A technology disabled in Manage Technologies still counts as loaded to EA. These are separate facts, and no single call reports all of them. The skill reads each one separately and cross-checks the classifier against the evidence.

The skill is read-only. It writes nothing to the model and installs nothing. Its output is a decision: which of ea-mdg-author, ea-mdg-model-build or ea-mdg-deploy comes next, or that nothing is needed.

Capabilities it uses

When to use it, and when not

Run it at the start of any MDG task, when a stereotype behaves inconsistently between elements, or when the classifier's recommendation needs a second opinion.

How it works

1. AI Power Tools Run the classifier. assess_mdg_situation returns a scenario number, a plain-language description, the technologies it counted as loaded, the share of stereotyped elements it counted as covered, and a recommended next skill. This is rule-based: repeatable, and it can be wrong. The next steps exist to find out whether it is.
2. AI Read the description, not just the recommendation. The AI matches the description against the routing table in this section and against what it knows of the repository. It confirms that the recommended skill exists before passing it on.
3. (AI Power Tools; engine for EA's own loaded and enabled checks) Read the technology's state, one question at a time. What Manage Technologies would list, which copies the model file stores and at which Location, and what EA actually loaded and whether it is enabled. The AI reads the "how did you get this answer" label on the last of these before it reads anything else in it (see the tables below). It then compares the answers with the real Manage Technologies dialog AI with computer use; otherwise you.
4. (AI + AI Power Tools checks) Recompute the classifier's numbers. AI Power Tools supplies per-stereotype counts. The AI splits them into covered and ad hoc against the technology's own stereotype list and reproduces the two figures by hand. If they differ, the by-hand split wins, because the specific stereotypes can be seen.
5. AI Read past the number. A figure such as "91% covered" can hide one stereotype carrying the whole total, or near-duplicates of existing stereotypes (a fold-in problem) next to genuinely additional concepts (an extension problem). The AI separates them and says which fix each needs.
6. (engine, then AI) When there is no technology, take a census. The census resolves each stereotype to the profile it belongs to, counts the element types it sits on, the tagged values it carries and the values those tags hold. It does the same for connectors, counting the connector type each stereotype sits on. The AI looks for stereotypes used both ad hoc and profile-bound, stereotypes from other shipped languages that someone landed on by accident, elements carrying one technology's tag names under another's stereotype, and connectors whose stereotype name is written as qualified text but was never bound to a profile (a data defect, reported apart from ordinary ad hoc use). When a technology is loaded, the census can also be compared with what that technology declares, for elements and connectors: declared but never used, used but never declared, a different base type than declared, tag values outside a declared closed list, stereotypes bound to another language, elements carrying two of the technology's stereotypes, and connectors that carry a declared name without its binding.
7. You Choose the approach and accept its cost. Either a hand-authored file (ea-mdg-author) or a source model held in the repository (ea-mdg-model-build). The choice is one-way and is put to you explicitly. The AI does not default it.
8. AI Record the choice. The chosen approach, the date and, where relevant, the fact that the technology was generated from a census go into the technology's own notes, so the next maintainer knows where the source of truth is.
9. AI Hand off to the skill that matches the evidence.

What the three scenarios mean

The 5% threshold and the term "ad hoc" come from one test: does a stereotype in use appear in the stereotype set of a language the classifier counts as loaded? A technology counts as a client technology only when the model stores it (at either Location) and EA reports it loaded and enabled; one disabled in Manage Technologies is left out. See Limitations for what the classifier can and cannot count.

The four states of a technology

get_mdg_from_runtime needs the technology id. It reads the technology's definitions from the copy imported into the model or from the registered file, then reports how it got them. Always read that label first:

If EA reports one version and the definitions read declare another, EA is loading a different build than the one read. Resolve that before trusting either side. A technology whose file declares no version reports none.

The answer also says where the definitions came from: the model at Location: Model, the model at Location: Project, or a registered file. When the model stores the same technology at both Locations, the answer comes from the Project copy, which is the copy EA itself uses, and it names the other copy and the version that one declares. In the Westbrook illustration the model holds WBA 1.1.1 at Location: Model. Reading it returns 18 stereotypes (15 element and 3 connector), 3 diagram types and 3 toolbox pages, and Manage Technologies lists one enabled WBA with two other builds disabled.

Cross-checks, in the order that catches the most

1. Recompute from the usage table. Reproduce the classifier's two figures by hand. In a Westbrook-style example, 107 of 118 stereotyped elements are covered (91%) and 11 are ad hoc, and the two agree.
2. Compare with Manage Technologies in the UI. The registered-technologies list and the classifier have, by report, disagreed with EA's own dialog. The AI looks at the dialog (AI with computer use; otherwise you, with a pasted screenshot) and reads the Location, enabled flag and version of every row for the technology. Do not rely on a confident negative from the embedded-technologies list: it covers only what the model stores.
3. Confirm "loaded" and "enabled" with a second source: get_mdg_from_runtime for the exact id, and EA's own loaded and enabled checks through ea-com Engine when in doubt.
4. Check that the recommended skill exists. A recommendation naming a skill that is not installed sends the next step into a dead end with apparent authority. Match the description against the routing table in ea-start-here instead.
5. Expect reasons for a mismatch. A language loaded between the two calls; a stereotype carrying a :: namespace on one side and not the other (the classifier strips everything before the ::); or a Sparx-shipped language covering something unexpected, since "covered" includes every loaded shipped language, not only your technology.

The stereotype usage summary also reports, for each stereotype, whether it is bound to a profile or used ad hoc, plus which stereotypes appear in a split form and how many elements carry more than one stereotype. That is what lets the AI tell a governed element from an ad hoc one that carries the same name.

What you get

• A statement of the scenario, with the evidence behind it and the AI's view of whether it holds.
• For a named technology, its state: installed, registered, embedded, loaded, and which label the loaded answer carried.
• The covered and ad hoc split, recomputed by hand, with the near-duplicates and the genuinely additional concepts told apart.
• A recommendation for the next skill, and, where a technology has to be generated, a census and your recorded choice of approach.

Tools it relies on

• assess_mdg_situation, list_available_modeling_languages, get_embedded_mdgs, get_mdg_from_runtime, list_registered_technologies, get_mdg_search_paths: Discovering technologies and Managing technologies
• summarize_stereotype_usage: Summaries
• The profile-aware census helper described in Shared references (elements and connectors; an engine: needs local code execution)
• EA's own loaded-technology check, through ea-com (an engine script: needs local code execution)

Sample prompts

1. "What modeling-language situation is WestbrookBank.qea in? Is the WBA technology actually loaded?"
2. "The assessment says scenario 3 and recommends a skill. Double-check that before we act on it."
3. "Some Westbrook Bank elements show WBA stereotypes and others don't, in the same package. Why?"
4. "Manage Technologies shows WBA twice, once at Location Project and once at Location Model. Which one is EA using?"
5. "This repository has no technology but people clearly use a shared set of stereotypes. Can we generate one from what's there?"

Recommended models

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

Checking accuracy and completeness

1. Reproduce the classifier. Split the per-stereotype counts into covered (the stereotype is in the loaded technology's declared set, after stripping any Name:: prefix) and ad hoc. Correct: your ad hoc count and covered percentage equal the classifier's. Red flag: they differ and the AI reports the classifier's figures anyway.
2. Read the label on every "what EA loaded" answer. Correct: the report states the label and what it implies, and states whether the technology is enabled. Red flag: a report of "loaded" built on a registered-not-loaded, load-unknown or parsed-this-session answer, or a technology called "in use" while Manage Technologies shows it disabled.
3. Match the technology id to Manage Technologies. Correct: the id used is the id the dialog shows, and an "unknown id" answer is reported as "no technology under that exact id", not "not installed". Red flag: a conclusion that a technology is absent drawn from that answer, an empty embedded list, or a missing row in the registered list.
4. Confirm the recommended skill exists. Correct: the skill named is one of the four MDG skills or another installed skill. Red flag: a hand-off to a name that is not in the plugin.
5. Check the census is complete (when one was used). Correct: it reports its excluded counts (EA-internal and profile-authoring stereotypes), untyped elements and connectors, and multi-stereotype elements, and its element total reconciles with the usage table plus the exclusions. Red flag: a census total silently lower than the usage table.
6. Check the record. Correct: after a generation, the technology's notes carry the chosen approach, the date, and "generated from a census". Red flag: a generated technology with no provenance.

Limitations

• The classifier counts only some technologies as client technologies. A technology counts when the model stores it (at either Location) and EA reports it loaded and enabled. A customer technology that exists only as a file registered on the workstation is not counted: the classifier then reports scenario 1 and counts that technology's stereotypes as ad hoc. For a technology the model does store, whether its stereotypes count as covered appears to depend on whether the server has read that technology's stereotype list during the session; before it has, they may be counted as ad hoc. Treat the scenario number as a prompt to check, not a finding, and rely on the state reads.
• The list of languages is a probe, not an inventory. EA has no call that enumerates technologies, so the language list and the registered list can only ask about ids they already know, plus the technologies the model stores. A technology registered as a file under an unknown id is absent from both while loaded and enabled in EA. The Manage Technologies dialog shows what EA itself lists, so reading it through computer use (or asking you to) closes the gap.
• The recommended skill is rule-based and can be wrong. Decide on the description and the evidence.
• Disagreement with the UI has been reported between the classifier, the registered list and EA's Manage Technologies view. Cross-check in the UI.
• The census and the classifier treat EA-internal stereotypes differently. The classifier counts every stereotype, including EA's own tooling stereotypes, as ad hoc. The census excludes EA-internal and profile-authoring stereotypes and reports them separately. In the Westbrook-style example, nine tooling elements sit in the ad hoc count; they are tooling, not a concept to add to a technology.
• The worked examples in the skill's references were captured against a demonstration language. They show the shape of the answers. Your repository will not contain WBA.
• EA can block on a dialog. EA reports many failures as a modal dialog that waits for a person and blocks every later call, so a call that seems to hang is usually waiting on one (see Shared references). With computer use the AI sees the dialog in EA's window, reads it, uses the message to correct the call, dismisses it and carries on. Without computer use you screenshot the dialog and paste it into the conversation so the AI can analyze it, then dismiss it so processing can continue.