Considering its significance, Situation is defined rather ambiguously in Table 5.1: “A situation describes a set of situation occurrences of some type. The system, place, time and state parameters are described by classifiers rather than individual descriptions. A situation occurrence is a system being in a given place at given time and in a given state.” Section 9.1 adds that “The system, place, time and state parameters are described by classifiers rather than individual descriptions.” This prompts a number of questions, which are unanswered by the specification:

• Why is there no formal definition of ‘situation occurrence’ in the Core Profile? (it is only informally defined as part of the definition of ‘situation’) The lack of a formal definition seems to be something of an oversight, given their central importance, especially considering that the stated aim of RAAML to “avoid inconsistent model-based solutions [that] prohibit direct model sharing between organizations and across the various tools”.
o My recommendation would be to add this to the Core Concepts e.g. “Figure 9.1 – Core concepts domain model”, a definition in Section 9.1.x and an entry in the 5.1 definitions table.

• In the absence of the above definition of ‘situation occurrence’, the RAAML user is left to guess how ‘situation occurrences’ should be represented in the model?
o One might initially assume that a ‘situation occurrence’ is intended to be an instances of ‘situation’, but this assumption would appear to contradict the definition of ‘situation’, which states it is a set of ‘situation occurrences’. In other words, every instance of ‘situation’ must be associated with a set corresponding instances of ‘situation occurrence’
o What ‘types’ of ‘situation occurrence’ exist (definition of ‘situation’ states “…situation occurrences of some type”)
o What is the nature of the set of ‘situation occurrences’ that are described by a ‘situation’?
 Should this be represented in UML with shared or composite aggregation from whatever represents ‘situation occurrence’ to ‘situation’ – maybe not, because ‘situation’ only “describes a set”, so perhaps this should be a plain association labelled ‘describes’?
 If the relationship is aggregation, should/could a ‘situation’ comprise anything else alongside the set (such as a description of the relationships between the members of the set)?
o Regardless of whether ‘situation’ aggregates ‘situation occurrences’ or merely describes them, what range of multiplicities is valid (e.g. can a ‘situation’ be an empty set, have only a single constituent ‘situation occurrence’, or must it be comprise two or more)?

• RAAML deliberately relies on UML classifiers to represent “system, place, time and state”.
o State is a UML type and RAAML shows e.g. «FailureState» extending the «State» metaclass, but which classifiers are intended to be used for ‘system’, ‘time’, and ‘place’?
o I am also left wondering why RAAML relies on classifiers for this purpose, rather than making them explicit in the Core Concepts – no rationale for this decision is provided. This seems almost certain to result in various interpretations in different organizations' tools, thus violating the stated aim "avoid inconsistent model-based solutions"

o Table 9.1 lists «ControllingAction» as “A stereotyped UML dependency” and states in the preceding text that “Situations can be mitigated, detected, and prevented via the ControllingAction. The use of this relationship introduces new safety requirements.” This term does not appear anywhere else.
o The Core Profile does, however, describe «ControllingMeasure» as “A measure taken to address (mitigate severity, reduce probability of occurrence, increase probability of detection) a potential or real adverse situation.” which is similar, but not identical to «ControllingAction»