In the Systems Library model Flows, the flow usage flows explicitly subsets messages. However, messages is also a flow usage, and it has owned end features. So, according to the constraint checkFlowUsageFlowSpecialization, messages is required to subset flows. This means messages and flows subset each other and are, therefore, semantically equivalent. As a result, all message flow usages with implied subsetting of messages end up having the same semantics as non-message flow usages with implied subsetting of flows.

In the Systems Library model Actions, the action definition AssignmentAction has two parameters, target and replacementValues, in that order. The action usage assignmentActions, which is defined by AssignmentAction, redefines the target parameter, but inherits replacementValues.

The action usage Action::assignments is also defined by AssignmentAction and it subsets assignmentActions. This means that it has two parameters from AssignmentAction and two parameters from assignmentActions as potentially inheritable members. However, assignmentActions::target redefines AssignmentAction::target so the latter is not inherited. And assignmentActions::replacementValues is the same as AssignmentAction::replacementValues, so the former is not inherited again.

The result of this is that the inherited parameters of Action::assignments are AssignmentAction::replacementValues and assignmentActions::target in that order. That is, the parameters of assignments have effectively switched their order relative to how they are defined in AssignmentActions. This is a problem, because an AssignmentActionUsage has an implied specialization of assignments, and it is parsed assuming the parameters inherited from assignments are in the same order as in AssignmentAction.

Documentation of Clock in standard library Time.sysml and subclause 9.8.8.2.1 has typo "montonically", should be "monotonically".

The following calc defs are missing nonunique in the declaration of the num input parameter:

• calc def '[' in VectorQuantityCalculations.sysml and clause 9.8.10.1
• calc def '[' in TensorQuantityCalculations.sysml and clause 9.8.11.1

Both the specification and the standard libraries must be updated.

A binary ConnectionDefinition must directly or indirectly specialize the ConnectionDefinition
Connections::BinaryConnection from the Systems Model Library.
ownedEndFeature->size() = 2 implies
specializesFromLibrary('Connections::BinaryConnections')

should be

specializesFromLibrary('Connections::BinaryConnection')

In 8.3.20.2 AssertConstraintUsage, in the OCL for the constraint validateAssertConstraintUsageReference, the invocation referencedFeaure() should be referencedFeature().

In 8.3.17.15 SendActionUsage, in the OCL for the constraint checkSendActionUsageSubactionSpecialization, the reference to Actions::Action::acceptSubactions should be Actions::Action::sendSubactions.

In the section for /stakeholderParameter within 8.3.21.8 RequirementsDefinition:

"The parameters of this RequirementDefinition that represent stakeholders for th requirement"

"the" missing the "e" at the end of the sentence.

On page 630 and 634 in the table under the section for ScalarQuantityValue Operations on the 3rd row, 1st column, the text is:

fs1+fs2

for the Description:

Addition of a bound and a free scalar quantity returns a bound scalar quantity.

Text should be:

bs1+fs2

In 8.3.17.5 AssignmentActionUsage, under "Constraints":

1. In the OCL for constraints checkAssignmentActionUsageAccessedFeatureRedefinition, checkAssignmentActionUsageReferentRedefinition and checkAssignmentActionUsageStartingAtRedefinition, the terms targetParameter->first() should be targetParameter.ownedFeature->first().
2. In the OCL for constraints checkAssignmentActionUsageAccessedFeatureRedefinition and checkAssignmentActionUsageStartingAtRedefinition, references to redefines should be redefinesFromLibrary.

The doc descriptions of MergeAction, DecisionAction, JoinAction and ForkAction use "succession connector". This should be replaced with "succession connection" (4 times).

At the top of the table on page 132 is a line from a requirement to a require constraint with an aggregation indicator at the requirement end. This also appears at the bottom of the table on page 131.
At the bottom of the table on page 132 is a line from a part to a requirement with an arrowhead at the requirement end.
Only the 2nd line is defined within the Graphical Notation section.
Do these both, as it appears, represent the same underlying element? If so how is the tool creator to decide which presentation to use?

This is done with cross subsetting, which is a special kind of subsetting relationship specified using the keyword crossing or the symbol =>.

replace the word crossing with crosses

