If all elements in Argumentation, Terminology, Artifact and AssuranceCase can be considered as artifacts the assertion that one or more artifact provide context for another artifact; and the assertion that one or more artifact support another artifact needs to be captured.

deferred

Use “artifact” instead of “artefact” is needed to make incorporation of SACM into The Open Group standards more practical.

deferred

ArtifactAssetRelationship can be simplified by removing all its sub-classes. The purpose of an ArtifactAssetRelationship can then be recorded by the property +property:Property in the ArtifactAsset class.

deferred

In SACM, all elements in the Argumentation package, Artifact package, Terminology package, and AssuranceCase package are considered to be Artifacts.

Consequently ArtifactElement needs to be moved to the Base classes and be a direct sub-type of ModelElement. All elements in other packages then will sub-type ArtifactElement.

deferred

In Argumentation package, AssertedRelationship should directly express if it is a counter relationship.

deferred

There is currently no direct mechanism to support internationalization in SACM content.

deferred

In packages (e.g. ArgumentPackage, TerminologyPackage), atomic references are too complicated.

deferred

Citations can be simplified by removing them from Argumentataion, Artifact and Terminology classes and replacing them with +isCitation and +citedElement properties in SACMElement in the Base classes.

deferred

The ability to create patterns (e.g. AssuranceCase patterns, ArgumentPackage patterns, etc) that contain only abstract SACMElements is needed and the patterns should be re-usable.

deferred

To support multiple stakeholder views and purposes a mechanism for associating SACMElements is needed.

deferred

Need to add internationalization of the languages used so that elements can be described using multiple languages

deferred

There are unnecessary differences between the Assurance Case, Terminology, Argument, and Artifact package definitions, interfaces, and bindings.

deferred

There are several areas where the work packages for addressing issues 1, 2, 3, 5, 6, 7, 9, 11, or 12 missed changes, additions, and deletions to support internationalization and package simplification. Additionally, there are several style issues in the text that need to be made consistent.

deferred

In making support for the Terminology Package optional a compliance point for those that want to support the Terminology Package was mistakenly left out.

Add a Terminology Package Compliance point

In the first sentence of section 2.1 change “three” to “four”; in bulleted list in section 2.1 add a fourth bulleted item “Terminology Model”; and add a new section “2.5 Terminology Model compliance point”, with the text “Software that conforms to the specification at the Terminology Model compliance point shall be able to import and export XMI documents that conform with the SACM XML Schema produced by applying XMI rules to the normative MOF metamodel defined in this entire specification. The top object of the Terminology package as a unit of interchange shall be the SACM::TerminologyPackage element.

The Conformance clause identifies with clauses of the specification are mandatory (or conditionally mandatory) and which are optional for an implementation to claim conformance to the specification.”

See pdf “Adding Terminology Compliance Point.pdf” for markup of proposed changes.

Currently, the Artefact, and Activity classes use the type ‘date’ for some of their attributes, and the ‘date’ attribute is missing from the model and diagrams for ActivityEvent, despite appearing in the text of the specification.

Change date to string

In section 12.5.2 (Attributes of Artefact class) change “date: Date” to “date: String”. In section 12.5.4 (Attributes of ArtefactEvent class) add “date: String”. In section 12.5.6 (Attributes of Activity class) change “startTime: Date” to “startTime: String” and “endTime: Date” to “endTime: String”.

See pdf “Model uses undefined date type.pdf” for markup of proposed changes to Figure 2 and 12.1

The 31 uses of the class name “ArtefactElementCitation” and the 10 uses of the class name “ArgumentElementCitation” are inconsistent with the 20 uses of the class name “ArtefactAssetCitation” and 7 uses of the class name “ArgumentAssetCitation”.

Align terminology to use '...AssetCitation(s)'

To be consistent across the SACM 2.0 metamodel the “ArtefactElementCitation” and “ArgumentElementCitation” uses should be changed to “ArtefactAssetCitation” and “ArgumentAssetCitation” respectively, the class “ArtefactElementCitation” in figure 6 should be changed to “ArtefactAssetCitation”, and the 2 uses of the term “citedElement” should be changed to “citedAsset”.

