There is no reason to have both LangString and ExpressionLangString, given the constraint on ExpressionLangString that the expression and the content cannot both have values. If you insist on having both, have a common base class that includes only the 'lang' attribute - then LangString can have the content field and ExpressionLangString can have the 'expression' field.

right now the Name of a model element can not be a multi-string... which it should be

There is no reason to have both LangString and ExpressionLangString, given the constraint on ExpressionLangString that the expression and the content cannot both have values. If you insist on having both, have a common base class that includes only the 'lang' attribute - then LangString can have the content field and ExpressionLangString can have the 'expression' field.

With ArtifactElement as the Base for the other Domains, it allowed anything to be connected to anything which was not the original intent.

Names used in the metamodel conflict with standard modeling usage.

Terminology package is not tied to everything else in the model.

Need to standardize concepts in SACM to be able to embed SACM in other languages and to be able to create a profile in UML based on the metamodel.

ArgumentationElement/ArgumentationElements/argumentationElement has the right naming pattern (i.e., consistent with the other Elements in the model) in 11.2 (ArgumentElements) but does not use that naming pattern in the rest of the model.

The metamodel should follow the open-closed principle to avoid double maintenance when changes are made because the current model requires changes in two places, additionally there is no need for the top-level interface package and but there is a need for a general binding package in the new packaging scheme, finally renaming interface and binging packages to align with normal package naming conventions.

Referencing external elements from the model are dealt with in inconsistent ways.

The Base Classes have names and scopes that are at odds with current standard modeling languages.

AssertionDeclaration has a number of orthogonal ideas that should not be in the enumeration (namely defeated and asCited), and the name should follow modeling practice of ending in”Kind” to indicate it is a set of enumerations.

Can not mix and match the domain elements within the group with the current per domain group approach.

Use of current gid is overly restrictive and not aligned with approaches used in UML and KerML.

Artifacts need to be able to be used in Arguments directly as well as ArtifactReference.

AssertedArtifactContext and AssertedArtifactSupport are redundant and their function can be implemented with the other things in the SACM language.

Association between ExpressionElement and Category, Claim and MetaClaim, and ArgumentReasoning and ArgumentPackage are shown but no longer needed and the association between ArgumentReasoning and AssertedRelationship is in the wrong direction and missing end-point details.

SACM 2.3 uses unique foundation elements instead of those from UML / Kermal modeling languages and need to fix issue of ArtifactAssetRelationship mislabeled as ArtifactAssertedRelationship in diagram versus specification text.

The name and the content of ExpressionElement, ArgumentReasoning, and Claim can be the same or the content can be different, but the SACM 2.3 doesn’t support this.

Currently SACM 2.3 allows too wide of nesting of different types of packages.

Asserted Relationships need precise targets and sources. The source and target of AssertedRelationships were either not defined or defined in OCL instead of being restricted in the Metamodel. Also, mislabeled (in text) the superclass for AssertedRelationships as Foundation::AssertedRelationship instead of Foundation::DirectedRelationship – is correct in diagram.

Date in Artifact section is not defined, nor are the mechanisms to reference to internal portions of external documents.

There is no construct to define what is in a SACM model or pattern.

metaClaim was removed from the text in a previous issue resolution but not from the diagram.

Format for IRI in Base is not defined

Document text and section numbers were not always changed as diagrams changed over the previous ballots and sometimes text was changed but not reflected in diagrams.

Arrow is on the wrong end of the association between NamedValue and ModelElement and generalization association from SACMModel to ModelElement is missing in the diagram but defined in the text.

Names are not distinguishable on directed relationships.

Property is no longer needed since any ModelElement can have a NamedValue.

Model should align with MOF to support use by SysML and UML audiences. Also ExpressionElement Attributes need to be aligned with the change adding MultiLangString as well as fixing the relationship between Category and TerminologyAsset. Finally, the arrow direction in the association between ArgumentReasoning and AssertedRelationship needs to be reversed and need to change the type for the attribute value of Argument Reasoning.

The new Foundation concepts of comments, constraints, named values, group, and dependencies were externalized and need to be re-integrated into the argument, terminology, and artifact package domains Additionally, the package structures in SACM 2.3 are too loose and need to be better aligned with intended use.

The modifications from the first two ballots and the previous issues in this ballot may have caused changes or complexities in the text that can be simplified.

SACM 2.3 only defined ownership for packages and not for other elements

SACM needs the ability to put in arbitrary dependencies between elements for explanation purposes

The text does not explain all of the OCL or what counter assertions mean.

NamedValue Ownerships can not be represented and are needed.

No consideration of an entire ArgumentPackage is allowed in GSN with a special notation, and SACM 2.3 has no equivalent and the ArtifactReference’s artifact association end has the wrong definition.

SACM needs a concept of a Join to allow multiple Assertions or Evidence to be Joined together as done in GSN Patterns and possible use for certain kinds of assurance cases.

Claims, arguments, terminology, and artifacts should all be able of being tagged as “needs development”.

SACM has no notion of Assessment

SACM does not support argument types other than inductive. Many engineering and other disciplines make use of other types of arguments including: Strengths (of all kinds); InferenceTypes from deductive as well as inductive logic (including notation changes); Inferences from other potential logic type (e.g. Modal); Possible Truth values for deductive arguments; and Undecidability for truth arguments. Supporting these other types of arguments would expand the utility of SACM.

SACM lacks support for the strength concepts and structured data for a model element as used in “Assurance 2.0: A Manifesto,” Robin Bloomfield & John Rushby, 2021.

SACM lacks support for date time duration bounds which is used in ISO/IEC 15026 – Assurance Cases.

SACM lacks any notion of views such as graphical Diagrams

Generally: This document is replete with grammatical errors. Has someone run a grammar checker on it?

Specifically:
In addition, the 'Attributes' section for 'ExpressionLangString' states:
"expression:Terminology::ExpressionElement[1] (composition) – a reference"

The field is either a reference or a composition - but not both. Pick one.

In GSN confidence goals can be directly connected to solutions by the supported by relationship but the analogous constructs in SACM, of claims cannot be connected to artifact references through assertedInference relationships. Nomenclature of inferrer and inferred can be confusing to many.

In general, the subject of a claim is not defined and therefore could be ambiguous. Specifically, confidence claims are about elements in the SACM Assurance Case itself and currently cannot be referenced.

Need to support “Context” notion from Patrick John Graydon’s paper, “Towards a Clearer Understanding of Context and Its Role in Assurance Argument Confidence”, 2014.

The transition from SACM 2.3 to SACM 2.4 for existing models needs to be explained for easier adoption and migration of existing implementations.

The graphical notation Annex needs to reflect the changes in SACM 2.4.

The example of SACM XMI needs to be recreated since the linked web site is gone

Annex A points to non-existent web pages about how SACM is mapped to GSN and CAE.

The conformance clause is Section 7 do not fully reflect the SACM 2.4 meta-model.

Need to use appropriate UML metaclasses for the profiles.

The annex with examples of the Argument Elements needs updating.

Annex E needs to reflect SACM 2.4 constructs.

Omissions, additions and errors discovered in the final cleanup of the SACM 2.4 document.

Specific SACMDiagrams need to be packaged under their appropriate domain packages, specifically under terminology, argument, and artifact domains.