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).

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.

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).

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.

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.

Deferred as still valid for SACM

This can be handled at present using the adhoc mechanism of TaggedValue. However, it is recognized that a more systematic solution is desirable. It is recognized that multiple stakeholders may have various roles with respect to assurance case elements (e.g. proposer, reviewer, endorsement). In addition, it could be useful to link these roles to a lifecycle model (similar to that proposed for Evidence in Section 7.7). This issue should be taken forward with the resolution of the change management and version control issue (16281), which was deferred in Ballot 4 (the 2nd Ballot of the SACM 1.1 RTF).

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.

Deferred as still valid for SACM

There needs to be a clear distinction between properties of model elements and properties (assertions) concerning domain objects being represented. It also may be worth thinking in terms of contestable vs. uncontestable assertions. (There may be some fluidity between these two concepts depending on context.) Are properties merely uncontestable assertions? This issue should be taken forward with the resolution of the change management and version control issue (16281) and the resolution of the property vs. assertion issue (16506), which were both deferred in Ballot 4 (the 2nd Ballot of the SACM 1.1 RTF).

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

Deferred as still valid for SACM

The RTF still recognize the important of supporting structured expressions (as could be done with SBVR). However, it has not been possible to harmonise the evidence part’s use of SBVR with an approach to use in the argument part.

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.

Deferred as still valid for SACM

RTF agree that the standard needs to make a sharper distinction between ‘uncontestable’ properties and assertions made (e.g. about evidence). In addition, there needs to be a clear distinction between properties of model elements and properties (assertions) concerning domain objects being represented. All assertions should inherit off a based Assertion class. To achieve this in SACM 1.1 would require a major reorganization of the standard that would significantly break backwards compatibility.

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.

Deferred as still valid for SACM

RTF agree that the standard needs to make a sharper distinction between ‘uncontestable’ properties and assertions made (e.g. about evidence). In addition, there needs to be a clear distinction between properties of model elements and properties (assertions) concerning domain objects being represented. All assertions should inherit off a based Assertion class. To achieve this in SACM 1.1 would require a major reorganization of the standard that would significantly break backwards compatibility.

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.

Deferred as still valid for SACM

RTF agree that the standard needs to make a sharper distinction between ‘uncontestable’ properties and assertions made (e.g. about evidence). All assertions should inherit off a based Assertion class. To achieve this in SACM 1.1 would require a major reorganization of the standard that would significantly break backwards compatibility.

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.

Deferred as still valid for SACM

The validity of this issue is still recognized. Providing full support for the issue as described requires support for exchanging assurance case patterns / templates. It has not been possible to implement this support in the current revision.

May a specialization of Claim element appear anywhere a Claim may? and vice versa? In June Day 2 diagram allows Calims in Augumentation elements but not InformationElements. However, InformationAssertions can appear both places. What is the reasoning behind this?

One might consider questions such as: For example, do restrictions exist on where an InformationAssertion may appear? Why should not a Claim element be used in place of each of the kinds or elements that inherit from it (e.g. in 2011 June Day 2)?

May a specialization of Claim element appear anywhere a Claim may? and vice versa? In June Day 2 diagram allows Claims in Augumentation elements but not InformationElements. InformationAssertions can appear both places. What is the reasoning behind this?

This issue has gone away because of the resolution to Issue 16838 (SR-24) that has now removed EvidenceAssertion as a specialization of Claim.

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?

Deferred as still valid for SACM

