When is SysML correct and when is it not?
Grab some popcorn, sit back and enjoy the battle of the tool manufacturers! But seriously, I was surprised to see a „friendly competition“ on LinkedIn between Dassault (Cameo) and Sensmetry (Syside). The exchange of blows was about the correctness of the „cheat sheets“ for SysML v2 from both manufacturers.
The more serious and important question is: What is correct SysML v2, and when is what kind of correctness important?
What is it about?
As SysML v2 is a hot topic at the moment, there is also a great need for help on how to use it. Cheat sheets are a popular tool, i.e. cheat sheets consisting of a few pages that summarize important aspects in a concise and user-friendly way. I recently published a list of all the cheat sheets I know of SysML v2 Cheat Sheets.
The cheat sheet from Dassault was missing from the list, as it was not yet ready at the time. Dassault made up for this on October 18, 2025. In the comments, Juozas Vaicenavičius, CEO of Sensmetry, spoke up to point out his own cheat sheet, which is perfectly legitimate. Andrius Armonas„ response was, frankly, “rage bait": insinuating mistakes without any concrete justification:
Juozas Vaicenavicius I'm not sure who created it, but it contains a number of errors and, from a methodological standpoint, could mislead users. I wish the creator had some knowledge of SysML v2.
Andrius Armonas, CATIA Systems R&D Application Director, Product Manager at Dassault Systèmes
It is understandable that Juozas did not want to let this go. True to the motto: „Attack is the best defense“, Juozas once again launched a bug-hunting challenge with a reward:
Let's help Dassault Systemes fix SysMLv2 textual notation mistakes in their recently released official cheat sheet!
Juozas Vaicenavicius, CEO & Co-Founder @ Sensmetry, PhD
At this point, I don't want to comment on which cheat sheet is right or wrong, or which contains the most errors. We must not forget that LinkedIn is social media: accordingly, we should not take the exchange of blows too seriously. What makes me happy: „There is no bad publicity“, and this exchange helps to increase the visibility of SysML v2.
Udo Nink has summarized this idea beautifully:
Have fun in the tool battle and may it help to make all tools and examples better.
Udo Nink, Unlocking AI Use Cases in Product Development, informed by deep Architecture & Engineering experience.
What is right, what is wrong?
As I said, I don't want to dissect the cheat sheets in detail at this point. Instead, I would like to briefly reflect on what is actually relevant in this context. I see different levels here:
Syntactic correctness
The syntax describes how a model is formally structured, i.e. whether brackets, colons, ties and keywords are used correctly. Or whether corners in the diagram are round, or lines are solid or dashed. There is no room for interpretation here. The SysML v2 specification defines the syntax completely so that tools can check it based on rules.
Grammatical correctness
The grammar concerns how model elements may be related. It is more closely linked to the metamodel structure. For example, a „part usage“ may only occur within a block definition. This is also formally defined and can be checked automatically, for example when loading a model.
Semantic correctness
Semantics means that the model expresses what was intended. A model can be syntactically correct but semantically nonsensical. Example: A „value type“ with unit „ampere“ for a „length“. There is no syntax error here, but a violation of meaning. This level is difficult to check automatically because it requires specialist knowledge and context. This is where AI can score points.
Methodical correctness
This level concerns procedures, i.e. how SysML is applied as part of a development process. This is about best practices, architectural principles and model structuring. A model can be formally correct, but methodologically questionable, for example due to a lack of traceability or mixing of requirements and design. This falls more into the area of modeling guidelines or internal model standards.
Stylistic correctness
Similar to linters in software development, tools can be used to check models against defined style rules. This can range from text formatting and simple naming conventions to complex heuristics (e.g. warnings for unnamed ports, unused signals or blocks that are nested too deeply). These checks are not part of the specification, but increase quality and consistency.
Cheat sheet simplifications
Cheat sheets must be abstract. In order to maintain clarity, details are omitted or simplified. This is legitimate as long as it is clear that simplifications exist. Typical simplifications are the omission of imports or simplified examples without complete links. The important thing is that they help with learning, not that they show every syntactic detail.
Conclusion
Anyone talking about correctness should therefore specify at what level. Because what is a mistake for one person is a didactically useful simplification for another. And very importantly, anyone who accuses others of mistakes without justification is not discrediting the other person, but themselves. Constructive criticism requires justification, context and the will to improve. Everything else is just click bait on social media.