See the pdf “terms Element and Asset are inconsistently used in citation-related classes.pdf” for markup of proposed changes.

Section 2 doesn’t make it clear that AssuranceCase compliance point is mandatory. Also, some text in section 2.4 should be moved to precede all the compliance point descriptions.

Make it clear that the Assurance Case compliance point is mandatory.

The sentence, “This compliance point is mandatory.” should be added at the beginning of the first paragraph of Section 2.4. The second paragraph should be moved to immediate follow the bullet point list of compliance points at the beginning of Section 2.

See the pdf “AssuranceCase compliance point is mandatory.pdf” for markup of proposed changes.

In the second paragraph of Section 2.1 there is currently the text, “The ‘ArtefactElementCitation’ class shall not be used.” This is incorrect. The ArtefactElementCitation class is still necessary for the use of Argumentation compliance point.

Correct erroneous text about 'ArtefactElementCitation’ class

Omit the sentence. “The ‘ArtefactElementCitation’ class shall not be used.”

See the pdf “Incorrect description of the Argumentation compliance point.pdf” for markup of proposed changes.

In Semantics sub-section, the text refers to ISO/IEC 15026, but it is written:
"An AssuranceCase element represents assurance cases as defined in ISO/IEC 15206."
It should be written:
"An AssuranceCase element represents assurance cases as defined in ISO/IEC 15026."

As part of the SACM 2.0 update the sub-section in question was rewritten and the typo referred to, that was present in SACM 1.1, was removed.

As part of the SACM 2.0 update the sub-section in question was rewritten and the typo referred to, that was present in SACM 1.1, was removed.

The class is described as ArgumentElementCitation in the section title, but CitationElement in the body text. For consistency with InformationCitationElement, it is probably supposed to be ArgumentCitationElement

Closed, no change.

As part of the SACM 2.0 update we addressed all inconsistent class naming in SACM 1.0. The particular classes discussed in this issue are no longer in SACM.

Because all the significant classes of the argumentation and artefact package inherit from ModelElement, and ModelElement must use the Description class to provide content (e.g. the text of a Claim), and Descriptions must (given the current multiplicity) contain an Expression object, both argumentation and artefact packages must use the terminology package.

Fix model to allow Terminology Package to be optional as intended

The multiplicity from TaggedValue to Expression and UtilityElement to Expression must be changed from ‘1’ to ‘0..1’ to allow this to be optional. In addition, a new attribute called “sExpression: String” (referring to ‘simple expression’) should be added to UtilityElement, and an additional attribute called “sKey: String” (referring to ‘simple Key’) should be added to TaggedValue.

In Section 8.4 (The description of UtilityElement) the following text needs to be added:

“Attributes
sExpression: String – the text that describes the value of the UtilityElement”

and

“Constraints
If an Expression class is associated (through the expression association) with UtilityElement then sExpression should be null”

In Section 8.8 (The description of TaggedValue) the following text needs to be added to the current ‘Attributes’ section:

“sKey: Expression – the text that describes the key of the tagged value”

and the following text to the existing ‘Constraints’ section:

“If an Expression class is associated (through the key association) with TaggedValue then sKey should be null”

See the pdf “The SACM 2.0 meta-model requires implementation of the Terminology Package.pdf” for markup of proposed changes to figures and “Terminology Package Implementation-8.4 and 8.8.pdf” for text changes.

Of the three compliance points, one is referred to with the word “Model” while the other two are not. All three should consistently use this word in describing the compliance points. Additionally, two times “model” is used instead of “Model”.

Change section 2 to be consistent in use of term "model"

In the bulleted list in section 2.1; the title of section 2.2; the first sentence of the first and second paragraphs of section 2.2; section 2.3; the title of section 2.4; and the first sentence of the first paragraph replace the text “Argumentation” and “Assurance Case” with “Argumentation Model” and “Assurance Case Model” respectively and replace “Artefact model” with “Artefact Model”.

