Structured Assurance Case Metamodel Avatar
  1. OMG Specification

Structured Assurance Case Metamodel — Closed Issues

  • Acronym: SACM
  • Issues Count: 362
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SACM23-12 List of companies, copyright dates, and description of changes needed SACM 2.2 SACM 2.3 Resolved closed
SACM23-17 AB request that new UML profile be normative and covered by a compliance point SACM 2.2 SACM 2.3 Resolved closed
SACM23-22 Errors in machine consumable files - emof and uml profile SACM 2.2 SACM 2.3 Resolved closed
SACM23-3 Figure 8.1 Mislabeled SACM 2.2 SACM 2.3 Resolved closed
SACM23-16 EMOF and UML profile files were html SACM 2.2 SACM 2.3 Resolved closed
SACM23-13 mistakenly created SACM 2.2 SACM 2.3 Duplicate or Merged closed
SACM23-1 SACM lacks display information for tool interchange SACM 2.1 SACM 2.3 Closed; Out Of Scope closed
SACM23-4 UML profile for SACM SACM 2.2 SACM 2.3 Resolved closed
SACM23-2 Terminology Categories need to nest SACM 2.2 SACM 2.3 Resolved closed
SACM23-5 List of companies, copyright dates, and description of changes needed SACM 2.2 SACM 2.3 Duplicate or Merged closed
SACM22-13 Referring to wrong version of SACM SACM 2.1 SACM 2.2 Resolved closed
SACM22-19 Typo in text of 11.7 SACM 2.1 SACM 2.2 Resolved closed
SACM22-17 Typo in OCL SACM 2.1 SACM 2.2 Resolved closed
SACM22-9 Section 3.1 Normative References SACM 2.1 SACM 2.2 Resolved closed
SACM22-3 "ID" never defined in Annex C graphical notation. Is it the gid? SACM 2.1 SACM 2.2 Resolved closed
SACM22-26 Graphical Notation Dot too small to work in tools. SACM 2.1 SACM 2.2 Resolved closed
SACM22-25 Remove duplicate text SACM 2.1 SACM 2.2 Resolved closed
SACM22-23 Missing words in 11.11 SACM 2.1 SACM 2.2 Resolved closed
SACM22-21 Missing line break in 11.8 SACM 2.1 SACM 2.2 Resolved closed
SACM22-20 Typo in text of 11.8 SACM 2.1 SACM 2.2 Resolved closed
SACM22-22 Typo in 11.9 SACM 2.1 SACM 2.2 Resolved closed
SACM22-28 Wrong package name used in second sentence of 9.3. SACM 2.1 SACM 2.2 Resolved closed
SACM22-12 Defining terms used in SACM SACM 2.1 SACM 2.2 Resolved closed
SACM22-11 Section 3.2 Non-normative References SACM 2.1 SACM 2.2 Resolved closed
SACM22-16 Flexibility in relationships SACM 2.1 SACM 2.2 Resolved closed
SACM22-15 Clarify bindings and interfaces SACM 2.1 SACM 2.2 Resolved closed
SACM22-14 Confusing use of the term property SACM 2.1 SACM 2.2 Resolved closed
SACM22-18 Definition is unclear SACM 2.1 SACM 2.2 Resolved closed
SACM22-7 Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it. SACM 2.1 SACM 2.2 Resolved closed
SACM22-2 SACM lacks display information for tool interchange SACM 2.1 SACM 2.2 Deferred closed
SACM22-1 Figure 11.1. Missing 'content' composition on ArgumentAsset SACM 2.1 SACM 2.2 Resolved closed
SACM22-24 Clarification of use of AssertedContext SACM 2.1 SACM 2.2 Resolved closed
SACM21-109 New notations for asserted context and asserted artifact context SACM 2.0 SACM 2.1 Resolved closed
SACM21-84 http -> https in MOF file SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-83 Why MOF 2.0 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-82 PNG images SACM 2.0 SACM 2.1 Resolved closed
SACM21-81 !!.14 or 11.14 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-80 SACM21-1 through 13 were unnecessary SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-79 Issue 55 material includes Issue 30 changes SACM 2.0 SACM 2.1 Resolved closed
SACM21-78 multiplicity change missing figures SACM 2.0 SACM 2.1 Resolved closed
SACM21-77 Missing Concrete Syntax in 11.10 SACM 2.0 SACM 2.1 Resolved closed
SACM21-76 Date or date in 12.11 SACM 2.0 SACM 2.1 Resolved closed
SACM21-72 newline SACM 2.0 SACM 2.1 Resolved closed
SACM21-71 multiplicity in figure and text do not match SACM 2.0 SACM 2.1 Resolved closed
SACM21-70 trailing bullet SACM 2.0 SACM 2.1 Resolved closed
SACM21-69 SPMS version SACM 2.0 SACM 2.1 Resolved closed
SACM21-68 Typo on pdf pg 10 SACM 2.0 SACM 2.1 Resolved closed
SACM21-67 http -> https SACM 2.0 SACM 2.1 Resolved closed
SACM21-65 SACM21-20 the changes are inconsistent with pdf SACM 2.0 SACM 2.1 Resolved closed
SACM21-64 SACM21-14 and SACM21-16 bad urls SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-13 Address missing elements of first 12 issues and address style consistency SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-12 Need for the ability to group SACMElements SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-11 Better support for patterns is needed SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-10 Simplification of ArtifactAssetRelationship SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-9 Need to simplify the citation classes of SACM SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-8 Elements in all parts of SACM need to be considered as artifacts and appropriate context and support relationships captured. SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-7 Need more consistency in packages, interfaces and binding SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-6 SACM needs support for Internationalization SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-5 Simplification of elements contained in packages SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-4 Need to simplify internationalization support in Expressions. SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-3 Alow AssertedRelationship to express if it is a counter relationship SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-2 Simplify ArtifactElement and its sub-types SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-1 Align with American English to support use of SACM by The Open Group SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-31 B and A or A and B SACM 2.0 SACM 2.1 Resolved closed
SACM21-30 Replace "that" with "whether"? SACM 2.0 SACM 2.1 Resolved closed
SACM21-25 Spelling mistake in 11.8 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-22 Spelling mistake in 2.5 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-21 Mistake in element name in 2.3 text SACM 2.0 SACM 2.1 Resolved closed
SACM21-20 Concepts in SACM 2 have no direct graphical notation SACM 2.0 SACM 2.1 Resolved closed
SACM21-19 Missing role discription for terminology model SACM 2.0 SACM 2.1 Resolved closed
SACM21-18 Misleading section title for 1.3 Artifact SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-62 Outdated constraints for class Claim SACM 2.0 SACM 2.1 Duplicate or Merged closed
SACM21-58 In 11.13 the +target should have multiplicity of 1 SACM 2.0 SACM 2.1 Resolved closed
SACM21-55 Unnecessary constraint statement in 11.11 SACM 2.0 SACM 2.1 Resolved closed
SACM21-107 Graphical notation for SACM Argumentation concepts SACM 2.0 SACM 2.1 Resolved closed
SACM21-75 Date or date in 12.9 SACM 2.0 SACM 2.1 Resolved closed
SACM21-74 Date or date in 12.7 SACM 2.0 SACM 2.1 Resolved closed
SACM21-73 text and figure mismatch ArgumentPackage<-->ArgumentPackageInterface SACM 2.0 SACM 2.1 Resolved closed
SACM21-66 Confirm URI on title page SACM 2.0 SACM 2.1 Resolved closed
SACM21-17 Incorrect description of package SACM 2.0 SACM 2.1 Resolved closed
SACM21-16 Invalid URL SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-15 Association is inconsistent with semantics SACM 2.0 SACM 2.1 Resolved closed
SACM21-14 Broken Link SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-29 Duplicative paragraphs? SACM 2.0 SACM 2.1 Resolved closed
SACM21-24 Punctuation and spacing errors SACM 2.0 SACM 2.1 Resolved closed
SACM21-23 Spelling mistake in 9.1 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM2_-9 Elements in all parts of SACM need to be considered as artifacts and appropriate context and support relationships captured. SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-8 Align with American English to support use of SACM by The Open Group SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-7 Simplification of ArtifactAssetRelationship SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-6 Simplify ArtifactElement and its sub-types SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-5 Alow AssertedRelationship to express if it is a counter relationship SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-4 Need to simplify internationalization support in Expressions. SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-3 Simplification of elements contained in packages SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-1 Need to simplify the citation classes of SACM SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-10 Better support for patterns is needed SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-11 Need for the ability to group SACMElements SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-2 SACM needs support for Internationalization SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-24 Need more consistency in packages, interfaces and binding SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-26 Address missing elements of first 12 issues and address style consistency SACM 2.0b2 SACM 2.0 Deferred closed
SACM2-73 There is no compliance point for those that support/use the Terminology Package specified in SACM 2.0’s metamodel. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-72 Model uses undefined ‘date’ type. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-71 In the classes related to Citations, the terms Element and Asset are inconsistently used. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-70 Section 2 doesn’t make it clear that AssuranceCase compliance point is mandatory. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-69 Incorrect description of the Argumentation compliance point. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-81 Typo in reference to ISO/IEC 15026 SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-30 Inconsistent naming of class SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-68 The SACM 2.0 meta-model requires implementation of the Terminology Package in spite of the text of Chapter 2 on compliance points saying it is optional. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-67 Inconsistent use of the word “Model” in describing the three compliance points SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-17 Assurance Cases under development or Incomplete ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-28 Scope of availability of change management information SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-23 Properties as Assertions ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-29 SBVR should be available in SACM for use wherever this would make sense SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-26 Ownership needs improved representation SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-18 Justification of Methods of Reasoning ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-19 Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-12 We are missing an SBVR vocabulary for ARM SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-16 Property Inherence Hierarchy ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-20 Properties of Model Elements must be Distinguished from Properties of what they Represent ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-22 Events should be able to be Associated with all Kinds of ModelElements ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-21 Making Role Binding and SBVR more generally available ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-14 Integration Issue: Inconsistency in level of prescription in the models SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-13 Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-11 There is no support for patterning, which is found to be useful current practice. SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-5 prefixes in the SAEM 'Evidence.... SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-15 combined standard should include a vocabulary for talking about standards of proof SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-1 Add missing definitions to SBVR Vocabulary in Annex A SACM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-33 Apparently spurious associations on class diagram SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-32 Superclass in text is inconsistent with diagram SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-8 Issue: No approach to allowing Structured Expression of Claims within ARM SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-6 No method of handling confidence in the ARM SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-2 Integration Issue: Inconsistent approaches to handling counter argument and evidence SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-10 Integration Issue: Inconsistent terminology SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-9 Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-3 Page73 ,section 13.2, figure21 SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-4 Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ... SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-7 fundamental difference in modelling style of each metamodel SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-27 EvidenceProperty inherit from Property SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-31 Reference to non-existent class SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-25 Uncertainty characteristic for claims SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-24 Identifying nature of element contents SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM11-2 Scope of availability of change management information SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-1 Need for general facility for stating and handling issues SAEM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-12 Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-11 Events should be able to be Associated with all Kinds of ModelElements ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-10 Making Role Binding and SBVR more generally available ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-9 Property Inherence Hierarchy ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-8 Properties of Model Elements must be Distinguished from Properties of what they Represent ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-7 Properties as Assertions ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-4 Assurance Cases under development or Incomplete ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-3 Uncertainty characteristic for claims SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-6 SBVR should be available in SACM for use wherever this would make sense SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-5 Ownership needs improved representation SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-34 All associations need to be labeled with a verb SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-33 combined standard should include a vocabulary for talking about standards of proof SACM 1.0 SACM 1.1 Deferred closed
SACM11-32 Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ... SACM 1.0 SACM 1.1 Deferred closed
SACM11-31 There is no support for patterning, which is found to be useful current practice. SACM 1.0 SACM 1.1 Deferred closed
SACM11-30 fundamental difference in modelling style of each metamodel SACM 1.0 SACM 1.1 Deferred closed
SACM11-29 prefixes in the SAEM 'Evidence.... SACM 1.0 SACM 1.1 Deferred closed
SACM11-28 Issue: No approach to allowing Structured Expression of Claims within ARM SACM 1.0 SACM 1.1 Deferred closed
SACM11-27 No method of handling confidence in the ARM SACM 1.0 SACM 1.1 Deferred closed
SACM11-26 Integration Issue: Inconsistent approaches to handling counter argument and evidence SACM 1.0 SACM 1.1 Deferred closed
SACM11-25 Integration Issue: Inconsistency in level of prescription in the models SACM 1.0 SACM 1.1 Deferred closed
SACM11-14 Usage of Specializations of Claim ARM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-13 Justification of Methods of Reasoning ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-17 InformationAssertion Dependencies on other Elements ARM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-16 Multiple Fact types/Rolebindings in a Claim Statement ARM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-15 Need for Groups of Asserted Links ARM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-24 Integration Issue: Overlapping scope SACM 1.0 SACM 1.1 Resolved closed
SACM11-23 Integration Issue: Inconsistent terminology SACM 1.0 SACM 1.1 Deferred closed
SACM11-22 Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel SACM 1.0 SACM 1.1 Deferred closed
SACM11-21 Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel SACM 1.0 SACM 1.1 Deferred closed
SACM11-20 Page73 ,section 13.2, figure21 SACM 1.0 SACM 1.1 Deferred closed
SACM11-19 ARM: Page 20, section 8.2.17 SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-18 ARM: Page 18, section 8.2.14 SACM 1.0 SACM 1.1 Resolved closed
SACM11-44 "ArgumentResoning" Class and "Assertedinferce" Class SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-43 AssertedRelationship Class SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-42 Use uniform 'statement' language for describing evidence properties SACM 1.0b1 SACM 1.1 Resolved closed
SACM11-41 Add missing definitions to SBVR Vocabulary in Annex A SACM 1.0b1 SACM 1.1 Deferred closed
SACM11-40 Need examples of the Evidence Metamodel XMI SACM 1.0b1 SACM 1.1 Resolved closed
SACM11-39 Use name "Artfact" rather than Exhibit" SAEM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-38 Identifying nature of element contents SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-37 EvidenceProperty inherit from Property SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-36 Assurance case composed of assurance cases ARM 1.0b1 SACM 1.1 Resolved closed
SACM11-35 We are missing an SBVR vocabulary for ARM SACM 1.0 SACM 1.1 Deferred closed
SACM11-91 typo: facctype section 12.3.1 SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-93 editing error & typo in 10.1.1 & 10.2.3 SACM 1.0 SACM 1.1 Resolved closed
SACM11-82 Rationalizing Citations within the Argumentation structure SACM 1.0 SACM 1.1 Resolved closed
SACM11-81 ArgumentReasoning associations with AssertedRelations SACM 1.0 SACM 1.1 Resolved closed
SACM11-85 AssertedRelationship Class SACM 1.0 SACM 1.1 Resolved closed
SACM11-84 "ArgumentResoning" Class and "Assertedinferce" Class SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-83 Replace Individual Class Examples with Single Integrated Example SACM 1.0 SACM 1.1 Resolved closed
SACM_-2 Incorrect URL for SACM in Appendix B SACM 1.0b2 SACM 1.0 Resolved closed
SACM_-3 Duplicate rolename 'subject' in class 'ProvidesContext' SACM 1.0b2 SACM 1.0 Resolved closed
SACM_-1 Association names should be nouns SACM 1.0b2 SACM 1.0 Resolved closed
SACM-145 Integration issue: introductory text should cover SAEM introductory material SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-152 We need a common route to support instance packaging SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-151 Using the term 'Argument' as the container for the "Claims-Argument-Evidence" aspect of ARM is confusing as people expec SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-147 evidence evaluation attributes SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-146 Lack of agreement the attribute types for some of the evidence evaluation subtypes - e.g. confidence 0..100 as integer SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-154 Need a revised compliance point approach SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-156 exchanged model instances should indicate which compliance points have been satisfied SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-155 The detailed enumerated attributes in SAEM need a corresponding location in SACM SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-149 If AssertedRelationships are genuinely Assertions then they should be subtypes of Assertion SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-148 No AssuranceCase Element in either ARM or SAEM - necessary for a Structured Assurance Case Metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-153 Metamodel packaging should broadly align with ARM/SAEM elements SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-157 Combined specification should have routes and guidance broadly corresponding to ARM and SAEM SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-150 counter evidence and challenge should be better modelled by a polarity attribute on the relation (AB comment) SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-167 Argument metamodel needs improvement SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-166 Evidence Metamodel needs a Record element SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-162 Need to provide motivation (the underlying issue) for new “link group” SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-161 Question of how to characterize the identity of the “artifact-as-such”, as well as its URN SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-165 Wrong figure in Evidence Evaluation example SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-164 Needed assurance case compliance point ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-160 Need to clarify usage of “nature of dependency” to indicate this is not for evidential or argumentation relations SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-159 motivate link groups SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-168 ArgumentReasoning should also attach to AssertedChallange SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-158 The frontispiece sections (introduction, background, scope etc) needs to be edited to reflect integration SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-163 Name AssertedEvidence ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-144 Integration Issue: Combined scope needs to include original scopes, and any emergent scope SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-143 Integration issue: An overall goal is to integrate the ARM and SAEM specifications into SACM in a coherent way. SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-142 Incorporate 12.5.1 EvidenceRequest (p82) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-141 Incorporate 12.4.4 HasRoleIn (p81) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-135 Incorporate 12.3.2 Service (p79) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-134 Incorporate 12.3.1 CollectionMethod (abstract) (p78) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-138 Incorporate 12.4.1 Originator (abstract) (p80) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-137 Incorporate 12.3.4 Tool (p79) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-133 Incorporate 12.2.6 DependsOn (p77) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-140 Incorporate 12.4.3 Organization (p81) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-139 Incorporate 12.4.2 Person (p80) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-136 Incorporate 12.3.3 Method (p79) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-125 Incorporate 12.1.3 StandardOfProof (enumeration) (p73) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-124 Incorporate 12.1.2 Package (p72) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-123 Incorporate 12.1.1 AdministrativeElement (abstract) (p71) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-122 Incorporate 11.7.1 EvidenceGroup (p69) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-126 Incorporate 12.1.4 AdministrativeProperty (abstract) (p74) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-119 Incorporate 11.6.2 Negates (p67) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-118 Incorporate 11.6.1 EvidenceResolution (abstract) (p66) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-121 Incorporate 11.6.4 Resolves (p68) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-120 Incorporate 11.6.3 Refutes (p67) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-129 Incorporate 12.2.2 ActivityProperty (abstract) (p76) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-128 Incorporate 12.2.1 Activity (p75) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-127 Incorporate 12.1.5 RequiresPackage (p74) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-130 Incorporate 12.2.3 Satisfies (p76) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-117 Incorporate 11.5.5 Amplifies (p65) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-63 Incorporate 9.2.1 FormalObject (abstract) (p33) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-62 Incorporate 9.1.3 RoleBinding (p31) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-61 Incorporate 9.1.2 DomainClaim (p 31) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-60 Incorporate 9.1.1 Assertion (p30) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-65 Incorporate 9.2.3 UnknownSubject (p34) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-64 Incorporate 9.2.2 Object (p33) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-59 Incorporate 8.1.12 IsReleasableTo (p28) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-58 Incorporate 8.1.11 HasSecurityClassification (p28) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-57 Incorporate 8.1.10 HasVersion (p27) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-56 Incorporate 8.1.9 IsExpressedInLanguage (p26) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-66 Incorporate 9.2.4 CompositeSubject (p34) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-54 Incorporate 8.1.6 HasMedia (p25) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-55 Incorporate 8.1.8 IsBasedOn (p26) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-28 SAEM: Page 16, section 8.2.2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-27 SAEM: Page 13, section 7.4, in table SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-30 SAEM: Page 19, section 8.2.8 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-29 Page 16, section 8.2.2 (2) SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-38 SAEM: Typographical errors SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-37 SAEM: Page 35, section 11 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-34 SAEM: Page 24,section 9.1.4 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-33 SAEM: Page 21,section 9.1,figure 6 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-31 SAEM: The class DocumentAttribute does not seem to be described in the standard SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-32 SAEM: Page 21, section 9.1, figure 6 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-26 SAEM: Page 12, text under figure 3 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-25 SAEM: Page 11, section 7.3, figure 2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-36 SAEM: Page 33, section 10.2.2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-35 SAEM: Page 33, section 10.2.1 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-109 Incorporate 11.4.1 EvidenceInterpretation (abstract) (p60) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-115 Incorporate 11.5.2 Conflicts (p64) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-114 Incorporate 11.5.1 EvidenceObservation (abstract) (p64) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-106 Incorporate 11.3.6 CompletenessLevel (enumeration) (p59) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-105 Incorporate 11.3.5 Completeness (p58) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-108 Incorporate 11.3.8 ReliabilityLevel (enumeration) (p59) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-107 Incorporate 11.3.7 Reliability (p59) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-111 Incorporate 11.4.3 MeansThat (p61) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-110 Incorporate 11.4.2 IsA (p61) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-112 Incorporate 11.4.4 IsCharacterizedBy (p62) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-113 Incorporate 11.4.5 IsScopedBy (p62) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-116 Incorporate 11.5.4 Weakens (p65) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-104 Incorporate 11.3.4 ConsistencyLevel (enumeration) (p58) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-88 Incorporate 11.1.2 Supports (p50) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-87 Incorporate 11.1.1 EvidenceRelation (abstract) (p50) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-84 Incorporate 10.4.8 CareOf (p46) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-83 Incorporate 10.4.7 CustodyProperty (abstract) (p46) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-92 Incorporate 11.2.4 ReportingLevel (enumeration) (p53) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-91 Incorporate 11.2.3 Reporting (p52) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-82 Incorporate 10.4.6 IsGeneratedAt (p45) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-81 Incorporate 10.4.5 IsRevokedAt (p44) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-90 Incorporate 11.2.1 Support (p51) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-89 Incorporate 11.1.3 Challenges (p50) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-80 Incorporate 10.4.4 IsTransferredTo (p43) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-85 Incorporate 10.4.9 AtLocation (p47) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-86 Incorporate 10.4.10 UsingProcess (p47) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-5 Increased clarity needed SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-2 General mistaken cardinality issue SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-1 Difference between properties and attributes fuzzy and unneccessary SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-8 Change name “Amplifies" SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-7 Eliminate or change name of “EffectiveTime" SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-4 Modify term “evidence collection project” SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-3 A more generally available "citation" capability ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-10 ArgumentReasoning available for more relations ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-9 Definition for “Rationale” element missing SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-6 Improve wording (editorial) SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-71 Incorporate 10.2.1 TimingProperty (abstract) (p37) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-70 Incorporate 10.1.4 OwnedBy (p36) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-79 Incorporate 10.4.3 IsCreatedAt (p42) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-78 Incorporate 10.4.2 IsAcquiredAt (p41) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-69 Incorporate 10.1.3 ApprovedBy (p36) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-68 Incorporate 10.1.2 CreatedBy (p35) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-74 Incorporate 10.2.4 EndTime (p38) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-73 Incorporate 10.2.3 StartTime (p38) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-77 Incorporate 10.4.1 EvidenceEvent (abstract) (p40) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-72 Incorporate 10.2.2 EffectiveTime (abstract) (p38) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-67 Incorporate 10.1.1 Provenance (abstract) (p35) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-75 Incorporate 10.2.5 AtTime (p39) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-76 Incorporate 10.3.1 Description (p40) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-21 ARM: Page 21, section 8.3.1 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-15 Hierarchical Collections of Artifacts or Other Items ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-14 Meaning of HasDependencyOn ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-11 Change name of “Originator” SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-20 ARM: Page 16, section 8.2.9 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-19 ARM: Page 12, Figure 2, Page 15, section 8.2.6 and page 16, section 8.2.9: In Figure 2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-23 ARM Typographical errors SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-22 ARM: Page 21, sections 8.3.1 and 8.3.2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-18 InformationAssertion’s and Informational Contents ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-17 Linking to Portions of an Artifact if this is what is Represented by a Model Element ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-24 SAEM: Page 6, section 7.1 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-16 Link to Actual Artifact Represented by Model Element ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-13 Confidence as an Assertion ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-12 1..2.14. Need to record modification events and who modified SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-132 Incorporate 12.2.5 IsAssociatedWith (p77) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-131 Incorporate 12.2.4 RequiresMethod (p77) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-98 Incorporate 11.2.10 Relevance (p55) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-97 Incorporate 11.2.9 Significance (p55) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-95 Incorporate 11.2.7 Confidence (p54) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-94 Incorporate 11.2.6 AccuracyLevel (enumeration) (p53) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-101 Incorporate 11.3.1 Originality (p57) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-100 Incorporate 11.2.12 Strength (p56) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-93 Incorporate 11.2.5 Accuracy (p53) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-103 Incorporate 11.3.3 Consistency (p58) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-102 Incorporate 11.3.2 OriginalityLevel (enumeration) (p57) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-96 Incorporate 11.2.8 ConfidenceLevel (enumeration) (p54) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-99 Incorporate 11.2.11 Level (enumeration) (p55) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-46 Incorporate 7.2.8 DomainAssertion (abstract) (p19) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-45 Incorporate 7.2.7 DomainObject (abstract) (p19) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-42 Incorporate 7.2.4 EvaluationAttribute (abstract) (p18) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-41 Incorporate 7.2.3 EvidenceProperty (abstract) (p17) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-44 Incorporate 7.2.6 Meaning (abstract) (p18) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-43 Incorporate 7.2.5 EvidenceItem (abstract) (p18) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-47 Incorporate 7.2.9 EvidenceEvent (abstract) (p20) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-40 Incorporate 7.2.2 EvidenceElement (abstract) (p16) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-39 Incorporate 7.2.1 Element (abstract) (p16) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-49 Incorporate 8.1.1 Exhibit (p 21) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-48 Incorporate 7.2.10 EvidenceEvaluation (abstract) (p20) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-53 Incorporate 8.1.5 IsPartOf (p25) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-52 Incorporate 8.1.4 HasElectronicSource (p24) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-51 Incorporate 8.1.3 Exhibit Property (p23) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-50 Incorporate 8.1.2 Document (p22) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed

Issues Descriptions

List of companies, copyright dates, and description of changes needed

  • Key: SACM23-12
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

    Need to update copyrights and list of submitters too.

  • Reported: SACM 2.2 — Fri, 18 Feb 2022 12:21 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Update items in spec to reflect new version

    Added sentence about the content of SACM 2.3 and revised previous SACM 2.2 content sentence to be past tense and update Figures 8.1, 9.1, 11.1 and 12.1 to reflect different modeling tool used to generate figures.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

AB request that new UML profile be normative and covered by a compliance point

  • Key: SACM23-17
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The original proposal of an informative uml profile needs to be made normative and covered by a compliance point.

  • Reported: SACM 2.2 — Tue, 22 Mar 2022 09:45 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Change of Annex F to Normative and add compliance point

    Changing Annex F to be Normative and describe it in section 2 as part of a new compliance point.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Errors in machine consumable files - emof and uml profile

  • Key: SACM23-22
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The emof file has a missing tag and uses an old version of xmi and the uml profile is not of the correct form due to the tooling used to generate it.

  • Reported: SACM 2.2 — Tue, 29 Mar 2022 12:05 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Regenerated SACM machine readable files using MagicDraw

    The eclipse tools we had used to generate the SACM machine readable files of the SACM model and the SACM UML profile were not producing appropriate files.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Figure 8.1 Mislabeled

  • Key: SACM23-3
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Some how Figure 8.1 was relabeled with the same label as Figure 7.2

  • Reported: SACM 2.2 — Wed, 16 Feb 2022 22:19 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Correct label on Figure 8.1

    Somehow in the revisions to SACM the figure in Section 8.1 was changed to the label used in the previous section (7.2). This needs to be fixed.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

