Author a ruleset

Goal

Write a complete ruleset for a modeling language (required tags, allowed values, connector counts, endpoint stereotypes) and prove it against known-good and deliberately bad content. This is for an MDG author or the owner of modeling standards. You end with a tested ruleset file that the audit can run from a path or a web address, with rule ids, severities and one-line remediations.

Where it runs

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

Before you start

• The language is installed and loaded in EA, with some real content, so stereotype names can be measured from the model rather than assumed. For a technology you built yourself, the assistant can read the declared stereotypes, tags and allowed values back from EA (get_mdg_from_runtime, see Discovering technologies).
• A package of known-good content, and permission to create a scratch package for deliberately bad content. You delete it afterward.
• The language's specification, or your own standards document, for the rule descriptions.

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-ruleset-author inventories the language: declared stereotypes, tags and allowed values, plus how the model actually uses them (stereotype, tag and base-type usage summaries; see Summaries).
2. AI ea-ruleset-author works out which of your standards can become rules and which cannot. You decide the scope of the standard.
3. AI ea-ruleset-author plans rule categories and rule ids (of the form language, category, number), and picks about 30 percent of the rules as a quick-check subset. You set the severities.
4. AI Power Tools ea-ruleset-author measures the stereotype names exactly as the model stores them.
5. AI ea-ruleset-author writes the ruleset file: a descriptive header followed by the rules. You review the rules.
6. AI Power Tools Test 1: ea-validation runs the audit on known-good content, and ea-ruleset-author confirms every rule matched at least one element.
7. AI Test 2: ea-modeling builds a scratch package of deliberate violations, and ea-validation runs the audit scoped to it. You approve the scratch content.
8. AI ea-ruleset-author iterates until every deliberate violation is reported by the intended rule and nothing else, then deletes the scratch package. You confirm the deletion.
9. AI Power Tools Optional, if the ruleset will be hosted: ea-validation runs the audit from the web address to prove that fetching the ruleset from its web address works.

The audit's rule format is small. Elements are selected by a list of stereotypes, with an optional tag-value pre-filter. Connectors are selected by one connector stereotype. The five kinds of check are those listed in Validate a model against a ruleset. A rule your standard needs that these cannot express (for example "only when the source is in package X", or "the target's lifecycle must not be Deprecated") cannot be written. Say so, and decide whether to enforce it by review instead.

Step 4 matters most. The audit selects with an exact comparison against the stored stereotype name. Write the name without the technology namespace (no WBA::), but otherwise exactly as stored. A prefix that is part of the stereotype's own name stays: EA's built-in ArchiMate technology stores ArchiMate_Assignment, while its BPMN technology stores a bare BusinessProcess. Measure per technology. Do not infer the name from the specification or from how an MDG declares it.

An illustrative pair of rules. Westbrook's AI stereotypes carry a modelGovernanceClass tag that Mission-Critical elements must fill in. In the rule format that is two rules, because "is filled in" and "has an allowed value" are separate checks:

Each rule carries a one-line remediation ("Set modelGovernanceClass to an approved tier"). Use your own stereotype, tag and value names. Tag values are strings. For connector direction, "outgoing" means "this element is the source".

Step 7, the bad content. Create elements that should trigger each rule (a Mission-Critical gateway with a blank tag; a gateway with a misspelled value) and elements that must not (a Standard-criticality service with a blank tag). Run the audit scoped to the scratch package. Rules that select by stereotype report only on the scratch content. If you test a connector rule, remember it is not limited by the package scope, so it may also report real connectors elsewhere in the model.

Prompts to use

Opening:

Follow-ups:

• Plan: "Group the rules into categories, give them ids, and mark the five most useful for a quick check."
• Write: "Write the rules. Measure each stereotype name from the model first and show me how you measured it."
• Test: "Create a scratch package with one deliberate violation for each rule and one near-miss that must not fire. Run the audit scoped to it and show which rule caught what."
• Close: "Delete the scratch package and run the ruleset on the real package. Tell me how many elements each rule matched."

Recommended models

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

Checking the result

• Correct. Each deliberate violation is reported by exactly the rule you intended, with the right element name and message. Each near-miss is not reported. Red flag: two rules reporting the same violation, or one violation reported by the wrong rule.
• Complete. Every standard on your list is either a rule or explicitly recorded as not expressible. On known-good content, the stereotype counts show every rule's selector matched at least one element. Red flag: a rule that matched nothing on content you know contains its stereotype.
• Nothing unintended changed. Authoring writes a file; the model changes only in the scratch package. After step 8, confirm the scratch package is gone and the element count in the real package is unchanged.

Variations

• A language you do not own (ArchiMate, BPMN, UML). Measure stored stereotype names from a model built with the shipped technology, and cite the specification section in each rule description.
• Pair with an MDG. For every required tag in your MDG, add a required-tag rule, and an allowed-values rule for every enumeration. See the modeling-language scenarios in Governance.
• Check a built MDG. The profile-types check compares a profile's tagged-value types with a built MDG file, which you point it to.

Limitations

• The rule format has no guard construct and no cross-element comparison (see Validate a model against a ruleset and Catch a non-conforming change). Do not promise rules the validator cannot evaluate.
• The descriptive header of the file is ignored at run time. Keep it for readers, and cite sources there.
• A ruleset is a file you write with the assistant. The validation tool runs the audit against it; see ea_validate.
• Zero violations on the real model is a result only when the selectors matched. Check coverage every time.
• A host that has just received a new file may not serve it immediately. A failed fetch right after publishing can be timing.