See pdf “Use of word Model in Chapter 2.pdf” for markup of proposed changes.

SACM standard must accommodate assurance cases under development as this is expected to be a common usage ­ transferring assurance cases among their developers or maintainers. This includes those incomplete.

In addition to incompleteness, decisions may yet to be concerning option options including the type of certain relations ­ e.g. does an inference relation challenge or not. As the relative distinctions are not always known, particularly early in assurance cases construction, which currently abstract classes should be concrete classes should be reviewed and changed as required to accommodate this.

Recording explicit options yet to be decided among (and optionally their effects) could be useful (and also relevant to patterns).

More elements similar in name to the UnknownSubject might be included if required to meet this need.

Addressed by harmonization to create SACM 2.0.

Incomplete models, as always, can be exchanged. In addition, SACM 2 has added a new attribute to the base ModelElement class called isAbstract. This allows any part of an SACM model to marked as a placeholder for later instantiation according to optionally provided ImplementationConstraints. Status / lifecycle information about whether a modelElement is, for example, ‘Agreed / Confirmed / Rejected’, could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package).

Timing or change management information needs to be able to be associated with anything as anything can change over time. This includes for example with Attributes (and any Properties). In addition, how to best handle changes and change information over time needs to be reviewed throughout SACM.

The version and change management related information ­ although often kept in a CM system ­ needs to be exchangeable along with an assurance case. At least one exchange standard for CM information exists, TECHAMERICA EIA-836B: Configuration Management Data Exchange and Interoperability, publication date: Mar 1, 2010. It is reportedly both ANSI and DoD approved. (http://engineers.ihs.com/document/abstract/BMVKACAAAAAAAAAA) One option is for this to be appropriately included by reference.

Versioning should be available for everything. Identification and “HasVersion” attribute should be associated with a near root element, or this availability should be achieved in some other fashion. The standard should not restrict its availability and smallness of possible granularity of elements it may be applied to.

This level of fine grained versioning is outside the scope of SACM.

Versioning has been maintained as an attribute for the Artefact class, because in SACM’s management of evidence we are responsible for ensuring the complete and correct management of the artefact inventory. However, versioning of all of the other model elements lies outside the scope of the exchange model.

Comment – there must be other fine-grained model management / versioning standards) Versioning information could be added to every model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). However, because there are many ways to maintain version information, we decided to not standardize this.

The property elements of various kinds contain assertions concerning proper values for various properties (or attributes). Should they not therefore inherit from Assertion? This includes tagged values unless these are used to tag kinds of “annotations” instead of using general Annotation elements.

Addressed by harmonization to create SACM 2.0.

While we have maintained a simple property model for Artefacts in SACM 2.0, and given more generally the opportunity to document TaggedValues on any model element, SACM 2 agrees with this comment and recognised that substantive assertions about artefacts / evidence should be documented as Claims. Communities of interest have the option of standardising particular structured expressions and vocabulary for claims using the Terminology package.

SBVR should be available in SACM for use wherever this would make sense. This includes in (ARM) claims and ReasoningElements and in SAEM many assertions particularly claims and possible rationales. Wherever narrative or prose, or mathematical expressions are allowed, why not also allow SBVR (and some places graphics or even other media also) unless strong reasons exist for doing otherwise?

Addressed by harmonization to create SACM 2.0.

The underlying intent of this issue has been fundamental in shaping the redefinition of SACM 2.0. The authors agreed with the need to provide a means of establishing structured expressions and vocabulary for both the Artefact and Argumentation parts of SACM 2.0. These structured expressions can be standardized for communities of practice through common terminology packages. We did not use SBVR and the fact model approach of SBVR as the means of doing this because it was considered too heavyweight for our purposes.

The following aspects need to be accommodated:
Owning, creating, and approving can be done concurrently by multiple entities and different (sets of) entities over time.

Ownership can be divided unequally among owners and fractions could need to be recorded.