EMOF and UML profile files were html

  • Key: SACM23-16
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The .xml files for emof and uml were github pages in html that had the expected emof and uml information as tables within the html. Need the content by itself.

  • Reported: SACM 2.2 — Tue, 22 Mar 2022 09:34 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Correct content of emof and uml profile files

    Pulled intended content out of html encoded material.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

mistakenly created

  • Key: SACM23-13
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    mistakenly created

  • Reported: SACM 2.2 — Fri, 18 Feb 2022 12:26 GMT
  • Disposition: Duplicate or Merged — SACM 2.3
  • Disposition Summary:

    This issue is extraneous and should be closed

    This issue was accidentally created and should be removed.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

SACM lacks display information for tool interchange

  • Key: SACM23-1
  • Status: closed  
  • Source: Linux Foundation ( David A. Wheeler)
  • Summary:

    SACM provides an abstract model for information on assurance cases. However, most humans normally interact with assurance cases shown as diagrams with supporting text. SACM 2.1 finally adds a standard graphical notation, and I'm happy to see it.

    However, SACM currently does not provide enough information to enable sharing diagrams in this notation. For example, there's no positioning or size information for displaying each ArgumentationElement in an ArgumentPackage. Tools do not always do a great job doing automatic layout, and in any case, humans often set up a layout to maximize human understanding. I believe this inability to exchange such information is a serious weakness in SACM.

    There are many ways to include such information.

    One way would be to require sharing display information in a standard form (like SVG) and provide a standard way to map between the SVG display information and the metamodel.

    An alternative is to extend the metamodel to include display information. Some basic constructs from SVG could be borrowed (being maximally compatible with SVG in general is recommended). An ArgumentationElement could have a new optional "location" with contents min_x, min_y, width, and height per SVG. Each ArgumentPackage would establish a viewpoint (and essentially determine portrait, landscape, or some other display is preferred).

    I'm sure there are many details to work out, but the first step is to agree that display information needs to be shared somehow.

    Thank you for your time.

  • Reported: SACM 2.1 — Sat, 24 Oct 2020 19:06 GMT
  • Disposition: Closed; Out Of Scope — SACM 2.3
  • Disposition Summary:

    Graphical layout formats out of scope of SACM standard

    The requested functionality is out of scope of the SACM work.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

