Find ungoverned elements

Goal

Before building the business layer for reporting, list the in-scope elements that carry no stereotype (so no business table will hold them), suggest a stereotype only where the evidence in the repository supports one, and refuse to guess where it does not. This is for an architect or data steward preparing a portfolio report. You end with a decision per element (apply a stereotype, choose among candidates, extend the technology, or accept the exclusion), with the exclusions stated.

Where it runs

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

Why this matters

An element with no stereotype lands in no entity table of the business layer (Build a reporting database). The one exception is when you choose to include everything in the repository, which gives such elements a table keyed by their element type. Otherwise the element is simply absent, and nothing says so. That is a data-quality finding when the element carries governance data anyway. On the Westbrook reference model, three components carry a full tag set (Business-Critical, a financial-privacy regulation, both owners named) and no stereotype. Somebody classified them deliberately, and no report would ever have shown them. The governance gate leads with elements like these.

The gate is a rule-based code engine. It gives each ungoverned element one of three outcomes, which are kept apart on purpose:

The gate weighs three signals, in this order. The element type is a hard filter: a stereotype that extends Component cannot be applied to a Node. Package locality is the evidence that decides: which stereotype do the element's stereotyped neighbors carry? Tag fit only counts against a candidate: an element that carries only the common tags is not offered a stereotype that declares tags it does not have, and a candidate is out if the element carries a tag the stereotype never declares. A stereotype is suggested only when one candidate leads on both locality and tag fit.

The Westbrook technology shows why "several candidates" exists. Ten of its fifteen element stereotypes declare an identical six-tag set, so for an element carrying those six tags, tag overlap scores three of the seven Component stereotypes exactly the same. Choosing the alphabetically first would be a guess presented as a recommendation. Run over the Westbrook Bank package, the gate finds 65 elements with no stereotype: 3 carry governance tags, none gets a suggestion, 19 need a choice, and 46 have no candidate (requirements and UML behavior elements, which the technology does not extend). The three governed components need a choice. Their package neighbors are vendor systems, but the vendor-system stereotype declares three tags those components do not carry, so it does not also lead on tag fit; the report lists it first among five candidates. These figures show the shape of an answer, not what to expect on your repository.

Before you start

• EA is running with the model open, and the technology loaded in the session. If it is not loaded, EA records an applied stereotype as ad hoc, with no binding to the technology, and the element still lands in no table. Installed, embedded, loaded and enabled are different states; check with ea-mdg-assess (ea-mdg-assess).
• A scope: the root packages to report on, and any packages to leave out. When you run the gate while building a reporting profile (Build a reporting database), it uses the profile's scope.
• Local code execution, with Python 3 on the machine. The gate is a code engine that ships with the skills, not a server operation, so it is an Engine step. It needs nothing beyond Python's standard library. See Census, inclusion choice and governance gate. See Supported clients for where local code execution is available.
• A baseline of the packages you may change. Applying a stereotype is the one step here that writes to the model.

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 runs the session preflight, and ea-reporting-database reads the technology's stereotypes, the element types they extend and their tags from the running session (get_mdg_from_runtime, Discovering technologies).
2. AI Power Tools ea-reporting-database reads the package tree, the in-scope elements and their tags with direct queries (Direct queries). You confirm the scope.
3. Engine The governance gate finds the elements that carry no stereotype and gives each one its outcome and reason. It skips package objects, because EA stores every package twice and nobody stereotypes the mirror. Elements that carry filled-in tags sort first.
4. AI ea-reporting-database presents the report: for each element, its package path, the tags it carries, the outcome and the reason. You decide per element.
5. AI Power Tools ea-change-management takes a baseline, then ea-reporting-database applies the stereotypes you chose (update_element, Elements). You approve each application.
6. AI Power Tools ea-reporting-database reads the elements and their stereotype bindings again, and Engine the census confirms that each element is now placed under the technology.
7. AI If you declined anything, ea-reporting-database states what will be missing and records the counts with the build. You accept the exclusion.

Step 2, scope. Only the scope is read: the root packages and everything under them, minus the packages you leave out. A package path from the root is shown with each element, so two similarly named packages cannot be confused.

Step 5, applying. The assistant applies the bare stereotype name (WBAVendorSystem, not WBA::WBAVendorSystem). With the technology loaded, EA resolves the bare name against it and records the binding itself, giving a profile-bound application. Do not trust the confirmation alone. The edit reports a warning when the written value does not read back, and EA can accept the write and drop a stereotype whose base type does not match the element's type. Step 6 verifies.

Step 7, declining. Declining is a valid answer. The assistant states the consequence, for example "six elements will not appear in the reporting layer, three of which carry governance tagged values including one marked with the regulation", and records the counts with the build so the layer can later say what it left out. Unstereotyped diagram furniture (package objects, notes, text, boundaries) is left out of that count, because it is never model content and never gets a table.

Prompts to use

Opening:

Follow-ups:

• Decide: "For the three governed components, list the candidates with your reasons. I'll choose. Baseline the package before you apply anything."
• Refuse: "Don't guess on the ambiguous ones. List the candidates for each and I'll tell you."
• Extend: "For the requirements, what would extending the technology involve?"
• Verify: "Read the elements again and re-run the gate. Show me what is still ungoverned and what I declined."

Recommended models

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

Checking the result

• Correct. For each suggestion, read the reason (which neighbors carry the stereotype) and check it against the package contents. After applying, the element reads back as bound to the technology, not ad hoc. Red flag: an applied stereotype that reads back as ad hoc, or a suggestion for an element the report listed as needing a choice.
• Complete. The count of ungoverned elements equals applied plus declined plus still outstanding. Elements carrying governance tags come first, and every outcome carries a reason.
• Nothing unintended changed. The baseline comparison shows only the stereotype changes you approved, as "Changed" items.

Variations

• This gate is a step in building the business layer (Build a reporting database), after the inclusion choice. Run it alone when you want only the findings.
• Extend the technology for no-candidate elements, using the modeling-language scenarios in Governance.
• Run it on one package before a review of that package.

Limitations

• Package locality is the deciding signal. A model that keeps mixed stereotypes in one package, or is organized by domain rather than by type, often yields "several candidates". That is correct, not a defect.
• Tag fit is a weak signal when the technology's stereotypes share one tag set, and a stereotype that declares tags the element lacks scores lower even when it is the right one.
• The gate covers elements with no stereotype at all. An element carrying an ad hoc stereotype, or one from another language, is a gap for the inclusion choice (Build a reporting database) or a finding in Compare declared and observed usage, not a gate finding.
• The gate is a code engine. It needs local code execution, and without it this scenario is not available.
• Only the stereotype edit writes to the model. A wrong stereotype applied in bulk is exactly the change a baseline exists to undo.