Ownership can have aspects, for example IP rights versus physical object ­ I own the book, but not its copyright.

Addressed by harmonization to create SACM 2.0.

SACM 2 allows explicit representation of Participants in the Artefact model. This allows the representation of stakeholders. It also now provides a very flexible means of documenting multiple relationships (using ParticipantRoleRelationship) between Artefacts and Participants.

How might and/or should the justification for an ArgumentReasoning element’s method(s) of argumentation be represented in SACM? Several options or possibilities exist. This justification might be a supplied by a Claim, a DescriptiveAssertion, or Assumption connected by an AssertedInference link or an AssertedConext link in turn potentionally supported by InformationElement, EvidenceElement, or Artifact. More generally justification for its method(s) of argumentation can be in the form of an assurance case. On the other hand might it be supplied by an AssertedContextLink to an Artifact or even simply a citation?

What is the designers approach? Should these options be restricted or others used ­ particularly for the link between the ArgumentReasoning element and justification of its methods? Should some approaches be preferred?

Addressed by harmonization to create SACM 2.0.

ArgumentReasoning is used in SACM 2.0 to describe AssertedRelations (e.g. AssertedInferences). These AssertedRelations can be justified with further supporting Assertions. ArgumentReasoning can optionally be fully documented as a structured argument with an associated ArgumentPackage. If this is done then, of course, it could be more fully justified.

Claims and other items can have versions that simultaneously exist but have different meanings. For example, what a Claim might represent includes:
• Required values
• Planned values to be achieved
• Supported (established, justified) values
Two or more of these can be relevant at the same time.
A suggestion has been made that SBVR be used (within associated properties?) to make this distinction. This would require that SBVR be available for these contents. Use of a TaggedValue is another possibility. Regardless of what mechanism is used, some standardization should be included for the key meanings.

Placing this distinction within the contents of claim true-false statement might be more awkward and not make it as readily handled by tools as having it reside in a property.

In any case, what is standardized needs to have precise definitions or distinguishable among multiple definitions (or explicitly made usage/implementation dependent?) as subtle variations in meaning are possible. Note that for some assertions differences might be entirely in the value for confidence.

Addressed by harmonization to create SACM 2.0.

SACM 2 has added a new attribute to the base ModelElement class called isAbstract. This allows any part of an SACM model to marked as a placeholder for later instantiation according to optionally provided ImplementationConstraints. Status / lifecycle information about whether a modelElement is, for example, ‘Agreed / Confirmed / Rejected’, could also be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package).

We are missing an SBVR vocabulary for ARM (authors view - this is work someone else
to do, maybe close/postpone)

Addressed by harmonization to create SACM 2.0.

We are no longer using SBVR.

A simple, natural and appropriate set of properties would have Property (abstract?) inheriting from Assertion (or less preferably ModelElement) and having ModelElementProperty, RepesentedObjectProperty, Event, and Timing inheriting from it (Property) and appropriately associated. Artifacts and DomainObjects would use RepesentedObjectProperty’s. The two classes of properties are needed to allow properties associated with a model element and those associated with what it represents to be distinguished. Likewise ModelElementEvent and RepesentedObjectEvent inherit from Event. What type of event timing an instance is relevant to will be clear from what it is associated with. CM events and properties for both model elements and what they represent could be treated within this approach.

Alternately, a usable set of properties could have Property inheriting from ModelElement and having ModelElementProperty, ArtifactProperty, DomainObjectProperty, Event, and Timing inheriting from it and appropriately associated. The three classes of properties are needed to allow properties associated with a model element and what it represents to be distinguished. Likewise ModelElementEvent, ArtifactEvent, and DomainObjectEvent inherit from Event. What type of event timing is relevant to will be clear from what it is associated with. CM events and properties could be treated likewise.

Addressed by harmonization to create SACM 2.0.