UML profile for SACM

  • Key: SACM23-4
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    To allow for more consistent and direct use of SACM concepts in tools and other environments, a SACM UML profile is needed.

  • Reported: SACM 2.2 — Wed, 16 Feb 2022 22:21 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Add an annex with a UML profile of SACM

    Add a SACM UML profile to allow UML-based tools to work with SACM concepts by leveraging the SACM UML profile.

    Having the separate explicit UML profile of SACM that is maintained as part of the SACM specification will allow others to leverage that profile. For example, the GSN team can constrain the SACM UML profile into a GSN UML profile in a similar manner to how they leverage the SACM meta-model to define their GSN meta-model, making it cleaner for external groups leveraging GSN.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Terminology Categories need to nest

  • Key: SACM23-2
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    To allow for capturing terminology use as it occurs in communities there is a need to support nesting of categories in SACM’s Terminology Category class.

  • Reported: SACM 2.2 — Wed, 16 Feb 2022 22:17 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Allow Categories to have sub-categories

    Add to SACM::Terminology::Category class a field called category of type Category, with cardinality 0..* allowing composite categories to be directly definable.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

List of companies, copyright dates, and description of changes needed

  • Key: SACM23-5
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    For SACM 2.3 the list of companies involved, their respective copyrights, and a sentence about the scope of SACM 2.3 is needed.

  • Reported: SACM 2.2 — Wed, 16 Feb 2022 22:26 GMT
  • Disposition: Duplicate or Merged — SACM 2.3
  • Disposition Summary:

    This issue is extraneous and should be closed

    This issue was accidentally marked as deferred and balloted. The content of the issue was addressed by resolving SACM23-12. This issue is duplicative of that issue.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Referring to wrong version of SACM

  • Key: SACM22-13
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Section 6.1 is referring to the wrong version of SACM.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:18 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Referring to wrong version of SACM

    Update to refer to 2.1.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in text of 11.7

  • Key: SACM22-19
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Typo in 11.7 ArguementAsset (abstract) first line of section.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:32 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in text of 11.7

    Replace "bsse" with "base".

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in OCL

  • Key: SACM22-17
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Typo first line of OCL, there is an extra space.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:29 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in OCL

    Typo first line of OCL, there is an extra space in the word AssuranceCasePackage.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Section 3.1 Normative References


"ID" never defined in Annex C graphical notation. Is it the gid?

  • Key: SACM22-3
  • Status: closed  
  • Source: Linux Foundation ( David A. Wheeler)
  • Summary:

    Annex C repeatedly refers to an "ID". However, nowhere is an "ID" defined.

    Section 8.1 page 17, figure 8.1, show that every SACMElement has an optional "gid", and that is subclass ModelElement has an optional "name". Either might be an ID, but I can't find any specific statement making that clear. I'm guessing that the gid is the ID, since otherwise you'd have to match all the possible language strings. However, that should be made clear.

    Even more confusingly, an asCited Claim must state a package as well as the claim ID, so it appears that an ID is unique within a package but not between packages. A gid must be unique across the whole model. If IDs are unique across entire model, then in annex C it should made clear that package names are optional in an asCited Claim since they aren't needed to make it unique.

  • Reported: SACM 2.1 — Mon, 26 Oct 2020 03:19 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    ID for graphical elements - should be name not ID

    The figures mistakenly labelled with ID are revised to use name.

  • Updated: Tue, 29 Jun 2021 12:55 GMT

Graphical Notation Dot too small to work in tools.

  • Key: SACM22-26
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The "dot" in SACM 2.1's graphical notations is too small for tool implementation

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:46 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Graphical Notation Dot too small to work in tools.

    Increase "dot" size and update Figures.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Remove duplicate text

  • Key: SACM22-25
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The last sentence of the last paragraph of section 12.1 does not look right (not counting the misspelling of the second occurrence of “Artifacts”).

    Typo - phrase accidentally repeated.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:44 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Remove duplicate text

    Typo - phrase accidentally repeated.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Missing words in 11.11

  • Key: SACM22-23
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Missing "or counter argument" after "counter evidence" in 11.11 Semantics, last line of page.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:41 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Missing words in 11.11

    Insert missing “or counter argument" after "counter evidence" in 11.11.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Missing line break in 11.8

  • Key: SACM22-21
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Missing line break before "needsSupport" in Enumeration Litterals of 11.8.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:35 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Missing line break in 11.8

    Add line break before "needsSupport" to separate terms.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in text of 11.8

  • Key: SACM22-20
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In “Enumeration Litterals” of 11.8

    “Litterals” mis-spelled.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:34 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in text of 11.8

    “Litterals” mis-spelled.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in 11.9

  • Key: SACM22-22
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In 11.9 Semantics, misspelling – “with in” should be “within”

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:38 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in 11.9

    Replace “with in” with “within”

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Wrong package name used in second sentence of 9.3.

  • Key: SACM22-28
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Wrong package name used in second sentence of 9.3.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 16:19 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Wrong package name used in second sentence of 9.3.

    Need to correct package name

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Defining terms used in SACM

  • Key: SACM22-12
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Several terms are used in the specification without definition. Specifically: package binding, package interface, participant package, attribute and property. Defining these terms early in the specification will make it much easier for readers to understand the material.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:17 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Defining terms used in SACM

    Add the following to section 4.

    Attribute
    A feature of a meta-element with a primitive type, such as integer, real, text, boolean, or date.

    Feature
    Super class of attribute and reference.

    Participant Package
    A Participant Package is any Package or Package Interface referenced by a Package Binding.

    Package Binding
    A Package that has references to at least two Participant Packages and to elements of those Participant Packages and defines the relationships among those elements.

    Package Interface
    A Package that is used to specify the elements of one Package that are declared “public” and available for use by other Packages.

    Reference
    A feature of a meta-element whose type is of another meta-element, such as +ParticipantPackage for AssuranceCasePackage

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Section 3.2 Non-normative References

  • Key: SACM22-11
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Section 3.2 Non-normative References, 1 of the references have been updated and there is one new reference to add.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:16 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Section 3.2 Non-normative References

    Shown in pdf, described below.

    Replace:
    Goal Structuring Notation (GSN) Community Standard, Nov 2011. <http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf>

    With:
    Assurance Case Working Group. Goal Structuring Notation Community Standard. Technical Report
    SCSC‐141BA v2.0, Safety Critical Systems Club, 2018. <https://scsc.uk/SCSC-141B>.

    Add to end of list of references:
    Model Based System Assurance Using the Structured Assurance Case Metamodel. R. Wei, TP. Kelly*, X. Dai, S. Zhao, R. Hawkins. Elsevier Journal of Systems and Software (JSS), 154, 211-233, 2019.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Flexibility in relationships

  • Key: SACM22-16
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The relationships discussed in 9.4 should be more flexible – any sub-packages in any AssuranceCasePackage can be used by any other AssuranceCasePackage if the appropriate interfaces and bindings are defined/available.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:26 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Flexibility in relationships

    The relationships discussed in 9.4 should be more flexible – any sub-packages in any AssuranceCasePackage can be used by any other AssuranceCasePackage if the appropriate interfaces and bindings are defined/available.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Clarify bindings and interfaces

  • Key: SACM22-15
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The relationship and use of bindings and interfaces are not well described for packages.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:24 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Clarify bindings and interfaces

    The relationship and use of bindings and interfaces are not well described for packages - propose to add clarifying text for package interface and package binding elements and add an annex with examples.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Confusing use of the term property

  • Key: SACM22-14
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Sections 8.5 & 10.10 the Constraints sections and for 101.10 the Semantics section too, use the word “property”, which is already defined as another part of the model – need to change to another word to avoid confusion.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:20 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Confusing use of the term property

    On pages 19 and 30, change the word “property” to “feature”.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Definition is unclear

  • Key: SACM22-18
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Definition of 11.5 ArgumentPackageBinding is unclear. More details needed to make it understandable and the constraints need enhancement to convey model details.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:30 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Definition is unclear

    Revised to expand description and fixed label in constraints as well as added constrain language.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

  • Key: SACM22-7
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Need to revise this section to reflect the new version.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 14:37 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

    Added sentence about the content of SACM 2.2 and revised previous SACM 2.1 content sentence to be past tense. Proposed change in attached pdf.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