On further discussion, this issue was determined as being supported by the current SACM 1.0 structure, by means of a) being able to have an associated Argumentation structure to a ArgumentReasoning element (and that this structure – alongside presenting the expansion of the reasoning of the reasoning step (e.g. AssertedInference) – could also present backing for that reasoning) and b) being able to provide backing directly for a reasoning step by means of presenting an AssertedInference (or AssertedEvidence) in support of an AssertedInference (or AssertedEvidence). The issue of the ‘reusability’ of a generic piece of reasoning that is associated to an Argument Reasoning step is connected with the provision of generic but instantiable argument patterns. (Side note thought about Argument patterns requiring a peer concept to Argumentation – e.g. called ‘ArgumentationPattern’ that with the application / association of the necessary information to instantiate can fulfill the same role as ‘Argumentation’.

An InformationAssertion, particularly a ResultsAssertion, will commonly depend on other elements particularly EvidenceElements and Artifacts. These can be shown by AssertedLinks, but hould they also be able to be shown by HasDependenceOn.

Change not considered necessary

InformationAssertion is not an element in the released SACM 1.0.

The comment/issue was against an element that didn't end up in the published SACM 1.0 release.

This issue is N/A.

Claim true-false statements in SBVR can contain a variety of kinds of concerns. A variety of terms and values can occur. The diagram appears to show/allow only one facttype. Is this appropriate?

Change not considered necessary

Whilst it is understood that Claims (and EvidenceAssertions etc.) could be categorized with multiple types, it is also understood that as a statement in SBVR it must be said to be associated with just one facttype (i.e. facttype defines the template that the claim expression must conform to).

Asserted links are already one-to-many, but only one is allowed at the supported-by (single) end. However, a strong case can be made for being able to have multiple ones and being able to group them. Substantial discussions both leading to the conclusion this should be included occurred during two FTF meetings ­ most recently in June 2011. Unfortunately, this occurred as the last discussion at the June meeting and exactly how best to do it (e.g. element names) evidentially due to time constraints was not judged firmly enough agreed upon to appear in the diagram resulting from this meeting.

This still needs to be included/finalized.

Change not considered necessary

Current arrangement for AssertedRelationship has 0..* source, and 0..* target. No additional constraints are given. Consequently it is possible to have multiple 1..* AssertedRelationships.

An assurance case should be able to be composed of assurance cases. This can both math the history of development of the larger assurance case and potentially be a mechanism facilitating structuring and reuse.

An assurance case should be able to be composed of assurance cases. This can both math the history of development of the larger assurance case and potentially be a mechanism facilitating structuring and reuse.

The existing packaging of evidence, and reflexive composition (nesting) of Argumentation structures remains valid. Therefore an additional composition association is proposed on the AssuranceCase class to support the hierarchical composition of AssuranceCases

A compliance point is needed that combines ARM and simply Exhibit/Artifact thereby providing the minimum needed for an assurance case and also essentially matching several existing tools.

This resolution has been merged with 16857.
Disposition: Merged

“AssertedEvidentiary” might be better than “AssertedEvidence”. Another less prevalent term is “evidential”.

Rejected - keep as ARM
Disposition: Closed, no change

A generally available "citation" capability is needed. This should be able to refer to points throughout the assurance case and outside. This is particularly required inside ArgumentDescriptions, Context, and narrative elements but potentially useful essentially everywhere throughout SACM. In addition to all the merits of referencing, it is potentially a means to avoid duplication.

How to do this from within an ArgumentDescription such as to localize within the referring element may require a different kind of mechanism than one that is associated with the element as a whole. Although not necessarily as critical, being able to cite a portion of an element is also important.

Add the following to attributes subsection of 11.1.2 Document, page 43:
citation:String The full citation of the document (bibliographical reference)

ArgumentReasoning should be allowed to describe any kind of AssertedRelationship ­ most importantly describe AssertedChallange, which is equivalent to the opposite of AssertedInference. This element might also be used in SAEM derived material to avoid duplication.

This issue is resolved as part of the accumulated model improvement, esp. resolution 17347. The updated
Argumnetation Metamodel includes element AssertedChallenge. Also the Evidence Metamodel includes a
related element Challenges.
Disposition: Closed, not change

Artifacts ­ e.g. documentation, test results, components ­ are often organized into subsets (of all artifacts) and subsuming subsets and these sets given labels and treated for some purposes as units. EvidenceElements and InformationElements are not shown as being possible to structure in this way (say by a looped composition or association “arrow”). Some structuring mechanism is needed for this.

In addition, non-hierarchical structures also have uses

Response: Check with TPK whether we intended to edit the model to include a self-inclusion loop on
InformationElement? For non-hierarchichal structures can use “nature of dependency” RESOLUTION:
This is already allowed in SAEM (and that's what we're sticking with)
The SACM Evidence Metamodel provides a detail mechanism for achieving this (called EvidenceGroup).
Disposition: Closed, no change

Various meanings would appear possible including:
• Version derives from prior version
• Version derives from these versions of items
• Copy
• Uses information from
• Conclusion based on
• Change together or should change if other changes
• Uses
• Subsumes
• Compiled from or otherwise results from tool processing of
• Analysis result regarding
• Obtains resources from
• Share contents
This list is by no means exhaustive and not all may apply to a set of exhibits/artifacts of interest, but having some relations with more restricted meanings than HasDependencyOn or standardizing vaules for natureofdependency would be useful for key kinds of dependencies, e.g. is version derived from. Apparently, as natures of dependencies could vary multiple relations related to a single dependent element must be allowed.
Fanally, should:
• Values for natureofdependency that duplicate meanings of AssertedLinks be allowed?
• HasDependencyOn inherit from AssertedLinks (or less preferably just Assertion)?

add the following text to Semantics subsection of 11.1.8 IsBasedOn, page 46:
Derivation of one Document from another can have various meanings including, but not limited to the
following:
• Version derives from prior version
• Version derives from these versions of items
• Copy
• Uses information from
• Conclusion based on
• Change together or should change if other changes
• Uses
• Subsumes
• Compiled from or otherwise results from tool processing of
• Analysis result regarding
• Obtains resources from
• Share contents
This list is by no means exhaustive and not all may apply to a set of exhibits of interest. Apparently, as
natures of dependencies could vary multiple relations related to a single dependent element are possible.
The SACM Evidence Metamodel does not provide a normative enumeration of the nature of dependency.
However, should an author of a SACM document desire so, a TaggedValue mechanism shall be used for
this purpose with a tag 'natureofdependency'.
Add the following text to section 15.2.6 DependsOn, page 97:
Dependency of one ProjectElement on another can have various meanings. The SACM Evidence
Metamodel does not provide a normative enumeration of the nature of dependency. However, should an
author of a SACM document desire so, a TaggedValue mechanism shall be used for this purpose with a tag
'natureofdependency'.

May InformationAssertion’s contain explanatory or contextual material as well as assertion.

Existing mechanisms exist for annotation, and providing contextual relations to information. This is
unchanged from ARM. TaggedValue and Annotation mechanism is made universal across SACM (per
resolution of the issue 16836).
There is no longer an element InformationAssertion. There is an InformationElement, which may contain a
reference to an EvidenceItem, and an abstract element called Assertion, which has a concrete subclass
called Claim, and another set of subclasses related to an AssertedRelationship.
It should be discouraged to use the TaggedValue mechanism to add assertion to an InformationElement,
since this violates the nature of the SACM as a structured approach to exchanging assurance cases -
subclasses of Assertion element should be used instead.
Disposition: Closed, no change.

For example, a ResultsAssertion may be detailed in only a portion or portions of an artifact (or artifacts). Whether mapped via an Artifact or not, how are this or these linked to so that the scope is clear? A means is needed.

If you need to reference a portioned item, you need an artifact. Can use tagged values and annotation to
include other referencing information No further action planned The relationship between the artefact and
the EvidenceAssertion is made clear by the association. REJECT.
The SACM Evidence Metamodel provides more detailed solution.
Disposition: Closed, no change

How does a model element link to what it represents, in particular, to an actual artifact? Is it via using Artifact element? If so, what kind of links are used to link to appropriate Artifact element(s)? Issue includes how do Artifact elements link to actual artifacts. In addition, how this is done needs to be explained in standard.

Note that duplication of contents should be avoided, and duplication of the contents of artifacts’ bodies never required.

Accessibility achieved by Location: URN Question of how to characterize the identity of the “artifact-assuch”,
as well as its URN. May need a “name” attribute for the “source” class (Issue raised) SUGGESTED
MODIFICATION: Add identification to Exhibit Change name of 'url' attribute to 'location' keep as string.
In text will need to comment on the relationship to chain of custody
DRAFT EDIT: No action on changing the attribute, however add cross reference to custody section to
remind reader there is infrastructure for other kinds of location information.
Resolution to this issue is provided as part of the accumulated model changes resolution
17347, where both a link to an EvidenceItem element as well as a url are added to the
InformationElement.
Disposition: Duplicate

A Confidence element contains an assertion concerning proper confidence. Should it not therefore inherit from Assertion?

Authors response: Although every property can be considered to be asserted, SACM focus is on argument
structuring elements. Therefore no change made. Decision: This is not how represented in ARM or SAEM

• REJECT
  Disposition: Closed, no change