In SACM 2.0 we have a clear ArtefactProperty class to capture properties of an Artefact. This, for example, is separate from the ability to attach UtilityElements to an Model Element (that can be used to capture Model Element Properties, e.g. using TaggedValue). Standardised vocabularies and expressions for domain properties can be captured using a Terminology package (which supports inheritance).

Obviously, properties that apply to Model Elements must be distinguishable from Properties of what they represent. Both these kinds of properties appear in SACM models. The issues titled “Property Inherence Hierarchy” states a way of doing this.

Addressed by harmonization to create SACM 2.0.

In SACM 2.0 we have a clear ArtefactProperty class to capture properties of an Artefact. This, for example, is separate from the ability to attach UtilityElements to an Model Element (that can be used to capture Model Element Properties, e.g. using TaggedValue). Standardised vocabularies and expressions for domain properties can be captured using a Terminology package (which supports inheritance).

Not just exhibits have events that affect them or otherwise relate to them. This is also relavent to what the elements represent.

An event might be associated with more than one element
For example, one bug fix that simultaneously change several code exhibits/artifacts.

Addressed by harmonization to create SACM 2.0.

In SACM 2.0 ArtefactEvents are optionally recorded as part of an Artefact’s description. They are intended to describe events relating to the artefact rather than events relating to the Artefact model element.

Versioning of all of the other model elements lies outside the scope of the exchange model. Versioning information could be added to every model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). However, because there are many ways to maintain version information, we decided to not standardize this.

The relationship of an Activity (e.g. fixing a bug) to multiple Artefacts can be recorded in SACM 2.0 as a many-to-one ArtefactActivityRelationship.

SBVR should be available for use within element contents everywhere unless strong, explicitly recorded reason exists for excluding it.

Addressed by harmonization to create SACM 2.0.

The underlying intent of this issue has been fundamental in shaping the redefinition of SACM 2.0. The authors agreed with the need to provide a means of establishing structured expressions and vocabulary for both the Artefact and Argumentation parts of SACM 2.0. These structured expressions can be standardized for communities of practice through common terminology packages. We decided to not use SBVR and the fact model approach of SBVR as the means of doing this because it was considered too heavyweight for our purposes.

Integration Issue: Inconsistency in level of prescription in the models (e.g. raised by Jeremy). E.g. arm does not prescribe what kinds of claims, instead SAEM has more presciption of the subtypes of

claims.

Addressed by harmonization to create SACM 2.0.

As part of the SACM 2.0 update we removed much of the prescription of domain-specific content in the artefact model of SACM. In particular, we avoided prescription where there was no industry consensus on the ways in which artefacts should be described. Instead, SACM 2.0 focuses on providing a standardised exchange model format within which description can be customized (see Description element of ModelElement) for communities of interest using user-defined vocabularies and structured expressions.

Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel

Addressed by harmonization to create SACM 2.0.

SupportLevel enumeration has been removed. In redefining SACM 2 it was recognized that there was no established approach (accepted by even a small group of industry) as to how to represent confidence and uncertainty on SACM artefact and argumentation elements. Consequently, SACM 2 deliberately pulled back from standardising in these areas. Confidence information could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). In addition, SACM 2 recognises that substantiative assertions about artefacts / evidence should be documented as Claims. It also recognizes the potential (which may be particularly relevant when discussing confidence) to attach metaclaims to any Assertion (see metaClaim association on Assertion).

There is no support for patterning, which is found to be useful current practice.

Addressed by harmonization to create SACM 2.0.

SACM 2 has added a new attribute to the base ModelElement class called isAbstract. This allows any part of an SACM model to marked as a placeholder for later instantiation according to optionally provided ImplementationConstraints. This allows us to represent Argumentation and Artefact patterns as models. The full documentation of these patterns lies outside the scope of SACM, but was recognized as being possible using SPMS referring to these SACM models.

The name 'Evidence' implies a certain association between some Information / some artefact and some claim. In ARM it was recognised that information can be used both to define context and as

supporting evidence to an assertion. This suggests that many of the prefixes in the SAEM 'Evidence....' should be changed to allow them to more generally refer to Information (and specialise to Evidence if

required)