SACM lacks display information for tool interchange

  • Key: SACM22-2
  • Status: closed  
  • Source: Linux Foundation ( David A. Wheeler)
  • Summary:

    SACM provides an abstract model for information on assurance cases. However, most humans normally interact with assurance cases shown as diagrams with supporting text. SACM 2.1 finally adds a standard graphical notation, and I'm happy to see it.

    However, SACM currently does not provide enough information to enable sharing diagrams in this notation. For example, there's no positioning or size information for displaying each ArgumentationElement in an ArgumentPackage. Tools do not always do a great job doing automatic layout, and in any case, humans often set up a layout to maximize human understanding. I believe this inability to exchange such information is a serious weakness in SACM.

    There are many ways to include such information.

    One way would be to require sharing display information in a standard form (like SVG) and provide a standard way to map between the SVG display information and the metamodel.

    An alternative is to extend the metamodel to include display information. Some basic constructs from SVG could be borrowed (being maximally compatible with SVG in general is recommended). An ArgumentationElement could have a new optional "location" with contents min_x, min_y, width, and height per SVG. Each ArgumentPackage would establish a viewpoint (and essentially determine portrait, landscape, or some other display is preferred).

    I'm sure there are many details to work out, but the first step is to agree that display information needs to be shared somehow.

    Thank you for your time.

  • Reported: SACM 2.1 — Sat, 24 Oct 2020 19:06 GMT
  • Disposition: Deferred — SACM 2.2
  • Disposition Summary:

    Defer for further discussion

    Exchangeable graphic notations are an interesting addition to the SACM exchange standard for assurance cases but need more discussion.

  • Updated: Tue, 29 Jun 2021 12:55 GMT

Figure 11.1. Missing 'content' composition on ArgumentAsset

  • Key: SACM22-1
  • Status: closed   Implementation work Blocked
  • Source: Dependable Computing, LLC ( Will Hawkins)
  • Summary:

    I hope that this is not an erroneously reported issue. I am still very new to reading through OMG specifications and UML diagrams. Forgive me if this is a waste of your time.

    It appears that the EMOF and the description of ArgumentAsset in section 11.7 on page 38 list a content composition but that composition is not shown in Figure 11.1.

    I hope that this is useful. Thank you for all the great work on standardizing SACM 2.1. It's great to see the version out of Beta!

  • Reported: SACM 2.1 — Fri, 22 May 2020 23:37 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Figure 11.1 is correct but EMOF and text in 11.7 Associations are incorrect

    Updating EMOF file to reflect change and deleting the Associations section from section 11.7 of the SACM specification.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Clarification of use of AssertedContext

  • Key: SACM22-24
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:42 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Clarification of use of AssertedContext

    The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.

    Corrections for clarity and readability.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

New notations for asserted context and asserted artifact context

  • Key: SACM21-109
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The notation previously selected for these concepts could cause confusion when viewed by those familiar with UML notations or when viewing UML notations in proximity to these SACM concepts.

  • Reported: SACM 2.0 — Wed, 20 Mar 2019 20:54 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    New notations for asserted context and asserted artifact context

    Replace diamond line heads with squares with small line at end to distinguish them from UML notations in the 19 figures that used diamond line heads.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

http -> https in MOF file

  • Key: SACM21-84
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS18 - http -> https throughout for omg.org (all URIs)

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:34 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    http -> https in MOF file

    https is not supported in MOF 2.0 and we can not generate MOF 2.5.1 from the version of MagicDraw we have available.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Why MOF 2.0

  • Key: SACM21-83
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS19 - Why MOF 2.0, and not 2.5.1?  If no technical reason, update to 2.5.1.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:33 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Why MOF 2.0

    The MagicDraw version University of York has does not support exporting to MOF any more. We are trying to find any alternatives, but in the meantime we are stuck to this version.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

PNG images

  • Key: SACM21-82
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS17 - The PNG images are less than optimal, and fuzzy throughout Section 11 and Annex C in both clean and changebar docs.  SVG preferred in general.  Can these be regenerated appropriately?

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:33 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    PNG images

    new figures were generated for previous png figures - will be attached to the new report and used in the updated specification.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

!!.14 or 11.14

  • Key: SACM21-81
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS16 - Filename for SACM21-31/!!.14 - A2B.pdf  - I assume this should be 11.14… that’s going to wreak havoc with some filesystems.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:32 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    JIRA file names for files included in Report

    Passed on to Mariano for resolution - no change in specification or issue resolution materials.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

SACM21-1 through 13 were unnecessary

  • Key: SACM21-80
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS15 - SACM21-1 through 13 were unnecessary to add to archive and muddied the waters.  One for Mariano?

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:31 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    SACM21-1 through 13 were unnecessary

    When finishing the previous Report - 14 issues that were resolved in that Report were incorrectly passed to this RTF. Referred to Mariano to resolve.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Issue 55 material includes Issue 30 changes

  • Key: SACM21-79
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS14 - Issue 55 (ptc-19-02-33/SACM21-55/11.11-deletion.pdf) includes editorial ‘that’ to ‘whether’ that is listed in changebar as Issue 30.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:31 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    showing changes from different issue

    removed edit notations from a different issue from 11.11-deletion pdf

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

multiplicity change missing figures

  • Key: SACM21-78
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS13 - Issue 58 (ptc-19-02-33/SACM21-58/11.13 multiplicity.pdf) does not include the graphic for Figure 7.2 on pg 12 and changes on pg 37 11.14 marked as Issue 31, 20 - should not have been in this file.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:30 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    multiplicity change missing figures

    included figures in pdf of changes

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Missing Concrete Syntax in 11.10

  • Key: SACM21-77
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS12 - Issue 20 (ptc-19-02-33/SACM21-20/Concrete Syntax.pdf) does not include the Concrete Syntax added to Section 11.10 Assertion (abstract) and includes an editorial change (‘that’ to ‘whether’) on page 38 Sec 11.13 under Attributes that is not in the changebar or clean documents for issue 20. 

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:29 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Missing Concrete Syntax in 11.10

    Added note of insertion in early pages of Concrete Syntax pdf for missing Concrete Syntax in 11.10. Change in word ”that” to “whether” is correctly marked as Issue 30 (not 20) in the clean and changebar pdfs. Removed from Issue 20’s Concrete Syntax pdf.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Date or date in 12.11

  • Key: SACM21-76
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS11 – In 12.11 Activity, under Attributes, startDate:Date[0..1] does not match naming of type in Figure 12.1, which is startDate:date[0..1] and under Attributes, endDate:Date[0..1] does not match naming of type in Figure 12.1, which is endDate:date[0..1]

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:28 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Date or date in 12.11

    resolve difference

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

newline

  • Key: SACM21-72
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS7 – In 8.6 ModelElement (abstract), under Associations, need a newline between implementationConstraint and description.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:24 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    missing newline

    added newline to address comment

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

