ArchiTrek help
ArchiMate's tables tell you which element types may connect. They don't show the chain that gets you from one to another. ArchiTrek finds that chain, often across the Business, Application and Technology layers.
- Pick two or more element types.
- Click Find Path.
- Read the diagram and the hop-by-hop explanation. Click any item to learn more.
- Turn on + Inferred under Search Depth.
- Pick a looser Semantic rigor, such as Discovery. Or allow Association fallback in Advanced options, under Advanced Logic Overrides.
- Add an element type that sits between the layers.
What the settings do
- Ordered
- The route follows your points in order, from Start through Via to End.
- Connect set
- Order doesn't matter. ArchiTrek reorders the points to find the strongest chain that connects them all.
- Explicit
- Only the uppercase relationships in Appendix B. This is the strictest graph.
- + Inferred
- Adds the Appendix B derivations. Certain ones (B.2) cost less than potential ones (B.3).
- Semantic rigor
- Academic, Pragmatic or Discovery. It sets the grammar checks and whether Association (§5.2.4) may bridge a gap. Search Depth decides which relationships exist. Rigor judges the routes built from them.
- Story theme
- Changes labels and wording, for example Abstract, Hospital or Death Star. The search rules stay the same.
Cheapest legal chain first
Each hop has a cost. ArchiTrek adds them up and lists the lowest total first. Ties go to fewer hops, then to fewer inferred hops.
Change the costs in Advanced options.
ArchiTrek checks every hop against the Appendix B relationship table, shipped as an offline snapshot. The Open Group owns the language and its normative relationship chapter. Found a mismatch with the published tables? Report it through Feedback, with the from and to element types and the table cell you expect.
How Appendix B is used
The engine treats the embedded ArchiMate 3.2 relationship matrix as the contract for “may this
relationship kind exist on this directed element-type pair?” That contract is built offline from the vendored
machine-readable table under data/source/ (see How the table was captured below) and shipped as
data/matrix.js — letter codes per cell for offline lookup, not re-derived at runtime from prose in the PDF.
Association follows the usual “always permitted” rule (section 5.2.4): it is not part of the per-cell
letter set in the matrix file; the UI layers it in as a deliberately weak escape hatch with a tunable cost so
specific links stay preferable when you want discipline.
Canonical language definition and diagrams remain with The Open Group; what you get here is an implementation snapshot aligned to that family. https://pubs.opengroup.org/architecture/archimate32-doc/ch-relationships-Normative.html
Known limits
The frozen matrix answers which relationship symbols appear for a type pair; it does not
by itself certify each symbol as “printed verbatim as uppercase in the table” versus “only appears after
section 5.7–style chaining.” The product still exposes two buckets so Explicit vs + Inferred
affects graph shape and scoring: direct vs derived letters are split according to the data in
data/matrix.js plus a few graph rules (for example canonical direction choices on mutual pairs).
Bottom line: legality tracks the embedded Appendix B snapshot; the primary/secondary split is
engineering judgement where the spec tables leave ambiguity.
Viewpoint palettes, aspect/metamodel blurbs, and narrative copy are curated for teaching — they should stay consistent with the matrix, but they are not emitted from the same mechanical source as the pairwise rules.
How the table was captured
The MATRIX records in data/matrix.js are produced by scripts/build-matrix.mjs.
The allowed codes for each pair come from the Appendix B table in data/source/relationships.xml
(AlbertoDMendoza/archimate_ontology). Whether a code is direct or derived comes from
upstream’s case-significant copy of the same table (data/source/relationships-cased.xml: UPPERCASE = drawn
in the chapter 3–12 metamodel figures, lowercase = derived). A derived code is valid when
upstream’s DR1–DR8 rules (Appendix B.2) produce it from the direct relationships, and
potential when it only appears once PDR1–PDR12 (Appendix B.3) also run. The upstream commit
and the date are in the header of data/matrix.js.
If you find a mismatch against the published tables, that is a bug worth reporting — include the from/to element types and the table cell you expect.
Credits
ArchiTrek builds on published ArchiMate material and related community work. The normative language is owned by The Open Group; community projects publish parallel machine-readable encodings that many tools use for validation or RDF pipelines.
- The Open Group — ArchiMate specification: relationship validity and derivation rules follow the public specification and its normative relationship tables (Appendix B in the same document family as https://pubs.opengroup.org/architecture/archimate32-doc/). Direct link to the normative relationships chapter: https://pubs.opengroup.org/architecture/archimate32-doc/ch-relationships-Normative.html.
- The Open Group — ArchiMate Model Exchange Format: optional path export to XML uses the published exchange namespace and XSD (see https://www.opengroup.org/xsd/archimate/3.0/).
-
Community ontology and validation dataset:
https://github.com/AlbertoDMendoza/archimate_ontology
(AlbertoDMendoza/archimate_ontology) ships a machine-readable type-level relationship encoding, including
https://github.com/AlbertoDMendoza/archimate_ontology/blob/main/validation/relationships.xml,
and a Turtle ontology at
https://github.com/AlbertoDMendoza/archimate_ontology/blob/main/ontology/archimate.ttl.
ArchiTrek’s pathfinding matrix is generated from snapshots of the project’s Appendix B tables
(derivation/relationships.xml,
where letter case marks direct versus derived) under
data/source/, and its valid-versus-potential split comes from running the project’s SPARQL derivation rules (DR1–DR8, PDR1–PDR12). Encoding and rules © Alberto D. Mendoza, Apache-2.0; the underlying tables are from Appendix B of the ArchiMate® 3.2 Specification, © The Open Group.
Understanding Search Depth: Explicit vs. Inferred
This setting determines which "tier" of the ArchiMate relationship matrix the engine uses.
Explicit mode: The engine only considers Explicit relationships (shown as Uppercase letters in the Appendix B tables). These are the primary, first-degree connections defined as the core building blocks of the language.
+ Inferred mode: The engine is allowed to use inferred relationships from Appendix B derivation rules. It distinguishes certain derivations (B.2) and potential derivations (B.3), with potential hops penalized more strongly.
💡 Why this is different from Semantic Rigor
Think of this as the Source Material. It decides whether we use only Explicit entries or also inferred entries from Appendix B. Rigor is the Filter—it decides which of those results are architecturally "Strong" based on grammar.
ArchiMate Semantic Rigor Guide
Understanding Semantic Rigor Modes
This engine evaluates architectural paths based on strict ArchiMate 3.2 derivation rules (§5.7). The Rigor Mode determines how strictly the "Grammar" of the language is enforced.
| Rigor Mode | Core-to-Core Filter | V-Shape Filter | Association Bridges | Purpose |
|---|---|---|---|---|
| 🎓 Academic | Strictly Blocked | Strictly Blocked | Disabled | Formal proofs and exam-level modeling accuracy. |
| 🛠️ Pragmatic | Strictly Blocked | Allowed (Flagged) | Enabled (High Penalty) | Real-world analysis where data may be fuzzy. |
| 🕵️ Discovery | Allowed (Flagged) | Allowed (Flagged) | Enabled (Low Penalty) | "What-if" exploration to find hidden impacts. |
Logic Gate Definitions
- Core-to-Core Filter: Prevents linking two Technology-layer elements by taking a shortcut through the Motivation layer (e.g., bridging two Servers because they share a "Goal").
- V-Shape Filter: Prevents "up-then-down" dependency loops (e.g., App A serves Process B, and App C serves Process B). Mathematically they share a process; architecturally they aren't necessarily connected.
- Association Bridges: Uses the universal §5.2.4 Association to bridge gaps when no formal logical chain exists.
Note: These settings determine the Semantic Strength Badge (Strong, Valid, or Informal) you see in the results.
💡 Why this is different from Search Depth (Explicit vs. Inferred)
Semantic rigor is the Filter—which routes count as architecturally "Strong" based on grammar and Association rules. Search Depth (the Explicit / + Inferred toggle) selects the Source Material: only explicit Appendix B entries, or explicit plus inferred Appendix B derivations (B.2/B.3).
You can have a short Explicit hop that is still flagged Informal if it breaks a grammar rule, or a longer Inferred chain that is Strong because it follows the rules.
Feedback
Welcome to ArchiTrek
ArchiTrek is an unofficial study tool for ArchiMate 3.2: choose two or more element types, and it searches the standard Appendix B relationship tables for valid routes. You get a diagram, hop-by-hop explanation, and links to dig into elements and the metamodel.
Watch the tour
80 seconds, with captions.
Try an example
Jump straight to a path, or skip and pick your own elements below.
By continuing, you agree this browser may store your settings and last session (path choices, layout) locally on your device so the app can restore them when you return. Nothing is sent to a server unless you use Feedback. You can clear site data anytime.
Welcome
You can turn on relationship names together with hop numbers and/or flip controls.