Addressed by harmonization to create SACM 2.0.

In SACM 2.0 we have changed the use of the term ‘Evidence’ to become ‘Artefact’ to avoid this problem.

combined standard should include a vocabulary for talking about standards of proof

Addressed by harmonization to create SACM 2.0.

In redefining SACM 2 it was recognized that there was no established approach (accepted by even a small group of industry) as to how to represent confidence and uncertainty on SACM artefact and argumentation elements. Consequently, SACM 2 deliberately pulled back from standardising in these areas. Confidence information could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). In addition, SACM 2 recognises that substantiative assertions about artefacts / evidence should be documented as Claims. It also recognizes the potential (which may be particularly relevant when discussing confidence) to attach metaclaims to any Assertion (see metaClaim association on Assertion).

The SBVR vocabulary for evidence in Annex A is missing several definitions.

Addressed by harmonization to create SACM 2.0.

SACM 2.0 is no longer using the SBVR approach.

Figure 9.1 shows associations between ArgumentReasoning and AssertedInference, and between ArgumentReasoning and AssertedChallenge, which are not described in the text. Because these can be captured by the association between ArgumentReasoning and AssertedRelationship, I assume they are spurious

Spurious associations removed

These spurious associations have been removed and are no longer present in SACM.

The superclass of ArgumentElement is shown as ModelElement in the text but as ArgumentationElement in figure 9.1 on page 27.

Diagram and text use same name.

ArgumentAsset (the new name for ArgumentElement) now refers to the superclass as ArgumentationElement in both the diagram and text.

Issue: No approach to allowing Structured Expression of Claims within ARM

Addressed by harmonization to create SACM 2.0.

The underlying intent of this issue has been fundamental in shaping the redefinition of SACM 2.0. The authors agreed with the need to provide a means of establishing structured expressions and vocabulary for both the Artefact and Argumentation parts of SACM 2.0. These structured expressions can be standardized for communities of practice through common terminology packages. We no longer make use of SBVR and the fact model approach of SBVR as the means of doing this because it was considered too heavyweight for our purposes.

No method of handling confidence in the ARM

Addressed by harmonization to create SACM 2.0.

In redefining SACM 2 it was recognized that there was no established approach (accepted by even a small group of industry) as to how to represent confidence and uncertainty on SACM artefact and argumentation elements. Consequently, SACM 2 deliberately pulled back from standardising in these areas. Confidence information could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). In addition, SACM 2 recognises that substantiative assertions about artefacts / evidence should be documented as Claims. It also recognizes the potential (which may be particularly relevant when discussing confidence) to attach metaclaims to any Assertion (see metaClaim association on Assertion).

Integration Issue: Inconsistent approaches to handling counter argument and evidence. Both standards have evaluation mechanisms (e.g. refuting, rebutting mechanisms)

Addressed by harmonization to create SACM 2.0.

There were a number of examples where evidence relationships were considered to be more appropriately represented as being between Claims regarding Artefacts. These relationships between Claims are now represented in SACM 2.0 only using the AssertedRelations of the argumentation parts of SACM.

Integration Issue: Inconsistent terminology

Addressed by harmonization to create SACM 2.0.

As part of the SACM 2.0 update we addressed all inconsistent terminology that was present in SACM 1.0. This was one of the primary drivers of the update was to address this.

Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel

Addressed by harmonization to create SACM 2.0.

Contributes is an example of a relationship that was considered to be more appropriately represented as being between Claims regarding Artefacts. These relationships between Claims are now represented in SACM 2.0 only using the AssertedRelations of the argumentation parts of SACM.

Some of the concepts being captured in the model here overlap quite strongly with those of
Configuration Management, and would probably best left to standards in that domain rather
than creating a conceptual overlap here.

Addressed by harmonization to create SACM 2.0.

Versioning has been maintained as an attribute for the Artefact class, because in SACM’s management of evidence we are responsible for ensuring the complete and correct description of the artefact inventory. However, versioning of all of the other model elements lies outside the scope of the exchange model. Versioning information could be added to every model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). However, because there are many ways to maintain version information, we decided to not standardize this.

Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...