multiplicity in figure and text do not match

  • Key: SACM21-71
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS6 – In 8.2 SACMElement (abstract), under Attributes, isCitation and isAbstract do not match multiplicity in Figure 8.1

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:24 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    multiplicity in figure and text do not match

    figure is correct - fix text

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

trailing bullet

  • Key: SACM21-70
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS5 - In 6.2 Acknowledgements, there is an extra trailing bullet.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:23 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    fix trailing bullet

    line after bulleted list has an empty bullet - removed.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

SPMS version

  • Key: SACM21-69
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS4 - In 3.2 Non-normative References, SPMS is at 1.2, update doc number to formal/17-11-01.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:23 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    updating SPMS version reference

    In 3.2 Non-normative References, SPMS reference updated.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Typo on pdf pg 10

  • Key: SACM21-68
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS3 - Typo on pdf pg 10: Issues: hhttp in URI -> https

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:22 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    hhttp to https

    typo in url and need to move to https

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

http -> https

  • Key: SACM21-67
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS2 - http -> https throughout for omg.org, please check other sites and changeover as possible for futureproofing ( on omg.org: pdf pgs 1, 3, 4, 9, 10, 16 and pdf pgs 16, 65, 67).

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:22 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    http -> https for document urls?

    Reviewed pdf pgs 1, 3, 4, 9, 10, 16 and pdf pgs 16, 65, 67 and updated urls for https were applicable and resolved broken url for fda document.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

SACM21-20 the changes are inconsistent with pdf

  • Key: SACM21-65
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    RB2 – For SACM21-20 the changes are inconsistent with the changes specified in the associated PDF file. In Concrete Syntax.pdf, Figure 11.2 contains the title "Concrete Syntax for ArguementPackage" whereas "ArgumentPackage" is used in the actual text. The misspelled version is still present in the table of contents.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:20 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Arguement-Argument

    Correct spelling now shown in the track changes and clean specifications - see RB2-Arguement-Argument.pdf

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

SACM21-14 and SACM21-16 bad urls

  • Key: SACM21-64
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    RB1 – Two of the issues, SACM21-14 and SACM21-16, referred to bad urls and were marked as “Closed; No Change,” but the resolution was not specified – what was done to resolve these two issues?

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:20 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    URL reactivated

    The web site behind the urls had lost its registration on the University of York DSN system – that was fixed in a day or so.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Address missing elements of first 12 issues and address style consistency

  • Key: SACM21-13
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Fri, 25 Aug 2017 18:13 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Need for the ability to group SACMElements

  • Key: SACM21-12
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:44 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Better support for patterns is needed

  • Key: SACM21-11
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:42 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Simplification of ArtifactAssetRelationship

  • Key: SACM21-10
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:19 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Need to simplify the citation classes of SACM

  • Key: SACM21-9
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:13 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Elements in all parts of SACM need to be considered as artifacts and appropriate context and support relationships captured.

  • Key: SACM21-8
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:41 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Need more consistency in packages, interfaces and binding

  • Key: SACM21-7
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 24 Aug 2017 20:03 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

SACM needs support for Internationalization

  • Key: SACM21-6
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:14 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Simplification of elements contained in packages

  • Key: SACM21-5
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:16 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Need to simplify internationalization support in Expressions.

  • Key: SACM21-4
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:16 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Alow AssertedRelationship to express if it is a counter relationship

  • Key: SACM21-3
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:18 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Simplify ArtifactElement and its sub-types

  • Key: SACM21-2
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:19 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Align with American English to support use of SACM by The Open Group

  • Key: SACM21-1
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:21 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

B and A or A and B

  • Key: SACM21-31
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    p39:Last sentences of 11.13 and 11.14: Is A and B intentionally exchange in "the truth of" parts of the two sentences?

    11.13: "An inference asserted between two claims (A � the source � and B � the target) denotes that the truth of Claim A is said to infer the truth of Claim B."

    11.14: "An AssertedInference between two claims (A � the source � and B � the target) denotes that the truth of Claim B is said to infer the truth of Claim A."

    I would expect that the inference of truth comes from the source and is asserted for the target so the other way than 11.14 Semantics part defines. [Remark: I am not a native English speaker so it might be strange just for me why the "said to infer" expression is used instead of "inferred from". I interpret "The truth of X is said to infer the truth of Y." as "Truth of Y can be inferred from the truth of X." or "The truth of X logically necessitates the truth of Y."- is it correct?]

  • Reported: SACM 2.0 — Sun, 17 Feb 2019 04:03 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    A and B are mistakenly swapped in the specification text

    Need to revise labels in section 11.14 to correctly describe the functionality.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Replace "that" with "whether"?

  • Key: SACM21-30
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    p38, 11.13, Attributes: If "isCounter" seems to be set to false then stating that "a flag indicating that the AssertedRelationship counters its declared purposes" seems to be controversial, although I understand that the "false" is a default value. I think, adding "that whether the AssertedRelationship counters" is more clear. E.g. in 11.10 at a similar case, it writes "indicating the state ..." which was more clear.

  • Reported: SACM 2.0 — Sun, 17 Feb 2019 04:03 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Whether for that

    The observation is correct - replacing "That" with "Whether" in Section 11.13

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Spelling mistake in 11.8

  • Key: SACM21-25
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The section title "Literals" is misspelled.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 19:26 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly opened issue on spelling mistake.

    This is correct in specification - was looking at wrong version.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Spelling mistake in 2.5

  • Key: SACM21-22
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Terminology misspelled as "Termonology" in Section 2.5

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:58 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Again was looking at the wrong version of the SACM file

    The term is correctly spelled - no change needed.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Mistake in element name in 2.3 text

  • Key: SACM21-21
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Mistake in element name – remove “Model” from ArtifactModel::ArtifactPackage

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:56 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Name of element in compliance point mistakenly has "Model" in it

    Revise in specification section 2.3 - SACM 2.0 metamodel is not impacted.
    ArtifactModel::ArtifactPackage should be Artifact::ArtifactPackage

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Concepts in SACM 2 have no direct graphical notation

  • Key: SACM21-20
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Need a concrete syntax for the Argumentation metamodel that can represent the semantic definitions of the elements for semantic transparency, easing the burden of learning the elements and allowing them to be perceived directly from the notation.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:54 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Concrete Syntax and Graphical notation

    As a result of the work by a graduate student at University of York - which was presented in draft at the March and September meetings we now have a proposed graphical notation for the Argumentation portions of SACM. The proposed revisions to the last part of Section 1 to add this to the history of SACM, along with a new compliance point (2.6) for those choosing to support the notation, update to section 5 on symbols, and the specific notations in many parts of section 11, as well as examples in the new Annex C are provided.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Missing role discription for terminology model

  • Key: SACM21-19
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    There is no discussion of the terminology model’s role in SACM.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:32 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    No discussion of the role of the terminology model

    In the scope of SACM we should include a discussion of vocabulary and the role of the terminology model at a high level.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Misleading section title for 1.3 Artifact

  • Key: SACM21-18
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The Artifact title is misleading label for this portion of the scope description, this section is actually is about Evidence.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:30 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly opened issue on Section number name.

    Thought section was named "Artifact" and wanted to change it to "Evidence" but in fact it was already named that way. Had looked at earlier version of specification.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Outdated constraints for class Claim

  • Key: SACM21-62
  • Status: closed  
  • Source: LogicalHacking.com ( Achim D. Brucker)
  • Summary:

    The constraint section of the class Claims revers to two attributes ("assumed" and "toBeSupported") that are not part of the SACM 2.0 metamodel (they are replaced by the attribute "assertionDeclaration" of type "AssertionDeclaration).

    Proposed fix:

    Remove the constraint section. It is no longer required, as the "exclusive or"-constraint is already enforced by AssertionDeclaration being an enumeration.

  • Reported: SACM 2.0 — Tue, 19 Feb 2019 19:30 GMT
  • Disposition: Duplicate or Merged — SACM 2.1
  • Disposition Summary:

    Duplicative request for removal of constraint from 11.11

    Addressed in ballot 3.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

In 11.13 the +target should have multiplicity of 1

  • Key: SACM21-58
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The multiplicity of +target should be 1 (target:ArgumentAsset[1]).

  • Reported: SACM 2.0 — Mon, 18 Feb 2019 03:18 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    In 11.13 the +target should have multiplicity of 1

    Update text, diagrams, and emof model.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Unnecessary constraint statement in 11.11

  • Key: SACM21-55
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The constraint statement in 11.11 is unnecessary since there is no longer an assumed nor a toBeSupported attribute in the standard

  • Reported: SACM 2.0 — Mon, 18 Feb 2019 02:59 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    remove unnecessary constraint statement in 11.11

    There is no longer an assumed nor a toBeSupported attribute in the standard, can remove the constraint.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Graphical notation for SACM Argumentation concepts

  • Key: SACM21-107
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Shouldn't have a compliance point for the Concrete Syntax as part of this revision.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 20:58 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Graphical notation for SACM Argumentation concepts

    Remove the compliance point and definitions for a graphical notation that maps to all of SACM Argumentation concepts from the body of the specification and putting that graphical notation into an new Annex to parallel the existing notation mappings to SACM contained in Annex A.

    Three supporting pdfs provided to 1) remove compliance point and notation definitions from main body, 2) rename Annex C examples to Annex D, and 3) create new Annex C with graphical notations that represent all SACM Argumentation concepts.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Date or date in 12.9

  • Key: SACM21-75
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS10 – In 12.9 Event, under Attributes, date:Date[0..1] does not match naming of attribute in Figure 12.1, which is occurence:date[0..1]

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:28 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Date or date in 12.9

    aligned text

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Date or date in 12.7

  • Key: SACM21-74
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS9 - In 12.7 Artifact, under Attributes, date:Date[0..1] does not match naming of type in Figure 12.1, which is date:date[0..1]

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:27 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Date or date in 12.7

    align spelling

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

