feat: Add GoM (Grundsätze ordnungsmäßiger Modellierung) semantic anchor

docs/all-anchors.adoc

@@ -111,6 +111,8 @@ include::anchors/clean-architecture.adoc[leveloffset=+2]
 
 include::anchors/domain-driven-design.adoc[leveloffset=+2]
 
+include::anchors/gom.adoc[leveloffset=+2]
+
 include::anchors/hexagonal-architecture.adoc[leveloffset=+2]
 
 include::anchors/madr.adoc[leveloffset=+2]

docs/anchors/gom.adoc

@@ -0,0 +1,48 @@
+= GoM
+:categories: software-architecture
+:roles: software-architect, business-analyst, consultant, team-lead
+:related: arc42, c4-diagrams, morphological-box
+:proponents: Jörg Becker, Michael Rosemann, Rolf Schütte
+:tags: modeling, enterprise-architecture, business-process, bpm, principles, quality
+
+[%collapsible]
+====
+Full Name:: Grundsätze ordnungsmäßiger Modellierung (Principles of Proper Modeling)
+
+Also known as:: GoM Principles, Principles of Well-formed Modeling
+
+[discrete]
+== *Core Concepts*:
+
+Correctness (Richtigkeit):: The model must accurately reflect the reality it represents — both syntactically (follows notation rules) and semantically (describes the real subject matter truthfully)
+
+Relevance (Relevanz):: A model should include only elements that are relevant to the intended purpose; unnecessary details reduce usability
+
+Economic Efficiency (Wirtschaftlichkeit):: The benefit gained from a model must justify the effort and cost of creating and maintaining it
+
+Clarity (Klarheit):: The model must be understandable to its intended audience; layout, notation, and level of detail must support comprehension
+
+Comparability (Vergleichbarkeit):: Models of the same subject should follow consistent conventions so they can be meaningfully compared
+
+Systematic Design (Systematischer Aufbau):: Models should be constructed using a consistent, structured approach to enable reuse and integration across a model landscape
+
+
+Key Proponents:: Jörg Becker, Michael Rosemann, Rolf Schütte ("Grundsätze ordnungsmäßiger Modellierung", WIRTSCHAFTSINFORMATIK, 1995)
+
+[discrete]
+== *When to Use*:
+
+* Evaluating or reviewing the quality of business process models (BPMN, EPC)
+* Establishing modeling standards within an organization or project
+* Enterprise architecture modeling to ensure consistent, reusable model artifacts
+* ERP implementation projects requiring traceable and auditable process documentation
+* Assessing whether a model is fit for its intended purpose
+* Onboarding teams to structured modeling practices
+
+[discrete]
+== *Related Anchors*:
+
+* <<arc42,arc42 Architecture Documentation>>
+* <<c4-diagrams,C4 Diagrams>>
+* <<morphological-box,Morphological Box>>
+====

docs/anchors/gom.de.adoc

@@ -0,0 +1,48 @@
+= GoM
+:categories: software-architecture
+:roles: software-architect, business-analyst, consultant, team-lead
+:related: arc42, c4-diagrams, morphological-box
+:proponents: Jörg Becker, Michael Rosemann, Rolf Schütte
+:tags: modeling, enterprise-architecture, business-process, bpm, principles, quality
+
+[%collapsible]
+====
+Vollständiger Name:: Grundsätze ordnungsmäßiger Modellierung
+
+Auch bekannt als:: GoM-Prinzipien, Grundsätze der Modellierungsqualität
+
+[discrete]
+== *Kernkonzepte*:
+
+Richtigkeit:: Das Modell muss die dargestellte Wirklichkeit korrekt abbilden — syntaktisch (Notationsregeln werden eingehalten) und semantisch (der Sachverhalt wird wahrheitsgemäß beschrieben)
+
+Relevanz:: Ein Modell soll nur Elemente enthalten, die für den beabsichtigten Zweck relevant sind; unnötige Details verringern die Nutzbarkeit
+
+Wirtschaftlichkeit:: Der Nutzen eines Modells muss den Aufwand und die Kosten für seine Erstellung und Pflege rechtfertigen
+
+Klarheit:: Das Modell muss für die Zielgruppe verständlich sein; Layout, Notation und Detaillierungsgrad müssen das Verständnis unterstützen
+
+Vergleichbarkeit:: Modelle desselben Gegenstandsbereichs sollen einheitlichen Konventionen folgen, damit sie sinnvoll verglichen werden können
+
+Systematischer Aufbau:: Modelle sollen nach einem konsistenten, strukturierten Vorgehen erstellt werden, um Wiederverwendung und Integration im Modellgefüge zu ermöglichen
+
+
+Schlüsselvertreter:: Jörg Becker, Michael Rosemann, Rolf Schütte ("Grundsätze ordnungsmäßiger Modellierung", WIRTSCHAFTSINFORMATIK, 1995)
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Bewertung oder Review der Qualität von Geschäftsprozessmodellen (BPMN, EPK)
+* Einführung von Modellierungsstandards in einer Organisation oder einem Projekt
+* Enterprise-Architecture-Modellierung zur Sicherstellung konsistenter, wiederverwendbarer Modellartefakte
+* ERP-Implementierungsprojekte, die nachvollziehbare und prüffähige Prozessdokumentation erfordern
+* Prüfung, ob ein Modell dem beabsichtigten Zweck gerecht wird
+* Einarbeitung von Teams in strukturierte Modellierungspraktiken
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<arc42,arc42 Architekturdokumentation>>
+* <<c4-diagrams,C4-Diagramme>>
+* <<morphological-box,Morphologischer Kasten>>
+====

