ArchiMate 3.1 ruleset

Logic: Deterministic. A data file the validation engine evaluates; no AI judgment at run time.

What it is for

Use it to check an ArchiMate model in EA against the structural rules of the ArchiMate 3.1 specification, or as the pattern for writing a ruleset for another language. You end with every element and relationship that breaks one of its rules, reported by rule.

ruleset-archimate31 is a shipped YAML ruleset that checks an EA model built with EA's own ArchiMate technology against the structural rules of the ArchiMate 3.1 specification (The Open Group). It contains 27 rules in 6 categories: relationship endpoint validity, collaboration structure, interaction assignment, well-formedness completeness, implementation and migration structure, and cross-layer endpoint patterns.

It is a data file, not a skill: it carries no skill file, the AI does not follow it, and nothing in it changes at run time. The ea_validate audit operation reads it, ea-validation is the skill that runs it, and ea-ruleset-author names it as the reference implementation for writing a ruleset for another language.

Capabilities it uses

When to use it, and when not

Use it to get a first structural conformance read of a model built with EA's ArchiMate technology. It is a screening check, not a certification: read the Limitations before acting on a violation.

How it works

1. You Point the AI at the model and ask for the ArchiMate 3.1 conformance run. Choose the whole model or a package subtree, and the full scan or demonstration mode.
2. AI Power Tools Run the ruleset. ea_validate audit evaluates the 27 rules (or the nine demonstration rules) and returns the violations, each with the rule's remediation text as written in the file. The ruleset never modifies the model.
3. (AI + AI Power Tools checks) Confirm the rules matched something. After a clean or sparse result, the AI counts candidates, for example elements whose stored stereotype begins with ArchiMate_. A model with no ArchiMate-technology elements returns zero violations with every rule dead.
4. (AI, you) Review each violation as a candidate, not a verdict. The AI separates probable real defects from the known false-positive patterns below, and you decide what to fix.

Variations.

• Demonstration mode runs only the nine demonstration rules (5 relationship, 1 collaboration, 1 interaction, 2 well-formedness).
• A package scope limits the element rules (collaboration, interaction, well-formedness and implementation) to one package subtree. The connector rules (relationship and cross-layer) and every connector count are not limited by a package.
• The ruleset can be run from its hosted location, with nothing installed (the server fetches the file at call time and needs network access and HTTPS), or from a local copy in the AI Power Tools rulesets folder, %USERPROFILE%\.claude\ai-power-tools\rulesets\ruleset-archimate31\archimate31_rules.yaml (~ and %VAR% are expanded; see ea-validation). The server refuses redirects, so a hosted address must be a direct link to the raw file.

What it checks

The rules reference 61 element stereotypes and 10 relationship stereotypes (Access, Aggregation, Assignment, Association, Composition, Flow, Influence, Realization, Serving, Triggering). Specialization and Junction are not covered. The ruleset checks structure, not the derivation of relationships.

What the count rules measure. The collaboration, interaction, well-formedness and implementation rules count connectors of one named stereotype in one direction at the selected element. They do not check the stereotype of the element at the other end. A rule described as "assigned from a Node" is satisfied by an Assignment from any element.

Warnings are "should" rules. The well-formedness and implementation rules express recommended structure ("should have a performer"), not conformance, and many valid models will not satisfy all of them.

How it behaves

Stereotype names are prefixed, and matching is exact. Every name in every rule is ArchiMate_<Concept>. That is the string EA's built-in ArchiMate technology stores for elements and connectors, which the engine matches exactly, with no normalization and no prefix stripping. The file's header records the measurement behind this: all three ArchiMate technology generations EA ships declare the prefixed form, 73 of the 94 stereotype names in the ArchiMate 3 technology file carry it, and in the model Sparx ships with EA, 123 elements across 32 stereotypes and 116 connectors across 10 carry it. Each stereotype also has a display-name attribute without the prefix; that is the notation's concept name, not the stored stereotype. The profile-qualified form (ArchiMate3::ArchiMate_Capability) is held elsewhere in the model, so a rule written that way would match nothing.

Matching is single-form on purpose. A prefix-tolerant comparison was considered and rejected on measured evidence. The same model that carries ArchiMate also holds elements stereotyped BusinessProcess (BPMN 2.0), DataObject (BPMN 2.0), Resource (BPMN 2.0), BusinessService (TOGAF) and CourseOfAction (BMM). Tail matching would pull those into an ArchiMate conformance run and report violations against elements that were never ArchiMate. The cost is stated plainly: a model whose ArchiMate content comes from another profile (a hand-built one, or a third-party technology that names its stereotypes without the prefix) is not selected by these rules. The way to serve such a model is a copy of the file with the prefix removed, not a looser match.

Consequence if you use a different ArchiMate technology: zero violations and zero matched elements are the same output. Confirm a nonzero match before reporting a model clean.