text and figure mismatch ArgumentPackage<-->ArgumentPackageInterface

  • Key: SACM21-73
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS8 – In 11.5 ArgumentPackageBinding, under Associations, participantPackage is listed as ArgumentPackageInterface, should be ArgumentPackage to match Figure 11.1.  Change type, or diagram.  The analogous Sec 12.4 ArtifactPackageBinding indicates the diagram here is likely correct.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:26 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    address discrepancy between text and figure

    Figure is correct - made text change

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:


Incorrect description of package

  • Key: SACM21-17
  • Status: closed  
  • Source: TGR Safety Management Ltd ( Timothy G Rowe)
  • Summary:

    The specification relates to ArtifactPackage, but the description of the package describes it as ArgumentPackage.

  • Reported: SACM 2.0 — Tue, 12 Jun 2018 01:56 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Element name mistake in 12.2

    In section 12.2 ArtifactPackage the element is mistakenly named ArgumentPackage - should be ArtifactPackage - correct in model.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Invalid URL

  • Key: SACM21-16
  • Status: closed   Implementation work Blocked
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    Details of the of the mapping between GSN elements and SACM are claimed to be at http://www.goalstructuringnotation.info/gsn-metamodel, but the link is invalid.

  • Reported: SACM 2.0 — Mon, 11 Jun 2018 02:00 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Fixed within a day of being reported

    This broken link was fixed within a few days of being reported.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Association is inconsistent with semantics

  • Key: SACM21-15
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The association `value` is shown as LangString[1..*], but the semantics describe it as a list of ExpressionLangString, not LangString.

  • Reported: SACM 2.0 — Sun, 10 Jun 2018 23:09 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    ExpressionLangString should be LangString

    Correct element name and change criteria from "must" to "should"

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Broken Link

  • Key: SACM21-14
  • Status: closed   Implementation work Blocked
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The link "http://www.goalstructuringnotation.info/sacm-examples
    Structured" leads to a "Site Unavailable" page.

  • Reported: SACM 2.0 — Fri, 8 Jun 2018 03:54 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Fixed within a day of being reported

    University of York had an issue with the routing to their web site - resolved shortly after it was reported.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Duplicative paragraphs?

  • Key: SACM21-29
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    p33: the last two paragraphs seem to be the same (from word to word) except the last words: "AssertedContext" and "ArtifactReference". I have no consistent understanding yet but it seems that the second paragraph should be removed (or something else was intended to be written there).

  • Reported: SACM 2.0 — Sun, 17 Feb 2019 04:02 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Duplicative paragraphs needing revision

    The two paragraphs at the bottom of page 33 of the specification need to be rewritten and merged to remove duplicative materials.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Punctuation and spacing errors

  • Key: SACM21-24
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In section 1.4 there is a missing "," after the word "Basically" at the beginning of the second sentence in the second paragraph. In section 9.2 "top level" should be hyphenated in the second sentence of the first paragraph. In the last sentence of section 11.1 the "." at the end is in the wrong place.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 19:23 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Minor edits to address mistakes

    Add comma after Basically in 1.4, in 9.2 hyphenate top-level, and correctly place the period in 11.1

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Spelling mistake in 9.1

  • Key: SACM21-23
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The word contained is spelled as"containined"

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 19:06 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly opened issue on spelling mistake.

    Word correctly spelled - was looking at the wrong version of SACM.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Elements in all parts of SACM need to be considered as artifacts and appropriate context and support relationships captured.

  • Key: SACM2_-9
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:41 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT

Align with American English to support use of SACM by The Open Group

  • Key: SACM2_-8
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:21 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Simplification of ArtifactAssetRelationship

  • Key: SACM2_-7
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:19 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Simplify ArtifactElement and its sub-types

  • Key: SACM2_-6
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:19 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Alow AssertedRelationship to express if it is a counter relationship

  • Key: SACM2_-5
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:18 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Need to simplify internationalization support in Expressions.

  • Key: SACM2_-4
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:16 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT

Simplification of elements contained in packages


Need to simplify the citation classes of SACM

  • Key: SACM2_-1
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:13 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Better support for patterns is needed

  • Key: SACM2_-10
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:42 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT

Need for the ability to group SACMElements

  • Key: SACM2_-11
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:44 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

SACM needs support for Internationalization


Need more consistency in packages, interfaces and binding

  • Key: SACM2_-24
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b2 — Thu, 24 Aug 2017 20:03 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Address missing elements of first 12 issues and address style consistency

  • Key: SACM2_-26
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b2 — Fri, 25 Aug 2017 18:13 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:09 GMT
  • Attachments:

There is no compliance point for those that support/use the Terminology Package specified in SACM 2.0’s metamodel.

  • Key: SACM2-73
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:04 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT
  • Attachments:

Model uses undefined ‘date’ type.

  • Key: SACM2-72
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:03 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    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

  • Updated: Tue, 19 Dec 2017 20:05 GMT
  • Attachments:

In the classes related to Citations, the terms Element and Asset are inconsistently used.

  • Key: SACM2-71
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:02 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Section 2 doesn’t make it clear that AssuranceCase compliance point is mandatory.

  • Key: SACM2-70
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:01 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT
  • Attachments:

Incorrect description of the Argumentation compliance point.

  • Key: SACM2-69
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:01 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Typo in reference to ISO/IEC 15026

  • Key: SACM2-81
  • Status: closed  
  • Source: Luxembourg Institute of Science and Technology ( Eric Grandry)
  • Summary:

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

  • Reported: SACM 1.1 — Wed, 28 Dec 2016 15:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Inconsistent naming of class

  • Key: SACM2-30
  • Legacy Issue Number: 19868
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    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

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

The SACM 2.0 meta-model requires implementation of the Terminology Package in spite of the text of Chapter 2 on compliance points saying it is optional.

  • Key: SACM2-68
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:00 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Inconsistent use of the word “Model” in describing the three compliance points

  • Key: SACM2-67
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:00 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT
  • Attachments:

Assurance Cases under development or Incomplete

  • Key: SACM2-17
  • Legacy Issue Number: 16289
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Scope of availability of change management information

  • Key: SACM2-28
  • Legacy Issue Number: 16281
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: SAEM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Properties as Assertions

  • Key: SACM2-23
  • Legacy Issue Number: 16505
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

SBVR should be available in SACM for use wherever this would make sense

  • Key: SACM2-29
  • Legacy Issue Number: 16313
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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?

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Ownership needs improved representation

  • Key: SACM2-26
  • Legacy Issue Number: 16310
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Justification of Methods of Reasoning

  • Key: SACM2-18
  • Legacy Issue Number: 16514
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims

  • Key: SACM2-19
  • Legacy Issue Number: 16511
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

We are missing an SBVR vocabulary for ARM

  • Key: SACM2-12
  • Legacy Issue Number: 16864
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    We are no longer using SBVR.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Property Inherence Hierarchy

  • Key: SACM2-16
  • Legacy Issue Number: 16507
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Properties of Model Elements must be Distinguished from Properties of what they Represent

  • Key: SACM2-20
  • Legacy Issue Number: 16506
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Events should be able to be Associated with all Kinds of ModelElements

  • Key: SACM2-22
  • Legacy Issue Number: 16510
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Making Role Binding and SBVR more generally available

  • Key: SACM2-21
  • Legacy Issue Number: 16509
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

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

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Integration Issue: Inconsistency in level of prescription in the models

  • Key: SACM2-14
  • Legacy Issue Number: 16841
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    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.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

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

  • Key: SACM2-13
  • Legacy Issue Number: 16781
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

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

  • Key: SACM2-11
  • Legacy Issue Number: 16853
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

prefixes in the SAEM 'Evidence....

  • Key: SACM2-5
  • Legacy Issue Number: 16849
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    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)

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

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

  • Key: SACM2-15
  • Legacy Issue Number: 16861
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

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

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Add missing definitions to SBVR Vocabulary in Annex A

  • Key: SACM2-1
  • Legacy Issue Number: 17335
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

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

  • Reported: SACM 1.0b1 — Tue, 24 Apr 2012 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    SACM 2.0 is no longer using the SBVR approach.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Apparently spurious associations on class diagram

  • Key: SACM2-33
  • Legacy Issue Number: 19870
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    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

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Spurious associations removed

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Superclass in text is inconsistent with diagram

  • Key: SACM2-32
  • Legacy Issue Number: 19867
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

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

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

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

  • Key: SACM2-8
  • Legacy Issue Number: 16844
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