docs/metadata/roles.yml

@@ -82,6 +82,14 @@ madr:
     - team-lead
   rationale: "Structured ADR format; architects/developers document decisions, team leads approve"
 
+gom:
+  roles:
+    - software-architect
+    - business-analyst
+    - consultant
+    - team-lead
+  rationale: "Modeling quality principles; architects define modeling standards, BAs create process models, consultants audit quality, team leads enforce conventions"
+
 c4-diagrams:
   roles:
     - software-architect

website/public/data/anchors.json

@@ -368,6 +368,38 @@
     ],
     "filePath": "docs/anchors/fowler-patterns.adoc"
   },
+  {
+    "id": "gom",
+    "title": "GoM",
+    "categories": [
+      "software-architecture"
+    ],
+    "roles": [
+      "software-architect",
+      "business-analyst",
+      "consultant",
+      "team-lead"
+    ],
+    "related": [
+      "arc42",
+      "c4-diagrams",
+      "morphological-box"
+    ],
+    "proponents": [
+      "Jörg Becker",
+      "Michael Rosemann",
+      "Rolf Schütte"
+    ],
+    "tags": [
+      "modeling",
+      "enterprise-architecture",
+      "business-process",
+      "bpm",
+      "principles",
+      "quality"
+    ],
+    "filePath": "docs/anchors/gom.adoc"
+  },
   {
     "id": "hexagonal-architecture",
     "title": "Hexagonal Architecture (Ports & Adapters)",

website/public/data/categories.json

@@ -87,6 +87,7 @@
       "c4-diagrams",
       "clean-architecture",
       "domain-driven-design",
+      "gom",
       "hexagonal-architecture",
       "madr"
     ]

website/public/data/metadata.json

@@ -1,15 +1,15 @@
 {
-  "generatedAt": "2026-02-26T19:17:52.667Z",
+  "generatedAt": "2026-03-01T22:48:19.586Z",
   "version": "1.0.0",
   "counts": {
-    "anchors": 52,
+    "anchors": 53,
     "categories": 12,
     "roles": 12
   },
   "statistics": {
-    "averageRolesPerAnchor": "3.27",
+    "averageRolesPerAnchor": "3.28",
     "averageCategoriesPerAnchor": "1.00",
-    "anchorsWithTags": 7,
-    "anchorsWithRelated": 6
+    "anchorsWithTags": 8,
+    "anchorsWithRelated": 7
   }
 }

website/public/data/roles.json

@@ -8,6 +8,7 @@
       "chatham-house-rule",
       "domain-driven-design",
       "ears-requirements",
+      "gom",
       "impact-mapping",
       "jobs-to-be-done",
       "mece",
@@ -29,6 +30,7 @@
       "cynefin-framework",
       "devils-advocate",
       "feynman-technique",
+      "gom",
       "iec-61508-sil-levels",
       "impact-mapping",
       "mece",
@@ -136,6 +138,7 @@
       "domain-driven-design",
       "dry-principle",
       "fowler-patterns",
+      "gom",
       "hexagonal-architecture",
       "iec-61508-sil-levels",
       "madr",
@@ -202,6 +205,7 @@
       "feynman-technique",
       "five-whys",
       "fowler-patterns",
+      "gom",
       "impact-mapping",
       "madr",
       "mental-model-according-to-naur",