Addressed by harmonization to create SACM 2.0.

As part of the SACM 2.0 update we removed much of the prescription of domain-specific content in the artefact model of SACM. In particular, we avoided prescription where there was no industry consensus on the ways in which artefacts should be described. This has removed these overlapping elements. Instead, SACM 2.0 focuses on providing a standardised exchange model format within which description can be customized (see Description element of ModelElement) for communities of interest using user-defined vocabularies and structured expressions.

There is a fundamental difference in how modelling style of each metamodel. For example SAEM has a more "fact oriented" (nouns and verbs) approach which has a simpler MOF implementation. ARM has

classes instead.

Addressed by harmonization to create SACM 2.0.

We have consolidated and standardized the model approach and style to ensure consistency between the Argumentation and Artefact elements of SACM.

With integration EvidenceProperty inherit from Property as should all properties - directly or indirectly.

Removed multiple inheritence and different definition path.

The only occurrence of Properties within SACM 2.0 is with the class ArtefactProperty, which inherits from ArtefactAsset. There are no longer any other (inconsistent) definitions of properties with different inheritance.

The text states that the ArgumentReasoning class has a reference structure:Argument[0..1]

There is no Argument class defined. This should presumably be structure:Argumentation[0..1], as shown in Figure 9.1

Typo has been removed

This spurious typo has been removed and is no longer present in SACM.

From the viewpoint of compatibility with ISO/IEC 15026, the most important issue is that SACM contain an "Uncertainty" characteristic or attribute, a key aspect of 15026-2, in order to facilitate use of SACM with ISO/IEC 15026 conformant assurance cases. These would be useful throughout SACM as attributes of assertions or claims (not relations).

Current usage means a need exists for several data type options ­ not necessarily mutually exclusive.

Data Types
• Probability true: 0-1.00
• Type I error: 0-1.00
• Type 2 error: 0-1.00
• Enumeration: None, low, medium, large, unknown
• Standard deviation: real number
One might also want to include a data type with customizable meaning (values: 1-100) that would parallel the data type for “Strength” in present draft if this is retained.

This attribute element is associated with claims (assertions) and not with relations. Current SAEM draft defines characteristics ­ such as “Strength,” and “Confidence” ­ of evidence relations between an EvidenceItem (e.g. exhibit) and a DominAssertion. These relate to uncertainty but are associated with a relation and not with a DomainAssertion (claim). Note that the draft of SAEM states these are one-to-one relations unlike the many-to-one inferential relations in ARM.

Addressed by harmonization to create SACM 2.0.

In redefining SACM 2 it was recognized that there was no established approach (accepted by even a small group of industry) as to how to represent confidence and uncertainty on SACM artefact and argumentation elements. Consequently, SACM 2 deliberately pulled back from standardising in these areas. Confidence information could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). In addition, SACM 2 recognises that substantiative assertions about artefacts / evidence should be documented as Claims. It also recognizes the potential (which may be particularly relevant when discussing confidence) to attach metaclaims to any Assertion (see metaClaim association on Assertion).

2. What is needed to be known by tool or human is information required to establish the meaning of its content (interpret it) for this the notation/means used to express contents needs to be identified. An associated property could do this ­ and with more power/flexibility as any notation could be identified. Among other things, one should not presume that multiple tool vendors would never chose to support a (mathematically) formal notation other than SBVR. The use of different element types to identify nature of contents as “informal” or “structured” would be overkill. Rather, rename/combine “Consistency,” “ IsExpressed InLanguage”or other element to NotationUsed and provide appropriate attributes.

This level of prescription of description is no longer included in SACM 2.0.

This level of prescription of description in the Artefact model (i.e. referring to the form of expression of artefact contents) is no longer included in SACM 2.0. However, a community could standardize on an expected set of ArtefactProperties, description of these properties and vocabulary using a common Terminology Package.