No method of handling confidence in the ARM

  • Key: SACM2-6
  • Legacy Issue Number: 16843
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    No method of handling confidence in the ARM

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Integration Issue: Inconsistent approaches to handling counter argument and evidence

  • Key: SACM2-2
  • Legacy Issue Number: 16842
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Integration Issue: Inconsistent terminology

  • Key: SACM2-10
  • Legacy Issue Number: 16837
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistent terminology

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

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

  • Key: SACM2-9
  • Legacy Issue Number: 16807
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Page73 ,section 13.2, figure21

  • Key: SACM2-3
  • Legacy Issue Number: 16712
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    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.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

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

  • Key: SACM2-4
  • Legacy Issue Number: 16854
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

fundamental difference in modelling style of each metamodel

  • Key: SACM2-7
  • Legacy Issue Number: 16850
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    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.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

EvidenceProperty inherit from Property

  • Key: SACM2-27
  • Legacy Issue Number: 16882
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

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

  • Reported: SAEM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Reference to non-existent class

  • Key: SACM2-31
  • Legacy Issue Number: 19869
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    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

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Typo has been removed

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Uncertainty characteristic for claims

  • Key: SACM2-25
  • Legacy Issue Number: 16287
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: SAEM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Identifying nature of element contents

  • Key: SACM2-24
  • Legacy Issue Number: 16883
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: SAEM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Scope of availability of change management information

  • Key: SACM11-2
  • Legacy Issue Number: 16281
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: SAEM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    This is still felt to be valid issue, and it remains a difference between the evidence and argument portions of SACM. However, it still remains unclear how best to address this fine-grained change management and versioning issue for individual model elements (e.g. individual claims).

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Need for general facility for stating and handling issues

  • Key: SACM11-1
  • Legacy Issue Number: 16279
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    As everything is disputable (that is, can be challenged) and issues of many natures can arise, a general “Issue” facility is required. This should also span all of SACM.

    Currently, “EvidenceObservation” is used in the sense of “comment” or “issue”. Its name could be changed and its availability be made more general. Possibly it should include a sub-element with a more general name for issues that do not fit into current sub-element categories (or possibly not yet categorized).

    While probably not belonging in the core compliance point, facilities for issue resolution need to be likewise generally applicable.

  • Reported: SAEM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    Felt not necessary to have specific Issue element as general commenting and issue tagging can easily be done with TaggedValue which already exists.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims

  • Key: SACM11-12
  • Legacy Issue Number: 16511
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

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

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Events should be able to be Associated with all Kinds of ModelElements

  • Key: SACM11-11
  • Legacy Issue Number: 16510
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

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

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Making Role Binding and SBVR more generally available

  • Key: SACM11-10
  • Legacy Issue Number: 16509
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

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

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Property Inherence Hierarchy

  • Key: SACM11-9
  • Legacy Issue Number: 16507
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Properties of Model Elements must be Distinguished from Properties of what they Represent

  • Key: SACM11-8
  • Legacy Issue Number: 16506
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Properties as Assertions

  • Key: SACM11-7
  • Legacy Issue Number: 16505
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Assurance Cases under development or Incomplete

  • Key: SACM11-4
  • Legacy Issue Number: 16289
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Uncertainty characteristic for claims

  • Key: SACM11-3
  • Legacy Issue Number: 16287
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: SAEM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    Whilst still a gap between what is discussed in ISO 15026 and what is supported in SACM, it was recognized that there still is no common established state of the practice for recording confidence and uncertainty values on assurance case argument elements. It may be that a probability value would allow for the most commonality amongst current approaches. Guidance would be required on how to map to a probability value under different confidence determination regimes as listed above. There was still some disagreement about whether the current approach to modeling confidence in the evidence portion of SACM is fit for purpose. However for backward compatibility now changes have been made to this.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

SBVR should be available in SACM for use wherever this would make sense

  • Key: SACM11-6
  • Legacy Issue Number: 16313
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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?

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Ownership needs improved representation

  • Key: SACM11-5
  • Legacy Issue Number: 16310
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

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

  • Updated: Tue, 21 Apr 2015 01:16 GMT

All associations need to be labeled with a verb

  • Key: SACM11-34
  • Legacy Issue Number: 16863
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    All associations need to be labeled with a verb

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    Discussed at Boston 2014 June meeting and decided that this change is not necessary and that the issue should be closed.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

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

  • Key: SACM11-33
  • Legacy Issue Number: 16861
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

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

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

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

  • Key: SACM11-32
  • Legacy Issue Number: 16854
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

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

  • Key: SACM11-31
  • Legacy Issue Number: 16853
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

fundamental difference in modelling style of each metamodel

  • Key: SACM11-30
  • Legacy Issue Number: 16850
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    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.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

prefixes in the SAEM 'Evidence....

  • Key: SACM11-29
  • Legacy Issue Number: 16849
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    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)

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

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

  • Key: SACM11-28
  • Legacy Issue Number: 16844
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

No method of handling confidence in the ARM

  • Key: SACM11-27
  • Legacy Issue Number: 16843
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    No method of handling confidence in the ARM

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Integration Issue: Inconsistent approaches to handling counter argument and evidence

  • Key: SACM11-26
  • Legacy Issue Number: 16842
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Integration Issue: Inconsistency in level of prescription in the models

  • Key: SACM11-25
  • Legacy Issue Number: 16841
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    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.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Usage of Specializations of Claim

  • Key: SACM11-14
  • Legacy Issue Number: 16517
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

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

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Justification of Methods of Reasoning

  • Key: SACM11-13
  • Legacy Issue Number: 16514
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

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

  • Updated: Tue, 21 Apr 2015 01:16 GMT

InformationAssertion Dependencies on other Elements

  • Key: SACM11-17
  • Legacy Issue Number: 16521
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Multiple Fact types/Rolebindings in a Claim Statement

  • Key: SACM11-16
  • Legacy Issue Number: 16519
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

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

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Need for Groups of Asserted Links

  • Key: SACM11-15
  • Legacy Issue Number: 16518
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    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.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Integration Issue: Overlapping scope

  • Key: SACM11-24
  • Legacy Issue Number: 16838
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Overlapping scope

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    Remove duplicate

    Delete Section 9.1.9 EvidenceAssertion from the Argumentation section.
    Rename all occurrences of Assertion in the Evidence section to EAssertion.

  • Updated: Tue, 21 Apr 2015 01:16 GMT
  • Attachments:

Integration Issue: Inconsistent terminology

  • Key: SACM11-23
  • Legacy Issue Number: 16837
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistent terminology

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

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

  • Key: SACM11-22
  • Legacy Issue Number: 16807
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

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

  • Key: SACM11-21
  • Legacy Issue Number: 16781
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

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

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Page73 ,section 13.2, figure21

  • Key: SACM11-20
  • Legacy Issue Number: 16712
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    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.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

ARM: Page 20, section 8.2.17

  • Key: SACM11-19
  • Legacy Issue Number: 16694
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    One may want to state the context in which an AssertedRelationship holds. At present, the invariants on AssertedContext disallow this.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    The issued SACM 1.0 already allows this.

    AssertedContext relationship is from InformationElement to ReasoningElement (which includes AssertedRelationship as a subtype).

  • Updated: Tue, 21 Apr 2015 01:16 GMT

ARM: Page 18, section 8.2.14

  • Key: SACM11-18
  • Legacy Issue Number: 16693
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    : In the AssertedInference class, the invariants leave the possibility of inferring an AssertedRelationship from a set of claims. They do not, however, allow a Claim to be inferred from an AssertedRelationship. Since an AssertedRelationship is a kind of claim (not in the sense of the model, but in a general sense), it seems reasonable to allow it; that is, “I claim A because of the relationship between claims B and C”.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    *Invariant should be changed *

    Agreed – Invariant should be changed to read:

    On Page 49, section 9.1.12
    context AssertedInference
    inv SourceMustBeAssertion : self.source->forAll(s|s.oclIsTypeOf(Assertion))
    inv TargetMustBeAssertion : self.target->forAll(t|t.oclIsTypeOf(Assertion))

  • Updated: Tue, 21 Apr 2015 01:16 GMT
  • Attachments:

"ArgumentResoning" Class and "Assertedinferce" Class

  • Key: SACM11-44
  • Legacy Issue Number: 19544
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    According to "ArgumentResoning" Class and "Assertedinferce" Class on the SACM 1.0 spec,

    >ArgumentReasoning can be used to provide additional description or explanation
    >of the asserted inference or challenge that connects one or more Claims (premises)
    >to another Claim (conclusion). ArgumentReasoning elements are therefore
    >related to AssertedInferences and AssertedChallenges

    and

    >The AssertedInference association class records the inference that
    >a user declares to exist between one or more Assertion
    >(premises) and another Assertion (conclusion).

    It seems that AsseretedInference and AssertedChallenges implies
    strategy(Parallelogram) on the GSN.

    On the other hand, in "B.2.1 Goal Structuring Notation(GSN) Examples" in Annex B
    Parallelogram corresponds to ArgumentReasoning.

    These are confusing.
    Which one is correct?