Validate a model against a ruleset

Goal

Run a conformance ruleset (the ArchiMate 3.1 set, your own file, or one hosted at a web address) against the whole model or one package, then interpret and fix the findings. This is for an enterprise architect or model steward preparing a review. You end with a triaged list of findings (real defects, rule limitations, and rules that matched nothing), fixes applied to the real defects, and a clean re-run.

Where it runs

This scenario needs the MCP server. Computer use covers its UI steps.

Before you start

• Enterprise Architect (EA) is running with the target model open, and the ea-start-here preflight is done. See Start a session safely.
• You have a ruleset: a web address (HTTPS), a local YAML file, or the text of one pasted into the conversation. The ArchiMate 3.1 ruleset ships with the skills library; see ArchiMate 3.1 ruleset.
• The stereotype names in the ruleset are the names EA actually stores in your model. EA's built-in ArchiMate technology stores names with an ArchiMate_ prefix (for example ArchiMate_Capability), and the shipped ruleset is written that way. A model whose ArchiMate content came from a different profile may name stereotypes differently, and the ruleset will not select those elements.
• For a bulk fix (more than about 25 elements): a baseline of the package first. See Protect a change with a baseline.

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 confirms the right model is open and which modeling technologies are loaded. You confirm the model.
2. AI ea-validation helps you choose the ruleset source and the scope: the whole model or one package subtree. You decide which ruleset and which scope.
3. AI Power Tools ea-validation proves the ruleset can match this model before it runs. It counts the stereotypes the rules select on (element stereotype counts, and a count of connectors by stereotype for connector rules). If the rules select nothing, the assistant tells you before it shows any audit result.
4. AI Power Tools ea-validation runs the audit, either the full ruleset or a quick demonstration subset. The audit is the audit operation of the ea_validate tool (ea_validate): it applies every rule to the repository and returns each violation with the rule id, severity, the element or connector concerned, a message and a one-line remediation.
5. AI ea-validation triages the findings: it groups them by rule and severity and separates real defects from rule limitations, reading the offending elements and connectors as evidence. You decide which findings are real.
6. AI Power Tools If the fix touches more than about 25 elements, ea-change-management offers a baseline. You accept or decline.
7. AI ea-modeling fixes the real defects: tag values, connector type or direction, a missing connector. AI Power Tools performs the edits; You approve each class of fix.
8. AI Power Tools ea-validation re-runs the audit and compares the result with the first run.

Why step 3 matters most. Zero violations because the model is clean, and zero violations because no rule selected anything, look the same in the audit output. The audit reports how many rules it evaluated and how many violations it found, but not how many elements each rule matched. So the skill checks coverage separately before it calls any model clean.

How rules select. An element rule matches elements by the exact stereotype name stored in the model, with no prefix stripping and no case folding. An optional filter narrows the candidates by a tagged value. A connector rule matches connectors by one exact connector stereotype. Five kinds of check are applied:

• a required tag must be filled in
• a tag's value must be one of an allowed list
• the number of connectors of a kind must fall within a limit
• the stereotypes at the two ends of a connector must be in stated lists
• the types declared in a technology's profile must match a built MDG file

Limiting the run to a package restricts the element rules to that package's subtree. Connector rules are not restricted by it: they evaluate every connector of the selected stereotype in the repository, so their findings can lie outside the package you chose.

Triage. Group findings by rule first. A rule that fires dozens of times on one connector pattern is more likely to be a limitation of the rule than dozens of separate modeling errors. For each group the assistant reads two or three offending connectors and the elements at both ends before deciding.

Apply this known limitation: the ArchiMate 3.1 ruleset has reported false positives, concentrated in its cross-layer endpoint rules (rule ids AM31-CLR-001 to 003). A connector-endpoint check requires the source and target stereotypes both to be in its lists, and it has no way to say "only when the source is X". Those rules select every connector of one stereotype (all ArchiMate_Serving connectors, for instance) but list a single source stereotype, so a legitimate connector with a different source is reported. Treat these findings as candidates to verify against the ArchiMate 3.1 specification, not as defects. The assistant states this to you rather than fixing connectors that were correct.

Fixes. Do not delete a connector to silence a rule until you have checked it against the specification. Deletes made through EA's automation interface cannot be undone, which is why a baseline comes first for anything bulk.

Prompts to use

Opening:

Follow-ups, by phase:

• Scope: "Run it on the whole model, but start with the quick demonstration subset."
• Triage: "Group the findings by rule. For the three rules with the most hits, pull two example connectors and tell me whether each is a real error or a limitation of the rule."
• Fix: "Fix the missing-tag findings only. Baseline the package first, then list what you changed."
• Re-run: "Run the audit again and show me the before and after violation counts per rule."

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, open the element or connector in EA (the assistant does this with computer use; otherwise you do) and confirm the message matches what is stored. For each error-severity finding left standing, name the specification clause or the model standard behind it. Red flag: a finding the assistant cannot tie to a clause or a standard.
• Complete. Confirm the coverage figures from step 3 are above zero for every category of rule in the ruleset. Confirm the number of rules evaluated equals the number of rules in the file (or the demonstration subset, if you chose it). Red flag: a clean result with a coverage figure of zero.
• Nothing unintended changed. The audit is read-only. After fixes, compare against the baseline and confirm the changed items are exactly the ones you approved. Re-run the audit: every fixed finding should be gone and no new rule should fire. Red flag: a new violation that appears only after a fix.

Variations

• Your own ruleset as a local file. Give the assistant the path. A path that does not exist is reported with the full path that was tried.
• A hosted ruleset by web address. The server fetches HTTPS only, refuses redirects, caps the size of the response at 2 MB and times out after 15 seconds. A refused or failed fetch produces a deliberately generic message.
• Pasted ruleset. Paste the rules into the conversation. A single line that contains a path separator or ends in .yaml is read as a path, so pasted rules need at least one line break.
• A package-only run. Use it to validate a newly built package before it is brought into the shared model.
• A model quality gate. The same audit can be run on a schedule you arrange yourself. The audit reports violations, not a pass/fail result; reading the violation count is up to whoever runs it.

Limitations

• A rule that matches nothing reports nothing. A selector one character off the stored stereotype selects nothing, and the rule stays silent. Always check coverage.
• Unsupported rule constructs are ignored, not rejected. A kind of check the server does not evaluate does not raise an error: the rule counts as evaluated and never reports a violation. Only a malformed rule, invalid YAML or an unknown mode fails loudly.
• Endpoint rules need both lists. A connector-endpoint check that lists only targets (or only sources) reports every connector it selects, because a missing list is treated as empty.
• An allowed-values check covers only filled-in values. A blank tag is not reported by it. Pair it with a required-tag rule to catch blanks.
• ArchiMate 3.1 cross-layer false positives are described above.
• Connector rules ignore the package scope.
• A write EA rejects can look like success. After fixing, re-read the element or re-run the audit rather than trusting the confirmation.