How it is tested. The ruleset ships with one test file of 12 hermetic tests: EA is never started and no model file is opened. The test builds an in-memory copy of the two tables the engine queries (elements and connectors), populated from stereotype names measured on EA 17.1 build 1716, then replays the engine's selection against it. The measured constants are not derived from the ruleset, so a test cannot pass by construction: one comes from EA's ArchiMate 3 technology file, the others from the model Sparx ships.

The test needs the YAML library and expects the ruleset in a folder layout where it can be found two levels up from the test; the two tests that look at sibling skill folders are skipped where those skills are not alongside.

Known false positives

The following behaviors follow from how the rules are written. They can make a conformant model report violations, so treat each reported violation as a candidate to review, and treat cross-layer results with particular caution.

• Endpoint rules apply both lists to every connector they select. A connector is reported when either end falls outside its list.
  • The two cross-layer Serving rules each name a single allowed source stereotype (ArchiMate_ApplicationService in AM31-CLR-001, ArchiMate_TechnologyService in AM31-CLR-002) but select every ArchiMate_Serving connector. Read literally, each rule reports every Serving connector whose source is anything else, so a Serving connector is likely to be reported by at least one of the two.
  • AM31-CLR-003 is written the same way for Realization: it allows two source stereotypes (ArchiMate_ApplicationInterface, ArchiMate_TechnologyInterface) and selects every Realization connector. Its target list also includes ArchiMate_BusinessInterface, an interface, while the rule's description says an interface-to-interface Realization is the error.
• Relationship rules report a connector whose far end carries no ArchiMate stereotype, or another notation's stereotype, because that end is not in the allowed list. A relationship drawn to an element from another language will be reported even if the model is deliberate about it.
• The count rules approximate the specification. They count one connector stereotype and do not check the neighbor. For example, AM31-IMP-002 describes a Plateau as containing elements by composition or aggregation, but counts outgoing Composition only, so a Plateau that contains its elements by Aggregation is reported.
• Warnings can be legitimate design. A behavior element with no performer, or a Gap with no Association, is recommended structure missing, not a defect in every model.

What you get

• A violation list in the standard audit shape (rule id, severity, element id and name, message, remediation), with the rule's remediation text as written in the file.
• A model-matching statement: how many ArchiMate elements and connectors the rules actually selected.
• The AI's separation of likely real defects from the known false-positive patterns.

Tools it relies on

• ea_validate audit, which runs the file by address or path: ea_validate
• ea-validation, the skill that tells the AI how to run a hosted ruleset
• ea-ruleset-author, which uses it as the reference implementation for a ruleset for another language
• execute_sql (read-only), to count the elements and connectors the rules select: Direct queries
• The ArchiMate 3 notation binding of Notation bindings, which declares the same ArchiMate_ prefix; the ruleset's own test checks the two agree

Sample prompts

1. "Run the ArchiMate 3.1 conformance set against the Westbrook application layer and summarize what you find."
2. "Run only the demonstration rules from the ArchiMate 3.1 set and tell me how many elements they matched."
3. "The ArchiMate ruleset flags every Serving connector in the model. Is that real?"
4. "Which of these ArchiMate violations are probably false positives, and which should I fix?"
5. "Our ArchiMate content comes from a different technology. Adapt a copy of the ArchiMate 3.1 ruleset to its stereotype names and test it."

Recommended models

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

Checking accuracy and completeness

1. The ruleset matched ArchiMate elements. Count elements whose stored stereotype begins with ArchiMate_ and connectors carrying one of the ten relationship stereotypes. Correct: nonzero counts where the model has ArchiMate content. Red flag: a clean result in a model with ArchiMate content but a count of zero, which means the model uses a different technology's names.
2. Rules evaluated. Correct: 27 in a full scan, or 9 in demonstration mode. Red flag: a smaller number.
3. A reported violation can be reproduced from the rule. Read the rule's source and target lists and the connector's stored ends. Correct: the connector's ends really fall outside the lists. Red flag: a violation whose ends are inside the lists (which would mean the engine read something different from what you expected).
4. Cross-layer results were reviewed against the false-positive patterns. Correct: every cross-layer violation is explained as a real defect or as one of the patterns above. Red flag: all Serving connectors accepted as defects.
5. Scope behaves as intended. With a package scope, only element rules are limited. A connector violation outside the package is expected.
6. A planted violation is reported. For example an Assignment from a data object to a process. Correct: the expected relationship rule reports it. Red flag: no report, which suggests a dead rule or a different technology.

Limitations

• Known false positives (see above): the shipped rules can report violations on conformant models, because a rule cannot be made conditional on another property. Treat each reported violation as a candidate to review, and cross-layer results with particular caution.
• Warnings are "should" rules, not conformance.
• Only models built with EA's built-in ArchiMate technology are selected. See the prefix note.
• Scoping is partial. A package scope does not limit connector rules or connector counts.
• No matched-count in the output. A dead rule and a satisfied rule look the same.
• Specialization and Junction relationships are not covered, and the ruleset checks structure, not the derivation of relationships.