subject vehicle : Vehicle {
...
then event occurrence startsDrive [1];
then event occurrence endsDrive [1];

should be

subject vehicle : Vehicle {
...
then event occurrence drives [1];

to make

then message of Drive from vehicle.drives to environment.vehicleDrives;

correct

In 8.2.2.21.1 Requirement Definitions, the production FramedConcernUsage references CalculationUsageDeclaration. However, there is no CalculationUsageDeclaration defined in the grammar.

In KerML clause 8.2.5.8.2 Primary Expressions, operator '[' is declared as an abstract function in BaseFunctions.kerml, as an Undefined placeholder. As such the operator does not have a precedence position in Table 6 Operator Precedence (in 8.2.5.8.1 Operator Expressions).

In SysML the operator '[' is redefined as a concrete calc def to construct quantity and measurement reference value tuples (defined by ScalarQuantityValue, VectorQuantityValue or TensorQuantityValue).

When used in quantity expressions that contain also other (arithmetic) operators it is currently undefined what the evaluation order is.

Examples:

• What is the interpretation of 24 + 5 [kg] ? Is it (24 + 5) [kg] or 24 + (5 [kg])? The latter interpretation would raise a quantity arithmetic error since it is not valid to add a scalar number (implicitly of dimension one) and a scalar quantity value with a different quantity dimension.
• What is the interpretation of 6 * 8.5 [kg] ? Is it (6 * 8.5) [kg] or 6 * (8.5 [kg])? Here, both are valid and yield the same result, but it can get more complicated.
• What is the interpretation of 6 [kg] / 22 [L] ? Is it (6 [kg] / 22) [L] or (6 [kg]) / (22 [L])? Intuitively the latter, although one could argue both yield the same result: (6 / 22) [kg/L].
• What is the interpretation of 13 [m/s]^2 ? Is it (13 [m/s])^2 or 13 ([m/s]^2)? Subexpression ([m/s]^2) would not be valid.

The precedence of the '[' operator should be defined relative to the other binary operators.

The following calc defs should include redefinitions of their parameters wrt the x and y parameters in general function BaseFunctions::'[' :

• calc def '[' in QuantityCalculations.sysml and clause 9.8.9.1
• calc def '[' in VectorQuantityCalculations.sysml and clause 9.8.10.1
• calc def '[' in TensorQuantityCalculations.sysml and clause 9.8.11.1

The Vector and Tensor calc defs also must include nonunique in the redefined declarations of the input parameters.

Within this definition:

FilterPackage : Package =
     ownedRelationship += FilterPackageImport

FilterPackageImport is not defined within the metamodel. According to Ed Seidewitz, this is a mistake in the specification and FilterPackageImport should have been ImportDeclaration.

In 8.4.1 Semantics Overview, the tables contain the following errors.

1. Table 31. Implied Definition Subclassification Relationships
   • For checkMetadataDefinitionSpecialization, Views::MetadataItem should be Metadata::MetadataItem.
2. Table 32. Implied Usage Subsetting Relationships
   • For checkAttributeUsageSpecialization, Attributes::attributes should be Attributes::attributeValues.
   • checkEventOccurrenceSpecializaton should be checkEventOccurrenceUsageSpecialization.
   • For checkTransitionUsageSpecialization, Actions::transitions should be Actions::transitionActions.
3. Table 33. Other Implied Relationships
   • checkRequirementUsageObjectiveSpecialization should be checkRequirementUsageObjectiveRedefinition.

includes the the keyword

an occurrence isage

should be

usage is

PrefixMetadataMember : OwningMembership =
    '#' ownedRelatedEleemnt = PrefixMetadataUsage

Element is not spelled correctly

PackageMember : OwningMembership
    MemberPrefix
    ( ownedRelatedElement += DefinitionElement
    | ownedRelatedElement = UsageElement )

there is no equal sign here

The resolution of SYSML2_-159, approved in SysML v2 FTF2 Ballot #5, included the following abstract syntax changes that were not actually made in the specification:

1. In 8.3.17.1 Overview (of Actions Abstract Syntax), in Figure 26
   Send and Accept Actions, change the multiplicity of the association end SendActionUsage::payloadArgument from [1] to [0..1].
2. In 8.3.17.2 AcceptActionUsage, under "Constraints", replace the description and OCL for the constraint validateAcceptActionUsageParameters:

   An AcceptUsageAction must have at least one input parameter, corresponding to its payload (even if it has no FeatureValue). (Note that the payloadParameter is an input as well as an output.)

   inputParameters()->notEmpty()
   

3. In 8.3.17.15 SendActionUsage:

• Under "Attributes", after "/payloadArgument : Expression" add "[0..1]".
• Under "Constraints", replace the constraint validateSendActionParameters with:

  validateSendActionUsagePayloadArgument

  If a SendActionUsage is owned via a StateSubactionMembership or a TransitionFeatureMembership, then it must have a payloadArgument.

  owningFeatureMembership <> null and
  (owningFeatureMembership.oclIsKindOf(StateSubactionMembership) or
   owningFeatureMembership.oclIsKindOf(TransitionFeatureMembership)) implies
      payloadArgument <> null
  

Grammar elements stakeholder-node, subject-actors-stakeholder-node and distinguished-parameter are not defined. I also searched in the KerML specification.

SpatialItem in standard library SpatialItems.sysml is defined by ThreeDCoordinateFrame[1]. However, this is too wide as it may not be any ThreeDCoordinateFrame but should be narrowed to ISQSpaceAndTime::Spatial3dCoordinateFrame[1] since it must be a spatial coordinate frame that is a measurement reference for 3D position or displacement vectors.

Furthermore, in subclause 9.7.2.2.5, SpatialItem::coordinateFrame is defined by the even wider VectorMeasurementReference and misses the default value. This should be corrected in line with the above, i.e., ISQSpaceAndTime::Spatial3dCoordinateFrame[1] , and adding the default value.

The current SysML metamodel defines use cases as specializations of behavioral elements—effectively treating them as calculations or executable functions. This characterization is semantically inconsistent with the foundational role of use cases in systems modeling. Use cases are not behaviors the system performs internally; rather, they represent contracts or agreements between external actors and the system, specifying what the system is expected to do in response to a stimulus. Modeling use cases as executable behaviors introduces a category error into the metamodel and risks conflating external interactions with internal mechanisms.

Use cases, by their very nature, are interaction scenarios. They do not define how a result is computed or executed, but instead describe what result is expected when a particular actor engages the system in a defined way. Their semantics are declarative and externally visible; they are about outcomes, not procedures. As such, the current inheritance from computational behavior types (such as Function or Behavior) is conceptually incorrect. This structural alignment misleads modelers and tool developers into treating use cases as execution artifacts, which they are not.

If the metamodel insists that use cases must derive from a parent behavioral concept, a more accurate—though still imperfect—choice would be to inherit from a construct akin to a state transition. This would at least preserve the idea that use cases mark a change in the system’s externally observable state as a result of actor interaction. Even so, this remains a second-best solution, as it still imposes a behavioral framing on what should be a scenario-based modeling construct.

The preferred and semantically coherent approach is to model use cases as a distinct first-class metamodel element, such as a Scenario. This new metaclass should stand apart from behavioral execution elements and focus solely on external intent, interaction structure, and resulting system obligations. Two clear examples of such Scenario constructs would be Use Cases and Acceptance Test Scripts. Doing so would reinforce the modeling clarity that use cases are not descriptions of how the system behaves internally, but agreements about what the system must do when engaged from the outside.

Separating use cases from procedural behavior elements also promotes stronger model validation and traceability. It enables more accurate conformance checking between actor expectations and system behavior without enforcing implementation-specific logic. This adjustment to the metamodel aligns better with the practical and pedagogical use of use cases in systems engineering and eliminates the conceptual mismatch that currently exists.

In summary, the treatment of use cases as calculations within the SysML metamodel introduces a fundamental misalignment between semantics and structure. Reframing use cases as scenario-based constructs—independent from executable behaviors—restores conceptual clarity and reinforces the integrity of the modeling language. This change would provide immediate benefit to the precision, usability, and future extensibility of SysML.

it says "Further, the keyword else may be used in place of a guard expression" but it needs to add
that may be used in palce of a guard and following then

because the else replaces the then... and nowhere in the spec does it say you can remove the then.... yet that is in the examples

checkCalculationUsageSubcalculationSpecialization has no definition

Performed By
Compartment is empty

No Abstracts shown in Metamodel... I am assuming one cannot create an Element... yet it is not shown as italicized in the
metamodel... that would be helpful if you had that in the metamodels

Spelling mistakes in PartUsage attribute stakholderOwiningRequirementDefinition - contains stakholder and Owining.

What is the meaning of el-prefix = '^' | '/'?
What determines whether either ^ or / should be present?

Standard library ISQMechanics.sysml contains a declaration of torque as a scalar quantity to represent torque magnitude, but the related torque vector quantity is missing.

A torque vector quantity and associated coordinate frame should be added using the same pattern as for other vector quantities.

Note: This issue was flagged in "SysML v2 Release" Google Group at https://groups.google.com/g/sysml-v2-release/c/w7ZbFZ9d-e0/m/yTF8oyb6AwAJ .

Tables 25 and 34 in clauses 7.26.5 and 9.2.20.1 respectively have inconsistent descriptions of standard views. Table 34 is the authoritative source for the standard view definitions. The first column of Table 25 will need to be updated to be consistent with Table 34.

SysML2 should support both graphical and textual syntax for guards on flows. The graphical and textual syntax should be like the syntax for successions. Ideally, the abstract syntax created by parsing the graphical and textual syntax for guards on flows should be more direct than the approach suggested for translating SysML1 object flows into SysML2 (proposed in Section 7.7.3.3.50 of the SysML v1 to SysML v2 Transformation specification).

In subclause 8.2.3.8 three corrections on graphical BNF productions are needed:

• In production enumeration-def-name-compartment, DefinitionPrefix is too wide and should most likely be replaced with DefinitionExtensionKeyword*.
• In production enumeration-name-compartment, UsagePrefix is too wide and should most likely be replaced with UsageExtensionKeyword*.
• In production enums-compartment-element, el-prefix? UsagePrefix is too wide and should most likely be removed.

In Table 15 of the Representative Notation Tables, the row labeled Accept and Send Action Flow includes a model fragment that uses a combination of a succession and a binding connection to connect to the input payload parameter of a send action and from the output payload parameter of an accept action. This issue recommends adding another example of a common pattern that replaces the succession and the binding connection with a succession flow.

The current specification presents two issues with compartment definitions:
• The same elements may appear in multiple compartments, even when a more specific compartment is defined (e.g., action and perform action).
• Because keywords are hidden, compartment element keywords cannot be clearly distinguished (for example, perform action looks the same as action).

To address these issues, the following adjustments are proposed. Specific compartments should explicitly exclude overlapping contents:

actions-compartment-contents (page 227)
• exclude perform-actions-compartment-contents (page 227)
use-cases-compartment-contents (page 255)
• exclude include-use-cases-compartment-contents (page 255)
states-compartment-contents (page 238)
• exclude exhibit-states-compartment-contents (page 239)
constraints-compartment-contents (page 243)
• exclude require-constraints-compartment-contents (page 246)
• exclude assume-constraints-compartment-contents (page 246)
• exclude assert-constraints-compartment-contents (page 244)
requirements-compartment-contents (page 246)
• exclude satisfy-requirements-compartment-contents (page 247)
• exclude verifies-compartment-contents (page 253)

Currently, the usage appearance in the ‘parameters’ compartment is defined in the “8.2.3.17 Actions Graphical Notation” chapter as follows:

parameters-compartment-element = el-prefix? FeatureDirection UsageDeclaration ValueOrFlowPart? DefinitionBodyItem*

This is not consistent with other compartments that represent elements which can declare a direction (it includes only the ‘direction’ modifier but omits others), such as items, parts, and attributes:

items-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
attributes-compartment-element = el-prefix? UsagePrefix usage-cp

Currently, the usage appearance in end compartment are declared in “8.2.3.14 Interfaces Graphical Notation” chapter like that:

ends-compartment-element = QualifiedName (’:’ QualifiedName)?

It is not consistent with all other compartments, e.g. parts, ports:

parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
ports-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp

PrefixMetadataMember : OwningMembership =
'#' ownedRelatedEleemnt = PrefixMetadataUsage

Element is not spelled correctly

There are errors in the example model that need to be corrected to align with the latest release.
This includes the following errors on pg 662.
From: variation part transmission:TransmissionChoices;
To: part transmission:TransmissionChoices;

From: variation part sunroof:Sunroof;
To: variation part sunroof:Sunroof [0..1];

It is also recommended to add the subset of the part vehicleFamily to model a specific vehicle configuration.

In 8.3.21.7 RequirementConstraintMembership, the constraint validateRequirementConstraintMembershipIsComposite requires that the ownedConstraint of a RequirementConstraintMembership be composite. However, consider the following:

part p {
    constraint c;
}
requirement r {
    subject :> p;
    require p.c;
}

In this case, the constraint c is composite in p, but the required constraint referencing p.c is composite in r. Further, checkConstraintUsageCheckedConstraintSpecialization requires that c subset Part::checkedConstraints, which indirectly specializes Object::ownedPerformances, and, therefore, so does the required constraint referencing p.c. But checkConstraintUsageRequirementConstraintSpecialization requires the required constraint to specialize RequirementCheck::constraints, which (as a composite constraint usage) indirectly specializes Performance::subperformances. Thus, the required constraint inherits from both ownedPerformances and subperformances, which is inconsistent (in particular, this is bound differently in the two features).