Annex B (updated by Issue 16695) has the same problems as the XSD file (below), and further has no URI at all in the declaration of namespace SACM. Also oddly TARGET and TRUE are capitalized for no reason

The namespaces declared for the SACM namespaces e.g. xmlns:SACM="http://schema.omg.org/SACM/1.0" are inconsistent with those in the inventory.

Correct URLs are:

xmlns:ARM="www.omg.org/spec/SACM/20120501/Argumentation" schemaLocation="http://www.omg.org/spec/SACM/20120501/Argumentation.xsd"

xmlns:EM=" www.omg.org/spec/SACM/20120501/Evidence" schemaLocation="http://www.omg.org/spec/SACM/20120501/Evidence.xsd"

xmlns:SACM=" www.omg.org/spec/SACM/20120501/SACM" schemaLocation="http://www.omg.org/spec/SACM/20120501/SACM.xsd"

Change example in section B.1 into the following:
<?xml version="1.0" encoding="ASCII"?>
<ARM:Argumentation xmi:version="2.1"
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ARM=" www.omg.org/spec/SACM/20120501/Argumentation"
xmi:id="0" id="IPSA">
<xsd:import namespace=http://schema.omg.org/spec/XMI/2.1"
schemaLocation="http://www.omg.org/spec/XMI/20071213/XMI.xsd"/>
<xsd:import namespace="www.omg.org/spec/SACM/20120501/Argumentation" schemaLocation="
http://www.omg.org/spec/SACM/20120501/Argumentation.xsd" />
<argumentElement xsi:type="ARM:Claim" xmi:id="1" id=“C1" description="" content="C/S logic is fault
free"/> <argumentElement xsi:type="ARM:ArgumentReasoning" xmi:id="2" id=“RC1.1" content="Argument by
omission of all identified software hazards" describes="5 6"/>
<argumentElement xsi:type="ARM:ArgumentReasoning" xmi:id="3" id=“RC1.2" content="Argument by
satisfaction of all C/S safety requirements" describes="7 8 9"/>
<argumentElement xsi:type="ARM:InformationElement" xmi:id="4" id=“IRC1.1" description="Identified
software hazards"/>
<argumentElement xsi:type="ARM:Claim" xmi:id="5" id=“C1.1" description="" content="Unintended
opening of press (after PoNR) can only occur as a result of component failure"/>
<argumentElement xsi:type="ARM:Claim" xmi:id="6" id=“C1.2" description="" content="Unintended
closing of press can only occur as a result of component failure"/>
<argumentElement xsi:type="ARM:Claim" xmi:id="7" id=“C2.1" content="Press controls being 'jammed
on' will cause press to halt"/>
<argumentElement xsi:type="ARM:Claim" xmi:id="8" id=“C2.2" content="Release of controls prior to
press passing physical PoNR will cause press operation to abort"/>
<argumentElement xsi:type="ARM:Claim" xmi:id="9" id=“C2.3" description="" content="C/S fails safe
(halts on) and annunciates (by sounding Klaxon) all component failures" toBeSupported=”true”/>
<argumentElement xsi:type="ARM:Claim" xmi:id="12" id=“C2.1.1" content="Failure 1 of PLC state
machine includes BUTTON_IN remaining true"/>
<argumentElement xsi:type="ARM:Claim" xmi:id="13" id=“C2.2.1" content="Abort transition of PLC
state machine includes BUTTON_IN going false"/>
<argumentElement xsi:type="ARM:InformationElement" xmi:id="10" id=“S1.1" content="Fault tree
analysis cutsets for event 'Hand trapped in press due to command error'"/>
<argumentElement xsi:type="ARM:InformationElement" xmi:id="11" id=“S1.2" content="Hazard directed
test results"/>
<argumentElement xsi:type="ARM:InformationElement" xmi:id="14" id=“S2.1" description=""
content="black box testing"/>
<argumentElement xsi:type="ARM:InformationElement" xmi:id="15" id=“S2.2.1" content="C/S state
machine"/>
<argumentElement xsi:type="ARM:AssertedInference" xmi:id="16" id=“C1.1.1" description=""
source="5" target="1"/>
<argumentElement xsi:type="ARM:AssertedInference" xmi:id="17" id=“C1.1.2" source="6" target="1"/>
<argumentElement xsi:type="ARM:AssertedInference" xmi:id="18" id=“C1.2.1" source="7" target="1"/>
<argumentElement xsi:type="ARM:AssertedInference" xmi:id="19" id=“C1.2.2" source="8" target="1"/>
<argumentElement xsi:type="ARM:AssertedInference" xmi:id="20" id=“C1.2.3" source="9" target="1"/>
<argumentElement xsi:type="ARM:AssertedContext" xmi:id="21" id=“CIRC1.1" source="4" target="2"/>
<argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="22" id=“S1.1" source="10" target="5 6"/>
<argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="23" id=“S1.2" source="11" target="5 6"/>
<argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="24" id=“SC2.1" source="14" target="7"/>
<argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="25" id=“SC2.1.1" source="15"
target="12"/>
<argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="26" id=“SC2.2.1" source="15"
target="13"/>
<argumentElement xsi:type="ARM:AssertedInference" xmi:id="27" id=“DI C2.1" source="12"
target="7"/>
<argumentElement xsi:type="ARM:AssertedInference" xmi:id="28" id=“DI C2.2" source="13"
target="8"/>
<argumentElement xsi:type="ARM:AssertedContext" xmi:id="29" id=“AR29" source="2" target="16
17"/>
</ARM:Argumentation>
Change example in section B.2 into the following:
<?xml version="1.0" encoding="ASCII"?>
<ARM:Argumentation xmi:version="2.1"
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ARM=" www.omg.org/spec/SACM/20120501/Argumentation"
xmi:id="0" id="BSC11">
<xsd:import namespace=http://schema.omg.org/spec/XMI/2.1"
schemaLocation="http://www.omg.org/spec/XMI/20071213/XMI.xsd"/>
<xsd:import namespace="www.omg.org/spec/SACM/20120501/Argumentation" schemaLocation="
http://www.omg.org/spec/SACM/20120501/Argumentation.xsd" />
<argumentElement xsi:type="ARM:Claim" xmi:id="1" id=“Bluetooth secure" content="A bluetooth
enabled network provides adequate security"/>
<argumentElement xsi:type=“ARM: Claim" xmi:id="2" id=“Availability" content="A bluetooth enabled
network is adequately available [1] Section 1 para 3"/>
<argumentElement xsi:type=“ARM: Claim" xmi:id="3" id=“Access" description="" content="A bluetooth
enabled network provides adequate control for access to services and data [1] Section 1 para 3"/>
<argumentElement xsi:type=“ARM: Claim" xmi:id="4" id=“Confidentiality" content="A bluetooth
enabled network provides adequate levels of confidentiality [1] Setion 1 para 3"/>
<argumentElement xsi:type=“ARM: Claim" xmi:id="5" id=“Integrity" content="A bluetooth enabled
network provides adequate levels of integrity [1] Section 1 para 3"/>
<argumentElement xsi:type=“ARM: InformationElement" xmi:id="6" id=“Context: security policy and
scenario for use" content="Definitions are required of the intented security policy and the scenario of use
for the system, including what is regarded as 'adequate'"/>
<argumentElement xsi:type=“ARM: InformationElement" xmi:id="7" id=“References" content="[1]
Bluetooth security white paper 19/4/ 02"/>
<argumentElement xsi:type=“ARM: InformationElement" xmi:id="8" id=“Definition: Availability"
content="The system is capable of providing requested services to authorised users, in an
acceptable/defined time"/>
<argumentElement xsi:type=“ARM: InformationElement" xmi:id="9" id=“Definition: Access"
content="Only users permitted by the defined security policy have access to services and data"/>
<argumentElement xsi:type=“ARM: InformationElement" xmi:id="10" id=“Define: Confidentiality"
content="Unauthorised persons cannot intercept and understand information to which they are not
entitled"/>
<argumentElement xsi:type=“ARM: InformationElement" xmi:id="11" id=“Define: Integrity"
description="" content="Services and data are provided to authorised users as intended and without
corruption"/>
<argumentElement xsi:type=“ARM: AssertedContext" xmi:id="12" id=“AC1" source="7" target="1"/>
<argumentElement xsi:type=“ARM: AssertedContext" xmi:id="13" id=“AC2" source="6" target="1"/>
<argumentElement xsi:type=“ARM: AssertedContext" xmi:id="14" id=“AC3" source="8" target="2"/>
<argumentElement xsi:type=“ARM: AssertedContext" xmi:id="15" id=“AC4" source="9 " target="3"/>
<argumentElement xsi:type=“ARM: AssertedContext" xmi:id="16" id=“AC5" source="10" target="4"/>
<argumentElement xsi:type=“ARM: AssertedContext" xmi:id="17" id=“AC6" source="11" target="5"/>
<argumentElement xsi:type=“ARM: AssertedInference" xmi:id="18" id=“AI1" source="5 4 3 2"
target="1"/>
<argumentElement xsi:type=“ARM: ArgumentReasoning" xmi"id="19" id=“Argue over vulnerabilities"
description="" content="Argue for each security requirement identified in the security white paper"
describes="18"/>
</ARM:Argument>

Class ProvidesContext Figure 14.3 already inherits the 'subject' association from the EvidenceInterpretation element.

Remove association 'subject' from class 'ProvidesContext' (section 14.3.6, page 98):
subject:EvidenceElement[1]The subject of the ProvidesContext clause
Change Figure 14.3 with the following: << figure on p 134 of ptc/2012-06-04>>

Applies to: Sysa/10-03-15, section 8.1

Title: Association names should be nouns

Detail: The association names between classes in ARM should be labelled
with nouns. This will better conform to the OMG naming recommendations.

Update the document as follows, assuming resolution for issue 17347 has already been applied
Argumentation class (was previously 9.2.3, and has been renamed from Argument by other edits),
Association
“containsArgumentelement:ArgumentElement[0..*]” -> “argumentElement:ArgumentElement[0..*]”
“containsArgumentation:Argumentation[0..*]” -> “argumentation:Argumentation[0..*]”
CitationElement class (previously 9.2.8), Associations
“refersToArgumentelement:ArgumentElement[0..1]” ->
“argumentElementReference:ArgumentElement[0..1]”
“refersToArgument:Argument[0..1]” -> “argumentationReference:Argumentation[0..1]”
ArgumentReasoning class (previously 9.2.11), Associations
“hasStructure:Argument[0..1]” -> “structure:Argument[0..1]”
“describes:AssertedInference [0..*]” -> “describedInference:AssertedInference [0..*]”
Replace figure 9.1 with the following << figure on p 129 of ptc/2012-06-04>>

Integration issue: introductory text should cover SAEM introductory material

Replace section 7.5. Evidence Metamodel with the following:
7.5. Precise statements related to evidence
In the simplest form, evidence consists of a collection of documents or records that provide evidentiary
support to a set of claims. These claims are called subject claims, as the are made by an argument related to
some selected subject area. Subject claims are different from evidence claims, which are the assertions
about the evidence items that help establish the exact nature of the evidentiary support they provide to the
subject claims in a clear, comprehensive and defensible way. Evidence claims can be reused as opposed to
subject claims and arguments, which are specific to each subject area for which an assurance case is
developed. Thus the SACM Evidence Metamodel defines the evidence vocabulary for constructing precise
statements related to evidence. Evidence vocabulary is reused in every argument for various diverse subject
areas.
The Evidence Metamodel defines an interchange format for evidence (XSD schema defined through the
application of XMI rules defined by MOF and XMI specifications) in which each evidence element,
including claims about evidence, is represented by a specific XML tags. The evidence interchange format is
then utilized to exchange bodies of evidence related to specific projects that require argumentation, for
example, in presenting an assurance case. describing evidence-related efforts, including
Collection of evidence
Management of evidence
Interpretation of evidence
Evaluation of evidence
Collection of Evidence includes activities of identifying evidence items, and recording various information
about them, including their origin, timing and custody. Evidence Metamodel defines precise statements
related to the pedigree of an evidence item, including evidence collection method or tool used.
The primary items of evidence are Documents, Records, Assertions and Objects. Documents may have
Properties that are characteristics independent of an assurance case being developed.
Properties in the Evidence Metamodel include the following:
Fundamental characteristics of Documents, for example
Media of document
Language of document
Security classification of document
Quality of Documents, for example
Primary or secondary document
Original or derived document
Consistency
Completeness
Accuracy
Management of Evidence compliments evidence collection activities with some planning and tracking
activities. Important to the management of evidence is the set of Project Elements, including an Evidence
Container, for grouping evidence items and assertions, as well as several elements for planning
management collection Activities, including their dependencies, objectives, input and output data, and the
evidence requests, which are the placeholders for evidence items that are being planned to be obtained.
Combined with the evidence events, provenance, custody and timing clauses, these project elements are
powerful enough to support management of evidence-related efforts and interchange of the relevant
managerial data as part of evidence packages.
Provenance of Evidence Elements, for example
Who created
Who approved
Who owns
Custody of Evidence Elements, for example
Where the element was aquired
Where the element is located
Who is the custodian of the element
Timing of Evidence Elements, for example
When the element was created or acquired
Effective Time of an assertion
Interpretation of Evidence includes activities of assigning meaning to documents (what a document is,
what claims does it make, etc). Interpretation of evidence is an important step in legal community, when a
physical object is submitted as evidence.
The following assertions are made to establish the meaning of evidence items.
Meaning of Documents, for example
Definition
Meaning
Scope
Characteristics
Evaluation of Evidence includes the activities of making certain assertions about evidence items and their
relation to subject claims.
Evidence Assertions are defined within the Evidence Metamodel and include the following categories: Quality Attributes of Evidentiary Support
Direct or indirect
Relevance
Confidence
Strength
Significance
Nature of the Evidentiary support
Supports
Challenges
Observations and Resolutions
The entire evidence package needs to be evaluated
Relations between Evidence Items need to satisfy one of the well-defined “Standards of proof,” such as
Clean and Convincing Evidence (CCE)
Preponderance of evidence (POE)
Resolved Counter Evidence (RCE), often used in the field of Genealogy as the Genealogical Proof
Standard
Beyond the reasonable doubt (BRD)
The following diagram is related to the so-called Resolved Counter Evidence Proof Standard, which
illustrates the steps involved in evaluating evidence.
Remove section 7.8 Evaluation of Evidence
Remove section 7.9. Design Characteristics of the Evidence Metamodel
Replace introductory text to Part 3, page 33, with the following:
This part of the Strucutred Assurance Case Metamodel defines the normative SACM Evidence Metamodel.
SACM Evidence Metamodel consists of 18 class diagrams. SACM Evidence Metamodel is delivered as a
single UML subpackage ‘Evidence’ of SACM.
The SACM Evidence Metamodel consists of the following logical parts:
Evidence Items
Formal Elements
Evidence Assertions
Administration
The Evidence Items part defines the physical evidence, provided in the form of documents, records and
sometimes other material exhibits. The Formal Elements part defines the logical assertions, provided in
the form of individual propositions. These propositions use an external vocabulary related to the subject
area for which an argument is being provided. The Formal Elements part defines a subset of an OMG
Semantics of Business Vocabularies and Business Rules (SBVR) fact model in the form of atomic
formulations based on fact types with role bindings to individual concepts. SBVR is not used directly
because of the semantic differences between fact models in linguistic models as they are defined in SBVR,
conceptual models and “asserted fact models” involved in evidence collection and evaluation. Formal
Elements represent a conceptual model underlying the entire assurance case. Evidence Assertions part
defines various statements that can be made about the evidence items, such as documents, records and
exhibits, and their relations to the subject area claims. Evidence Assertions includes statements that are
related to various esential properties of evidence items. A large group of statements are the so-called
evidence evaluations, including assertions of the evidentiary support (relations between evidence items and
the subject area claims), assertions related to the interpretation of physical evidence and document,
assertions about the conflicts in evidenctiay support and resolutions of these conflicts. Other statements are
assertions related to provenance, custody and timing of the evidence items and evidence evaluations. The
last group of statements qualify the evidentiary support that evidence items confer on the subject area
claims. The Administration part defines an EvidenceContainer element which organizes individual
evidence items and evaluations into a package that becomes a unit of exchange. The Administrative part
also provides several means for managing evidence collection projects.
Remove Figure 10.1 in Part 3 (page 33)

we need a common route to support instance packaging. Proposal is to use “Assurance
repository” as the main packaging element.

Add Figure Administration to chapter 8 SACM Assurance Case as follows: << diagram on p 117 of ptc/2012-06-04>> Add section Administration
This section describes the common elements of SACM that are involved in managing
assurance cases, exchanging assurance cases and related concerns. The elements
described in this chapter organize instances of SACM. In particular, this section defines
the root object of an assurance case - the AssuranceCase element. This element contains
other objects in the assurance case, such as the Argumentation objects and
EvidenceContainer objects and constitutes a unit of exchange using the SACM as the
protocol.
In addition, the SACM Argumentation Metamodel and the SACM Evidence Metamodel
constitute two independent protocols within SACM, so Argumentation packages can be
developed and exchanged using the Argumentation elements, and also the
EvidenceContainers can be developed, managed and exchanged independently of the
Argumentation elements or in combination with them. Independently developed
Argumentation packages and EvidenceContainer packages can be later assembled into
complete assurance cases. Specifications of the Evidence Metamodel can be used to
develop an evidence repository that can be used to store and manage evidence in support
of multiple assurance cases.
Add sub section AssuranceCase
AssuranceCase
AssuranceCase element Superclass
ModelElement
Attributes
name:String the name of the assurance case
gid:String the globally unique identifier assigned to the current assurance case
Associations
argument:Argumentation::Argumentation[0..*] the argument component of the assurance
case
evidence:Evidence::EvidenceContainer[0..*] the evidence component of the assurance
case
Semantics
An AssuranceCase element represents assurance cases as defined in ISO/IEC 15206.
Argument and Evidence components of an AssuranceCase are optional which allows
representing incomplete assurance cases.
An AssuranceCase element involves both a globally unique "gid" and a locally unique
"id". The global referencing scheme may involve gid+id combination, while a local
scheme may use id component.

Using the term 'Argument' as the container for the "Claims-Argument-Evidence" aspect of ARM is confusing as people expect to see Claim first.

Heading -> Rename to “Argumentation Class”
Para 1, 2nd word -> rename to “Argumentation”
Associations section -> rename association “containsArgumentLink” into
containsArgumentation" The nested Argumentation contained in a given instance of an
Argumentation.
Semantics section, first sentence -> delete “and ArgumentLinks between
ArgumentElements”
Semantics section add after 1st sentence: "Argumentation elements can be nested."
Section 9.2.9 Claim Class
First para, first sentence -> change “structured Argument.” to “structured
Argumentation”
Edit section 9.2.8. CitationElement as follows:
change the 1st sentence from " The CitationElement Class cites an Argument, or an
ArgumentElement within another Argument, for use within an Argument"
into
The CitationElement Class cites an Argumentation, or an ArgumentElement within
another Argumentation, for use within the current Argumentation.
in subsection Associations change 'refersToArgument:Argument[0..1] into
"refersToArgumentation:Argumentation[0..*] References to Argumentation.
change 'refersToArgumentElement;ArgumentElement[0..1] into
"refersToArgumentElement:ArgumnetElement[0..*]
Replace Argumentation Metamodel diagram Figure 9.1 according to the new Figure 9.1
in related resolution 17347 that addresses other model improvements. change the semantics subsection from:
Within an Argument (package) it can be useful to be able to cite elements of an
Argument (i.e., ArgumentElements) to act as explicit proxies for those elements acting
within the argument structure. For example, in supporting a Claim it may be useful to
cite a Claim or InformationElement declared within another Argument. It can also be
useful to be able to cite entire Arguments. For example, in supporting a Claim it may be
useful to cite an existing (structured) Argument.
into
Within an Argumentation (package) it can be useful to be able to cite elements of an
Argumentation (i.e., ArgumentElements) to act as explicit proxies for those elements
acting within the argumentation structure. For example, in supporting a Claim it may be
useful to cite a Claim or InformationElement declared within another Argumentation. It
can also be useful to be able to cite entire Argumentationss. For example, in supporting a
Claim it may be useful to cite an existing (structured) Argumentation.

Some of the evidence evaluation attributes were allowed to be applied to exhibit, rather than the relation between exhibit and evidence assertion

Action - text describing Accuracy subclass to be improved to make it clear it is on the
link.
This issue has been resolved due to resolutions of related issues 16730 and 168737.
Disposition: Merged

Lack of agreement in the attribute types for some of the evidence evaluation subtypes - e.g. confidence 0..100 as integer

In diagram "EvidenceAttributes" add concrete class "ExtendedEvidenceAttribute" and
make it a subclass of the abstract class EvidenceAttribute.
In section Evidence Attributes Class Diagram replace Figure EvidenceAttributes Class
Diagram with the following: <<diagram on p 112 of ptc/2012-06-04>> After subsection "Strength" in the section Evidence Attributes Class Diagram add the
following subsection describing the new element:
"
ExtendedEvidenceAttribute
ExtendedEvidenceAttribute element represents a user-defined characteristic of the
evidence relations that is asserted during the course of evaluation.
Superclass
EvidenceAttribute
Constraints
• ExtendedEvidenceAttribute element shall own at least one TaggedValue
describing the meaning of the element.
Semantics
ExtendedEvidenceAttribute is a user-defined characteristic. Its meaning is represented by
the key-value pair of the corresponding TaggedValue element.
ExtendedEvidenceAttribute characteristic can not be verbalized using the standard
vocabulary of the Structured Assurance Case Metamodel. However, the key and value
pair may be carefully named to result in meaningful verbalizations for the targeted
community in the selected language. In diagram "DocumentAttributes" add concrete class "ExtendedDocumentAttribute" and
make it a subclass of the abstract class DocumentAttribute.
In section Document Attributes Class Diagram replace Figure DocumentAttributes Class
Diagram with the following: << diagram on p 113 of ptc/2012-06-04>> After subsection "ReliabilityLevel (enumeration)" in the section Document Attributes
Class Diagram add the following subsection describing the new element:
"
ExtendedDocumentAttribute
ExtendedDocumentAttribute element represents a user-defined characteristic of a
document that is asserted during the course of evaluation.
Superclass
DocumentAttribute
Constraints
• ExtendedDocumentAttribute element shall own at least one TaggedValue
describing the meaning of the element.
Semantics
ExtendedDocumentAttribute is a user-defined characteristic. Its meaning is represented
by the key-value pair of the corresponding TaggedValue element.
ExtendedDocumentAttribute characteristic can not be verbalized using the standard
vocabulary of the Structured Assurance Case Metamodel. However, the key and value
pair may be carefully named to result in meaningful verbalizations for the targeted
community in the selected language.
"

Need a revised compliance point approach. Suggestion is that there is a compliance point
such that existing tool vendors can claim compliance. Perhaps other complicance points. This
would be of interest to OMG/ISO.

replace the entire section 2. Conformance with the following:
2. Conformance
Structured Assurance Case Metamodel (SACM) specification defines the following 3 compliance points:
Argumentation
Evidence Container
Assurance Case
2.1. Argumentation compliance point
Software that conforms to the SACM specification at the Argumentation 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 the Argumentation subpackage of the SACM
specification, including the common elements defined in the Common and Predefined diagrams of the
SACM. The top object of the Argumentation package as a unit of interchange shall be the
Argumentation::Argumentation element of the SACM.
Conformance to the Argumentation compliance point does not entail support for the Evidence subpackage
of SACM, or the Administration diagram of the SACM. Links to the evidence items in the Argumentation::InformationElement shall be made using the ‘url’ attribute. The ‘evidence’ association
shall not be used.
This compliance point facilitates interchange of the structured argumentation documents produced by
existing tools supporting The Goal Structuring Notation (GSN) and Claims-Arguments-Evidence (CAE)
notation. Examples of the SACM XML interchange documents and the corresponding GSN and CAE
diagrams are provided in Annex B.
2.2. Evidence Container compliance point
Software that conforms to the specification at the Evidence Container 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 Evidence subpackage of the SACM specification,
including the common elements defined in the Common and Predefined diagrams of the SACM. The top
object of the Evidence package as a unit of interchange shall be the Evidence::EvidenceContainer element
of the SACM.
Conformance to the Evidence compliance point does not entail support for the Argumentation subpackage
of SACM, or the Administration diagram of the SACM. Claims in the Evidence::ReferencedClaim element
shall be explicitly defined using the ‘content’ attribute of the Evidence::ReferencedClaim element. The
‘claim’ association shall not be used.
This compliance point facilitates interchange of the precise statements related to evidence. In particular,
this compliance point facilitates development of evidence repositories in support of software assurance and
regulatory compliance.
2.3. Assurance Case compliance point
Software that conforms to the specification at the Assurance Case 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 Assurance Case
package as a unit of interchange shall be the SACM::AssuranceCase element.

exchanged model instances should indicate which compliance points have been satisfied

This is achieved by observing the top element. See related resolution 16855.
Disposition: Closed, no change

The detailed enumerated attributes in SAEM need a corresponding location in SACM.
Choosing to use these could be defined using a seperate compliance point.

The SACM Evidence Metamodel provides a comprehensive vocabulary for constructing and interchanging
precise statements related to evidence. Detailed enumeration attributes contribute to the precision of the
interchange. Without them semantic interoperability and reasonable automation processing of the
interchanged content is hard to achieve. Related resolutions are 16845, 16737 and 16857.

If AssertedRelationships are genuinely Assertions then they should be subtypes of Assertion

Related issue: 16852 (id=145)
The agreed resolution is that asserted relationships to be moved to be a sub class of
assertion, and to remove abstract class “ArgumentLink”. Update the text to reflect that
the “toBeSupported” attribute attaches to the Claim class (as shown in the diagram).
This issue is resolved as part of the accumulated model changes addressed by 17347.
Disposition: Merged

No AssuranceCase Element in either ARM or SAEM - necessary for a Structured Assurance Case Metamodel

This issue has been resolved due to resolutions of related issues 16855.
Disposition: Merged

Metamodel packaging should broadly align with ARM/SAEM elements. Will support
understandability

The discussion details are as follows:
Modularity of the specification itself provides this modularity
The corresponding resolutions are provided in resolutions to issue 16836.
Disposition: Merged

Combined specification should have routes and guidance broadly corresponding
to ARM and SAEM, and supports ease of adoption for ARM.

This resolution has been merged with 16857.
Disposition: Merged

counter evidence and challenge should be better modelled by a polarity attribute on the relation (AB comment)

No Data Available

The argument metamodel has some limitations that should be addressed to
make it more coherent and simple. The following aspects need to be
addressed:

1. The annotation class is generally useful and should be promoted up
the class diagram so it can be used more widely

2. AssertedRelationships seem to be kinds of assertions (see related
issue 16848) and so a number of related modelling updates will be needed
to reorganise the model to reflect this, and to simplify by removing or
renaming some of the abstract classes. An abstract Assertion class could
be a useful common parent for both Claim and AssertedRelationship
Classes. A simplification can be made then to rename the existing
ArgumentLink as AssertedRelationship.

3. We should have a simple referencing mechanism to allow referencing
evidence in the evidence metamodel, or to reference other evidence by
means of a URL directly (for when the user is only choosing to comply
with the Argument compliance point)

4. As the models are integrated it will be necessary to rename the top
level element in ARM to be less generic

I propose the following changes:

Create a new Assertion class, as a subclass of ReasoningElement

Set the Claim class to be a subclass of Assertion

Rename the ArgumentLink abstract to be AssertedRelationship (removing
the previous abstract class AssertedRelationship) and move the new
AssertedRelationship class to be a child of the Assertion class

Move the Annotation Class to a shared top level ModelElement, and
include a content:String attribute

Add an optional association from InformationElement to
Evidence::EvidenceItem and add an attribute URL to InformationElement to
be used to refer to evidence not held in the evidence model.

Rename the ModelElement to be ArgumentationElement, and move the
id:String attribute to its new parent ModelElement, which is part of the
shared classes for the argumentation and evidence parts of SACM.

Rename 9.2.1 to “ArgumentationElement class (Abstract)”
Delete paragraph 1 of 9.2.1 and replace with:
“An ArgumentationElement is the top level element of the hierarchy for argumentation
elements”
In the Attributes section:
delete the “identifier: String” attribute
delete the text under “description: String”, and replace with “A description of the
Argumentation entity”
delete the text under “content: String”, and replace with “Supporting content for the
Argumentation entity”
delete the “Associations” heading and its content
change the text of the “Semantics” section to be “The ArgumentationElement is a
common class for all elements within a structured argument”
delete the Invariants section
Delete all of section 9.2.18 (Annotates Class)
Delete all of Section 9.2.5 (ArgumentLink Class (Abstract))
Insert a new Section 9.2.5 as follows:
“Assertion Class (Abstract)
Assertions are used to record the propositions of Argumentation (including both the
Claims about the subject of the argument and structure of the Argumentation being
asserted). Propositions can be true or false, but cannot be true and false simultaneously.
Superclass
ReasoningElement
Semantics
Structured arguments are declared by stating claims, citing evidence and contextual
information, and asserting how these elements relate to each other.
“
Edit section 9.2.6 ReasoningElement Class (Abstract) as follows: First sentence, change “namely Claims and ArgumentReasoning” to “Assertions and
ArgumentReasoning”
Delete Attributes section and its content.
Delete the content of the “semantics” section, and replace with “The core of any
argument is the reasoning that exists to connect assertions of that argument. Reasoning is
captured in SACM through the linking of fundamental claims and the description of the
relationships between the claims. ReasoningElements represent these two elements.”
Edit section 9.2.7 InformationElement Class as follows:
Add an “attributes” section with the following content:
url : string
An attribute recording a URL to external evidence
Add a new sentence at the end of the Semantics section as follows:
“The url attribute is only to be used when only the argumentation aspects of SACM are
complied with. If compliance is claimed against both the argumentation and evidence
packages, then an association to Evidence::EvidenceItem shall be used to reference
evidence by means of a URL”
Add an "associations:" section with the following content:
evidence:Evidence::EvidenceItem[0..*]
The EvidenceItems referenced by the current InformationElement object.
Edit Section 9.2.9 Claim Class as follows
Superclass section > Delete “ReasoningElement”, insert “Assertion” Attributes section>
add “toBeSupported: Boolean An attribute recording whether further reasoning has yet to
be provided to support the Claim (e.g. further evidence to be cited).”
Semantics section, first para -> Delete first sentence (begins “Structured arguments are
declared…”)
Semantics section, 2nd para-> delete “reasoning (in the recorded Argument)”, insert
“argumentation”
Semantics section: add 3rd para: “A Claim that is intentionally declared as requiring
further evidence or argumentation can be denoted by setting toBeSupported to be true. “
Add new “Invariant” Section with the content “Self.assumed and self.toBeSupported
cannot both be true simultaneously”
Edit 9.2.12 AssertedRelationship Class (Abstract) as follows
Superclass section -> delete “ArgumentLink”, insert “Assertion”
Insert new “Associations” section after “Superclass” section, with the following content:
Associations
source:ArgumentElement[0..*] Reference to the ArgumentElement(s) that are the
source (start-point) of the relationship.
target:ArgumentElement[0..*] Reference to the ArgumentElement(s) that are the
target (end-point) of the relationship.
Semantics section, delete first sentence, replace with “In SACM, the structure of an
argument is declared through the linking together of primitive ArgumentElements.”
Edit section 9.2.13 AssertedInferenceClass as follows:
Delete first para, replace with “The AssertedInference association class records the
inference that a user declares to exist between one or more Assertion (premises) and another Assertion (conclusion). An assertion may be the target in more than one
AssertedInference. It is important to note that such a declaration is itself an assertion on
behalf of the user.”
Semantics section, delete existing content, replace with “The core structure of an
argument is declared through the inferences that are asserted to exist between Assertions
(e.g. Claims). For example, an AssertedInference can be said to exist between two claims
(“Claim A implies Claim B”). An AssertedInference 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.”
Change title of 9.1 from 'Overview' into 'Argumentation Class Diagram'
Replace Figure 9.1 with the following new figure <<figure on p 125 of ptc/2012-06-04>>

Currently the Evidence metamodel has a general class Exhibit, and one concrete class Document. However the feedback from Regulatory Compliance community is that there should be an explicit element to represent electronic records of compliance.
Suggested resolution is to add Record element as a concrete subclass of Exhibit. Resolutions in Ballot 5 are addressing the issue of moving the DocumentProperties up the inheritance chain so that these Properties are available for Records.
This is a minor semantic enhancement that will allow better differentiation between various exhibits, and will allow management of electronic records for compliance.

Add section Record to chapter 10 as follows:
Record
Record element represents Exhibits that are explicit records of compliance, for example
log entries. Record is different from a Document, since a Document element represents
some physical object that exists elsewhere in the physical world (even if it is an
electronic document), while a Record element exists directly in the EvidenceContainer.
Superclass
EvidenceElement
Attributes
name:String the name of the record
content:String the content of the record
Semantics
Record is defined as "a thing constituting a piece of evidence about the past, esp. an
account of an act or occurrence kept in writing or some other permanent form". In the
Evidence Metamodel Record element is such thing. In contrast to a Document element, a
Record is not a representative of some other physical object, but the object itself. A
Record is therefore similar to an Object, however it is considered a structured element
with an informal content rather than a formal element.
Changes to Figure EvidenceElements (Figure 10.1) were illustrated in related resolutions
(e.g. 16800) and is presented below. <<diagram on p 121 of ptc/2012-06-04>>

Need to provide motivation (the underlying issue) for new “link group”. Question of why
not just use annotation/tagging to convey alternatives. We should make architectural changes
unless strong warrant to do so.

This issue is related to a now obsolete intermediate model of ARM and is not longer
applicable.
Disposition: Closed, no change

Question of how to characterize the identity of the “artifact-as-such”, as well as
its URN. May need a “name” attribute for the “source” class (Issue raised). Perhaps defer or
explain usage in the document?

This issue is a duplicate of 16515; a resolution is provided by 17347. SACM uses a URL in both the
Argumentation Metamodel as well as in the Evidence Metamodel. Evidence Metamodel also includes a
name. Annotations can be used to provide further clarifications. There is also a gid+id mechanism, so each
organization can use a unique reference schema for their exhibits and artifacts.
Disposition: Closed, no change

he subsection Evidence Evaluation Example in chapter 6 Overview includes a Figure; the Beta-1 document has a wrong figure. Correct figure from the adopted specification must be used.

Replace Figure in section 7.5.1 with the following:
Change text on page 11 from 'Genealogical Proof Standard' into 'Resolved Counter
Evidence (RCE), often used in the field of Genealogy as the Genealogical Proof
Standard'.
Change text on page 11 from 'the so-called Genealogical Proof Standard" into "the socalled
Resolved Counter Evidence Proof Standard"

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

This resolution has been merged with 16857.
Disposition: Merged

Need to clarify usage of “nature of dependency” to indicate this is not for evidential or argumentation relations

This issue is to some extent a duplicate of 16512. However, the updated Argumentation Metamodel does
not have nature of dependency attribute any more. Some clarifications were added to the Evidence
Metamodel as resolution to 16512. No further changes are required.
Disposition: Closed, no change

(a missing issue) to motivate link groups

This issue has been raised against an intermediate version of the Argumentation Metamodel; the element in
question has been since removed and is not part of the final version.
Disposition: Closed, no change

This issue was raised by Sam Redwine on April 16th 2012 in a message to Luke and Nick

Argumentation metamodel:
ArgumentReasoning should also attach to AssertedChallange

In ArgumentReasoning class (previously 9.2.11), delete the first paragraph and replace with the following:
“ArgumentReasoning can be used to provide additional description or explanation of the asserted inference
or challenge that connect one or more Claims (premises) to another Claim (conclusion).
ArgumentReasoning elements are therefore related to AssertedInferences and AssertedChallenges. It is also
possible that ArgumentReasoning elements can refer to other structured Arguments as a means of
documenting the detail of the argument that establishes the asserted inferences. “
In the Associations subsection, add the following:
describedChallenge:AssertedChallenge[0..*]
Reference to the AssertedChallenge being described by the ArgumentReasoning.
Replace figure 9.1 with the following << figure on p 127 of ptc/2012-06-04>>

The frontispiece sections (introduction, background, scope etc) needs to be edited to
reflect integration. Suggest to break an issue for each sections.

Page 2-3 remove text starting from section 1.3 Why Software Assurance Evidence ? and ending with
phrase "demonstrated through the development of assurance cases".

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

Rejected - keep as ARM
Disposition: Closed, no change

Integration Issue: Combined scope needs to include original scopes, and any emergent scope

The summary of this issue does not give any further details, so the intention of the issue remains rather
vague. Additional details are provided as follows:
part 1 deals with the minimal new issues of assurance case containment part 2 is same
scope as ARM part 3 is same scope as SAEM.
The corresponding resolutions will be provided in resolutions to the issue 16836.
Disposition: Merged

Integration issue: An overall goal is to integrate the ARM and SAEM specifications into SACM in a coherent way.

Add new section Common Elements Class Diagram to chapter 8 SACM Assurance Case
Add Common Elements diagram as follows: <<diagram on p 106 of ptc/2012-06-04 >> Add SACMElement section
SACMElement
A SACM element is a top-level element for the Structure Assurance Case Metamodel.
This is an abstract class that directly extends MOF::Element. Every class in SACM is a
(direct or indirect) subclass of SACMElement.
Superclass
MOF::Element
Semantics
The SACMElement is a common class for all meta-model elements that represent some
element of a structured assurance case.
Remove ModelElement section 9.2.1, page 23
Add ModelElement section to chapter 8 in the following way:
ModelElement Class (Abstract)
A ModelElement is an atomic constituent of a structured assurance case represented
using the Structured Assurance Case Metamodel. In the meta-model, ModelElement is the top meta-element in the SACM Common class hierarchy. ModelElement is an
abstract meta-model element.
Attributes
• id: String A unique identifier for the SACM entity.
Associations
taggedValue:TaggedValue[0..*] This association enables the association of one or more
user defined TaggedValues to any ModelElement.
annotation:Annotation[0..*] user defined annotations associated with the current element
Semantics
The ModelElement is a common class for all meta-model elements that represent some
element of a structured assurance case.
Invariants
• context ModelElement inv UniqueIdentifier: ModelElement.allInstances()->
select(me:ModelElement|me.identifier=self.identifier)->size()= 1
Add UtilityElement section to chapter 8 in the following way:
UtilityElement Class (Abstract)
A UtilityElement is an atomic constituent of a structured assurance case represented
using the Structured Assurance Case Metamodel. In contrast to a ModelElement,
UtiiltyElement represents auxiliary constructs that extend ModelElement and that are
only used as part of some ModelElement. In particular, such UtilityElement cannot be
referenced outside of the owner ModelElement. UtilityElement is an abstract class.
Semantics
The UtilityElement is a common class for all meta-model elements that represent some
auxiliary element of a structured assurance case.
Move TaggedValue section 9.2.2, page 24 to chapter 8
Change superclass of TaggedValue to UtilityElement
Change sentence in the description of TaggedValue element as follows:
A TaggedValue is a structured annotation that can be provided on any ModelElement in
the Structured Assurance Case Metamodel.
Change sentence in semantics section from:
This is a deliberately general mechanism to allow users to associate tags that they find
useful for any Argumentation Metamodel instance.
into
This is a deliberately general mechanism to allow users to associate tags that they find
useful for any Structure Assurance Case Metamodel object.
Add Annotation section to chapter 8.
"
Annotation
An Annotation element represents informal and unstructured user-defined content to any
ModelElement of the Structure Assurance Case Metamodel. In contrast, a TaggedValue
element allows more structured content to be added to elements.
Superclass UtilityElement
Attributes
content:String the text of the annotation
Semantics
It can be useful to be able to add informal text to the ModelElements. For example,
Annotation elements can record comments, notes and general explanations. This is a
deliberately general mechanism to allow users to associate annotations that they find
useful for any Structure Assurance Case Metamodel object.
"
Modifications to the Argumentation Metamodel and the Evidence Metamodel parts are
described in related resolutions. In particular, we are adding a reference from
Argumentation::InformationElement to Evidence::EvidenceItem and from
Evidence::ReferencedClaim to Argumentation::Claim

Incorporate 12.5.1 EvidenceRequest (p82) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Administrative Element in support of a collection of evidence
items. Any connection to the SACM common classes is accomplished through the element's superclass. No
other changes to this element are anticipated according to the selected level of the integration.
Disposition: Closed, no change

Incorporate 12.4.4 HasRoleIn (p81) in a coherent way into merged SACM metamodel

The superclass of this element is changed to ProjectProperty due to renaming from AdministrativeProperty
(see resolution 16818). Otherwise, this is a useful leaf class representing a statement related to managing
and evaluating evidence in evidence collection projects. No change is required.
Disposition: Closed, no change

Incorporate 12.3.2 Service (p79) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Administrative Element in support of a collection of evidence
items. Any connection to the SACM common classes is accomplished through the element's superclass.
No other change is anticipated.
Disposition: Closed, no change

Incorporate 12.3.1 CollectionMethod (abstract) (p78) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Administrative Element in support of a collection of evidence
items. Any connection to the SACM common classes is accomplished through the element's superclass.
No other change is anticipated.
Disposition: Closed, no change

Incorporate 12.4.1 Originator (abstract) (p80) in a coherent way into merged SACM metamodel

No Data Available

Incorporate 12.3.4 Tool (p79) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Administrative Element in support of a collection of evidence
items. Any connection to the SACM common classes is accomplished through the element's superclass.
No other change is anticipated.
Disposition: Closed, no change

Incorporate 12.2.6 DependsOn (p77) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to the administrative elements that
describe evidence collection and evidence evaluation projects. Any connection to the SACM common
classes is accomplished through the element's superclass. No other changes to this element are anticipated
according to the selected level of the integration.
Disposition: Closed, no change

Incorporate 12.4.3 Organization (p81) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Administrative Element in support of a collection of evidence
items. Any connection to the SACM common classes is accomplished through the element's superclass. No
other change is anticipated.
Disposition: Closed, no change

Incorporate 12.4.2 Person (p80) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Administrative Element in support of a collection of evidence
items. Any connection to the SACM common classes is accomplished through the element's superclass.
No other change is anticipated.
Disposition: Closed, no change

Incorporate 12.3.3 Method (p79) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Administrative Element in support of a collection of evidence
items. Any connection to the SACM common classes is accomplished through the element's superclass.
No other change is anticipated.
Disposition: Closed, no change

Incorporate 12.1.3 StandardOfProof (enumeration) (p73) in a coherent way into merged SACM metamodel

Section 15.13. StandardOfProof (enumeration) page 93 add and attribute:
"
RCE
Resolved Counter Evidence Proof Standard
"
in the Semantics section on page 93 change text "Genealogical Proof Standard (GPS) to
'Resolved Counter Evidence Proof Standard (RCE)".

Incorporate 12.1.2 Package (p72) in a coherent way into merged SACM metamodel

Change text page 91 from
Administration package defines key framework elements that determine patterns for
constructing representations of evidence information.
into
This chapter describes the elements of the SACM Evidence Metamodel that are involved
in managing evidence, exchanging units of evidence and related concerns. The elements
described in this chapter organize instances on Evidence Metamodel, which can be
referred to as an Evidence Model. In particular, this chapter defines the root object of
Evidence Models - the EvidenceContainer. This element contains other objects in an
evidence project and constitutes a unit of exchange using the Evidence Metamodel as the
protocol.
Rename section 15.1.2 Package into 15.1.2. EvidenceContainer
Change text pages 92-93 from
Package element is the root element that owns EvidenceItem, EvidenceEvaluation
elements, as well as other auxiliary elements related to the processes of evidence
identification, collection, interpretation, evaluation, and management.
Superclass
AdministrativeElement
Attributes • consistency:ConsistencyLevel Globally unique identifier of a SACM evidence
element.
• version:String version of the package.
• criteria:StandardOfProof Standard of Proof used for evaluation of evidence.
• completeness:CompletenessLevel Level of completeness of the evidence package.
Association
• :requiresPackage[0..*] List of other evidence packages that are required by this
package.
• item:EvidenceItem[0..*] List of evidence items.
• evaluation:EvidenceEvaluation[0..*] List of evaluations.
• method:CollectionMethod[0..*] List of evidence collections methods, including
tools.
• originator:Originator[0..*] List of personnel and organizations involves in
evidence collection project.
• request:Request[0..*] List of evidence collection requests.
• activity:Activity[0..*] List of project activities.
• objective:ProjectObjective[0..*] List of project objectives.
Constraints
• Package shall not be the object of the requiresPackage relation owned by the
Package, either directly or indirectly through requiresPackage of other Packages.
• Any Package that is the object of the requiresPackage relation shall be available
for exchange.
• [Completeness of the package with respect to required packages] Any Element
that is referenced by any of the Element that defined in the package (i.e., that are
members of the lists item, evaluation, method, originator, request, activity, and objective
of the Package) shall be also defined in the Package or in one of the Package that are
referred to as objects of the requiresPackage relation either directly or indirectly. An
Element is referenced if it is an object of an EvidenceProperty or an EvidenceEvaluation.
• EvidenceProperty, EvidenceEvaluation, EvidenceRequest, EvidenceAction,
ProjectObjective elements shall not be referenced across packages.
Semantics
Package element is the root element of an Evidence Model. A single Package is a unit of
exchange. All Element defined in Package are exchanged together as part of the Package.
Elements that are referenced shall be either present in the Package or in one of the
Package that is specified as required for the Package. The Evidence Metamodel does not
require completeness of the closure of all required packages.
into
EvidenceContainer element is the root object of the SACM Evidence Metamodel
instances. This object owns EvidenceItem, and EvidenceEvaluation elements, as well as
other ProjectElement related to the processes of evidence identification, collection,
interpretation, evaluation, and management.
Superclass
EvidenceElement
Attributes
• name:String name of the EvidenceContainer.
• gid:String Globally unique identifier of the EvidenceContainer. • version:String version of the EvidenceContainer.
Association
• item:EvidenceItem[0..*] List of evidence items.
• evaluation:EvidenceEvaluation[0..*] List of evaluations.
• element:ProjectElement[0..*] List project elements (objectives, activities,
requests, methods, stakeholders).
• property:ProjectProperty[0..*] List of project property clauses.
Constraints
• EvidenceContainer shall not be the object of the requiresContainer relation owned
by the EvidenceContainer, either directly or indirectly through requiresContainer of other
EvidenceContainers.
• Any EvidenceContainer that is the object of the requiresContaienr relation shall
be available for exchange.
• [Completeness of the evidence container with respect to required evidence
containers] Any Element that is referenced by any of the Element defined in the package
(i.e., that are members of the lists item, evaluation, or element of the EvidenceContainer)
shall be also defined in the EvidenceContaienr or in one of the EvidenceContainers that
are referred to as objects of the requiresContaienr relation either directly or indirectly. An
Element is referenced if it is an object of an EvidenceProperty or an EvidenceEvaluation.
• EvidenceProperty, EvidenceEvaluation, EvidenceRequest, EvidenceAction,
ProjectObjective elements shall not be referenced across evidence containers.
Semantics
EvidencePackage element is the root object of an instance of the Evidence Metamodel
(which can be referred to as Evidence Model). A single EvidenceContainer is a unit of
exchange of evidence information. All Element defined in an EvidenceContainer are
exchanged together as part of the EvidenceContainer. Elements that are referenced shall
be either present in the EvidenceContainer or in one of the EvidenceContaienrs that is
specified as required for the EvidenceContainer. The Evidence Metamodel does not
require completeness of the closure of all required packages.
The properties of the EvidenceContainer element make assertions regarding the current
container (use the current container as the subject of the corresponding clauses).
Therefore, the following properties for an EvidenceContainer can be readily interpreted
in the above way:
RequiresContainer (for example, verbalized as "the EvidenceContainer requires container
X1")
ContainerConsistency (for example, verbalized as "the elements of the
EvidenceContainer are interpreted formally")
ContainerCompleteness (for example, verbalized as" the EvidenceContainer is in draft
state")
CompliesTo (for example, verbalized as "The EvidenceContainer complies to the
Resolved Counter Evidence proof standard")
All ProjectProperties clauses directly owned by an EvidenceContainer shall be
interpreted with the EvidenceContainer as the main subject. For example, "The
EvidenceContainer depends on evidentiary support rendered by exhibit E1 to the claim
'testing is completed'"
Replace Figure 15.1 with the following (see also resolution 16815): <<figure on p 99 of ptc/2012-06-04>> Add section ProjectProperties to chapter 15 (see also resolution 16818).
Move section 15.1.3 StandardOfProof (enumeration) to the new section
Move section RequiresPackage to the new section.
Rename section RequiresPackage into RequiresContainer
Change section RequiresContainer to the following:
RequiresContainer is an owned property of EvidenceContainer element. This element
represents a statement asserting that the subject EvidenceContainer requires another
evidence container for the resolution of some references.
Superclass
ProjectProperty
Associations

• container:EvidenceContainer[1]
  EvidenceContainer that is required for the resolutions of soem references in the
  subject evidence contaienr
  Constraints
• RequiresContainer element shall not be owned by any ProjectElement object
  -subject EvidenceContainer shall no be the 'container' of the requiresContainer
  relation, either directly or indirectly,
  Semantics
  RequiresContainer property represents a state of affairs that the subject
  EvidenceContainer requires another evidence container for the resolution of some
  references. This property contributes to the completeness constraint of the
  EvidenceContainer. This is a commitment to the set of evidence containers that need to
  be processed together. Add section ContainerConsistency as follows:
  ContainerConsistency ContainerConsistency element is a counterpart of the Consistency property of Documents.
  ContainerConsistency clause makes an assertion about the subject EvidenceContainer
  regarding the level of formality of the element of the container. In combination with other
  container properties, such as ContainerCompleteness and CompliesTo, this clause
  determines capability to interpret the elements of this container. Consistency of an
  EvidenceContainer can be informal, semiformal and formal.
  Superclass
  ProjectProperty
  Attributes
  value:ConsistencyLevel
  asserted Consistency level of the elements of the EvidenceContainer, such as informal,
  semi-formal, and formal.
  Add section ContainerCompleteness as follows:
  ContainerCompleteness
  ContainerCompleteness element is a counterpart of the Completeness property of Documents.
  ContainerCompleteness clause makes an assertion about the subject EvidenceContainer
  regarding the level of completeness of the element of the container. In combination with
  other container properties, such as ContainerConsistency and CompliesTo, this clause
  determines capability to interpret the elements of this container. Completeness of an
  EvidenceContainer can be incomplete, draft, final and obsolete.
  Superclass
  ProjectProperty
  Attributes
  value:CompletenessLevel
  asserted Completeness level of the elements of the EvidenceContainer, such as
  incomplete, draft, final and obsolete.
  Add section CompliesTo as follows:
  CompliesTo
  CompliesTo clause makes an assertion about the subject EvidenceContainer regarding the
  standard of proof used for the evaluation of evidence in the EvidenceContainer. In
  combination with other container properties, such as ContainerConsistency and
  ContainerCompleteness, this clause determines capability to interpret the elements of this
  container. Completeness of an EvidenceContainer can be incomplete, draft, final and
  obsolete.
  Attributes
  criteria:StandardOfProof Standard of Proof used for evaluation of evidence in the subject
  container.
  Add section ExtendedProjectProperty as follows:
  ExtendedProjectProperty
  ExtendedProjectProperty element represents a user-defined characteristic documents that
  is asserted during the course of evaluation for the project elements in the subject
  container.
  Superclass ProjectProperty
  Constraints
  • ExtendedProjectProperty element shall own at least one TaggedValue informally
  describing the meaning of the element.
  Semantics
  ExtendedProjectProperty is a user-defined characteristic. Its meaning is represented by
  the key-value pair of the corresponding TaggedValue element.
  ExtendedProjectProperty characteristic can not be verbalized using the standard
  vocabulary of the Structured Assurance Case Metamodel. However, the key and value
  pair may be carefully named to result in meaningful verbalizations for the targeted
  community in the selected language.
  Replace Figure 15.2 ProjectProperties (shows as part of 16818) as follows: <<diagram on p 101 of ptc/2012-06-04>>

Incorporate 12.1.1 AdministrativeElement (abstract) (p71) in a coherent way into merged SACM metamodel

Change text 15.1.1 AdministrativeElment (abstract), page 91 into 15.1.1 ProjectElment (abstract)
Change definition of the AdministrativeElement section 15.1.1, page 91 from
AdministrativeElement is an abstract class representing non-essential elements of the
Evidence Metamodel that assist in managing evidence collection, interpretation,
evaluation, and exchange processes.
into
ProjectElement represents the auxiliary elements of the Evidence Metamodel that are
involved in the statements related to managing evidence collection, interpretation,
evaluation, and exchange processes.
Change superclass of AdministrativeElement to 'EvidenceElement' (page 91)
Remove text from Attributes of the AdministrativeElement on page 91:
id:String Globally unique identifier of a SACM evidence element.
Add text to Attributes of the AdministrativeElement on page 91:
name:String Name of the ProjectElment.
content:String The statement in a selected language that is the description of the content
of the element
Add Associations subsection of the AdministrativeElement on page 91:
Associations
property:ProjectProperty[0..*] properties of the Project Element - zero or more
predicates to the main clause in which the current element is the subject)
Add to semantics of the ProjectElement the following:
The properties of a ProjectElement make assertions regarding the current element (use
the current element as the subject of the corresponding clauses). Therefore, the following
properties for a ProjectElement can be readily interpreted in the above way:
DependsOn when a subject element is an Activity (for example, verbalized as " Activity
A2 depends on Activity A1")
HasRoleIn when the subject element is a Stakeholder (for example, verbalized as " Bob is
the president of the organization SupplierCorporation")
Satisfies when a subject element is an Activity (for example, verbalized as" Activity A2
satisfies project objective Perform Search")
All ProjectProperties clauses directly owned by a ProjectElement shall be interpreted
with the ProjectElement as the main subject. For example, "Person Researcher depends
on activity Perform Search and satisfies project objective Find evidence"
Add class ProjectElement to Figure 10.1 EvidenceElements
Replace Figure 10.1 with the following (this also contains resolution to several related
issues ). <<diagrams on p 94 of ptc/2012-06-04>> Rename 15.2 ProjectActivities Class Diagram into
15.2 ProjectElements Class Diagram
Change text on page 94 from
ProjectActivities Class Diagram defines Activity AdministrativeElement and its owned
properties. Activity element facilitates management of evidence collection and evaluation
processes.
into
ProjectElements Class Diagram defines several auxiliary elements that are used in
various statements as predicate clauses for some main clause in which the subject is some
evidence element. The elements defined at this class diagram are collectively referred to
as the project elements. They are required to express various evidence statements related
to evidence collection, evaluation and evidence management.
Move sections 15.3.1. CollectionMethod (abstract), 15.3.2 Service, 15.3.3 Method, 15.3.4
Tool into the section 15.2 ProjectElements Class Diagram.
Move sections 15.4.1. Originator (asbtract), 15.4.2. Person, 15.4.3 Organization into the
section 15.2 ProjectElements Class Diagram.
Move section 15.5.1. EvidenceRequest into the section 15.2 ProjectElements Class
Diagram.
change superclass of EvidenceRequest to ProjectElement
remove association 'provenance' of EvidenceRequest.
Create class diagram ProjectElements based on Figure 15.2 and former ProjectActivities
diagram.
Change superclass of CollectionMethod (section 15.3.1 page 98) to ProjectElement
Change superclass of Originator (section 15.4.1 page 100) to ProjectElement Remove section 15.3 Methods (see also related resolution 16818)
Remove section 15.4 Originators (see also related resolution 16818)
Remove section 15.5 Request class diagram.

Incorporate 11.7.1 EvidenceGroup (p69) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Item related to management of evidence items as well as
representing subjects of evidence assertions involved in the evaluations of evidence items and the
justification support they provide. Any connection to the SACM common classes is accomplished through
the element's superclass. No other changes to this element are anticipated according to the selected level of
the integration.
Disposition: Closed, no change

Incorporate 12.1.4 AdministrativeProperty (abstract) (p74) in a coherent way into merged SACM metamodel

Rename section 15.1.4 AdministrativeProperty (abstract) into ProjectProperty (abstract) (page 92)
Change definition of AdministrativeProperty from
AdminstrativeProperty is an abstract class that represents owned properties of
AdminstrativeElement. This class is added to enhance the readability of the model.
into
ProjectProperty represents statements related to the structure of ProjectElement. These
statements are predicate clauses where the main clause describes some project element.
The subject of the ProjectProperty clause is a ProjectElement.
Rename superclass of ProjectProperty to EvidenceProperty
Add class ProjectProperty to EvidenceAssertions class diagram
Change semantics from
Defined by concrete subsclasses
into
Defined by concrete subclasses
Add section ProjectProperties Class Diagram
move section 15.1.4 ProjectProperty (abstract) to the new section
Add Figure ProjectProperties Class Diagram <<diagram on p 103 of ptc/2012-06-04>> Move section 15.4.4 HasRoleIn to the new section
change superclass of HasRoleIn from EvidenceProperty to ProjectProperty
add Constraints section as follow:

• ProjectElement shall not be affiliated with self, either directly or indirectly
  Remove class RequiresTool (the corresponding section is missing in the document, so it
  does not need to be removed)
  Move section 15.2.6. DependsOn to the new section change superclass of the DependsOn to ProjectProperty (page 97)
  Change text on page 97 from
  DependsOn element represents a relationship between the owner Activity element and
  another Activity element that is identified as the activity attribute of the DependsOn
  element.
  into
  DependsOn element represents a relationship between the owner project element and
  another project element that is identified as the element attribute of the DependsOn
  element. DependsOn element is a clause where the main subject is the ProjectElement
  that owns the current element. For example, this clause can be used to specify
  dependencies between Activities in an evidence collection project.
  Change associations from
  activity:Activity[1] Activity that the current activity depends on.
  into
  element:ProjectElement[1] Project element that the subject element depends on.
  Change semantics section from
  DependsOn element represents a state of affairs that the owner Activity is associated with
  another Activity identified as the activity attribute of the DependsOn element.
  into
  DependsOn element represents a state of affairs that the subject project element depends
  on another project element identified as the 'element' attribute of the DependsOn
  element.
  In Constraints subsection, change text 'Activity' into "ProjectElement'.
  Remove class isAssociatedWith and the corresponding section 15.2.5, page 97
  Remove class RequiresMethod and the corresponding section 15.2.4 page 97
  Move section 15.2.3. Satisfies, page 96 to the new section
  Change the superclass of the Satisfies element to ProjectProperty
  Change the associations from
  objective:ProjectObjective[1] Project objective that is satisfied by the activity.
  into
  element:ProjectElement[1] Project element that is satisfied by the current element.
  Change text from
  Satisfies element represents a relationship between the owner Activity element and a
  ProjectObjective object that is identified as the objective attribute of the Satisfies
  element.
  into
  Satisfies element represents a relationship between the owner project element and another
  project element that is identified as the element attribute of the Satisfies element. The
  Satisfies element is a clause where the main subject is the ProjectElement that owns the
  current element. For example, this clause can be used to specify that a certain Activity
  satisfies a certain ProjectObjective in an evidence collection project.
  Change associations of Satisfies into
  element:ProjectElement[1] Project element (such as a ProjectObjective) that is satisfied
  by the subject project element
  Change the semantics subsection from Satisfies element represents a state of affairs that the owner Activity object satisfies the
  ProjectObjective identified as the objective attribute of the ProjectObjective element.
  into
  Satisfies element represents a state of affairs that the owner project element satisfies
  another ProjectElement (such as a ProjectObjective) identified as the 'element' attribute of
  the Satisfies element.
  Other changes to the ProjectProperties Class Diagram are described in the related
  resolution 16816 (EvidenceContainer)

Incorporate 11.6.2 Negates (p67) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
support provided by a certain evidence item. Any connection to the SACM common classes is
accomplished through the element's superclass. No other changes to this element are anticipated according
to the selected level of the integration.
Disposition: Closed, no change

Incorporate 11.6.1 EvidenceResolution (abstract) (p66) in a coherent way into merged SACM metamodel

Change text at in the section 14.6.1 page 86 from
EvidenceResolution is an abstract class that asserts resolution to conflicts between two
domain assertions either directly or through refuting some domain assertion or negating
some evidence relations.
into
EvidenceResolution represent statements that assert resolution to the conflict between
two evidence assertions either directly or indirectly by refuting some evidence assertion
or negating some evidence relation.
Remove EvidenceContext class from EvidenceResolutions class diagram Figure 14.6
Add EvidenceElement class to EvidenceResolutions class Diagram Figure 14.6; add an association from
EvidenceResolution class to EvidenceElement class with rolename of EvidenceItem named 'subject' and
multiplicity of 1.
Remove Rationale class from EvidenceResolutions class diagram Figure 14.6
Change associations of EvidenceResolution from
context:EvidenceGroup[0..1] The set of evidence element that provides the context for
the resolution.
rationale:Rationale[1] The rationale for the resolution (prose).
into
subject:EvidenceElement[1] The subject evidence element for the resolution, i.e. the
evidence element that negates, resolves or refutes other evidence elements
Replace Figure 14.6 with the following: << diagram on p 92 of ptc/2012-06-04

Incorporate 11.6.4 Resolves (p68) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
support provided by a certain evidence item. Any connection to the SACM common classes is
accomplished through the element's superclass. No other changes to this element are anticipated according
to the selected level of the integration.
Disposition: Closed, no change

Incorporate 11.6.3 Refutes (p67) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
support provided by a certain evidence item. Any connection to the SACM common classes is
accomplished through the element's superclass. No other changes to this element are anticipated according
to the selected level of the integration.
Disposition: Closed, no change

Incorporate 12.2.2 ActivityProperty (abstract) (p76) in a coherent way into merged SACM metamodel

This is an abstract class representing Evidence Assertions related to project Activity elements. Any
connection to the SACM common classes is accomplished through the element's superclass. No other
changes to this element are anticipated according to the selected level of the integration.
Disposition: Closed, no change

Incorporate 12.2.1 Activity (p75) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Administrative Element in support of a collection of evidence
items. Any connection to the SACM common classes is accomplished through the element's superclass.
No other change is anticipated.
Disposition: Closed, no change

Incorporate 12.1.5 RequiresPackage (p74) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to a property of an evidence container.
In particular, this assertion allows to specify dependencies between evidence containers. Any connection to
the SACM common classes is accomplished through the element's superclass. No other changes to this
element are anticipated according to the selected level of the integration.
Disposition: Closed, no change

Incorporate 12.2.3 Satisfies (p76) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to evaluation of the administrative
elements that describe evidence collection and evidence evaluation projects. Any connection to the SACM
common classes is accomplished through the element's superclass. No other changes to this element are
anticipated according to the selected level of the integration.
Disposition: Closed, no change

Incorporate 11.5.5 Amplifies (p65) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
support provided by a certain evidence item. Any connection to the SACM common classes is
accomplished through the element's superclass. No other changes to this element are anticipated according
to the selected level of the integration.
Disposition: Closed, no change

Incorporate 9.2.1 FormalObject (abstract) (p33) in a coherent way into merged SACM metamodel

All references are against document ptc/2012-04-04
Delete entire section 12.2.1 FormalObject (abstract)
Remove class FormalObject from Figure 12.2; rename class DomainObject to FormalObject (see resolution
16734); change superclass of Object to FormalObject (see resolution 16753); change superclass of
UnknownSubject to FormalObject (see resolution 16754).
Add element ObjectifiedAssertion (after section 12.2.2 Object)
ObjectifiedAssertion represents an objectified assertion, i.e. an assertion that implicitly
defines an object that is used in another assertion.
Superclass
FormalObject
Associations
assertion:FormalAssertion Link to the FormalAssertion being objectified
Semantics
From the formal logic perspective, SACM distinguishes objects from assertions. As a
consequence, in order to represent a formal assertion about other assertions the later must
be objectified, i.e. represented as a FormalObject that refers to the objectification of the
original assertion using the element ObjectifiedAssertion.
At Figure 14.4 change class Object into FormalElement
Change description of 'IsA' statement on page 81 into
IsA statement represents a fundamental relation between one EvidenceElement and one
FormalElement which defines the general concept for the subject EvidenceElement. The
actual concept can be given by reference to an external formal vocabulary or ontology.
The following statements are examples of IsA statements:
• “This metric is a McCabe’s Cyclomatic Complexity Metric.”
• “This report is a penetration testing report.”
Superclass EvidenceInterpretation
Associations
• definition:FormalElement[1] The FormalElement that is the general concept of
the subject of the relation.
Constraints
• The subject of the IsA relation shall not be its definition.
Semantics
The IsA element asserts a state of affairs that the EvidenceElement, identified as the
subject element of the IsScopedBy element, has a general concept represented by the
FormalElement that is identified as the definition of the IsA element. The FormalElement
can be either a FormalObject or a FormalAssertion.
This characteristic is verbalized as follows: “EvidenceElement is a FormalElement.”
Change description of IsScopedBy (pages 82-83) into:
IsScopedBy statement represents a relation between one EvidenceElement and one
FormalElement that defines the scope of the subject EvidenceElement. The actual
concept can be given by reference to an external formal vocabulary or ontology. The
following statements are example of IsScopedBy: “This metric is scoped by the client
subsystem.”
Superclass
EvidenceInterpretation
Associations
• scope:FormalElement[1] The FormalElement that is the scope of the subject of
the relation.
Constraints
• The subject of the IsScopedBy relation shall not be its scope.
Semantics
“Scope” is defined as the area covered by a given activity or subject, which can be
interpreted in either physical or logical sense. The IsScopedBy element asserts a state of
affairs that the EvidenceElement, identified as the 'subject' of the IsScopedBy element, is
delimited by the FormalElement that is identified as the 'scope' of the IsScopedBy
element. The FormalElement may represent an individual concept, an abstract concept or
an assertion.
This characteristic is verbalized as follows: “EvidenceElement is scoped by
FormalElement.”
Change the rolename of the FormalAssertion association end of the IsCharacterizedBy
statement on page 82 from:
property:DomainAssertion[1] The DomainAssertion that is the property of the subject
EvidenceElement.
into
assertion:DomainAssertion[1] The DomainAssertion that characterizes the subject
EvidenceElement.
Change text on page 82 from
The IsCharacterizedBy element asserts a state of affairs that the EvidenceElement,
identified as the element of the MeansThat element, is characterized by a proposition, in which the subject is bound to one of the role, and which is represented by the Object that
is identified as the property of the IsCharacterizedBy element.
into
The IsCharacterizedBy statement asserts a state of affairs that the EvidenceElement,
identified as the subject of the IsCharacterizedBy element, is characterized by an
assertion, in which the subject is bound to one of the roles, and which is represented by
the FormalAssertion that is identified as the 'assertion' property of the IsCharacterizedBy
element.
Change the text in the Semantics subsection of the MeansThat element, section 14.4.3,
page 81 from:
The MeansThat element asserts a state of affairs that the EvidenceElement, identified as
the element of the MeansThat element, has meaning represented by the Object that is
identified as the meaning of the MeansThat element. This characteristic is verbalized as
follows: “EvidenceElement means that DomainAssertion.”
into
The MeansThat element asserts a state of affairs that the EvidenceElement, identified as
the 'subject' of the MeansThat element, has meaning represented by the FormalAsserion
that is identified as the' meaning' of the MeansThat element. This characteristic is
verbalized as follows: “EvidenceElement means that FormalAssertion is true.”
Change Figure 14.4 EvidenceInterpretation as follows: <<diagram on p 77 of ptc/2012-06-04

Incorporate 9.1.3 RoleBinding (p31) in a coherent way into merged SACM metamodel

All references are against document ptc/2012-04-04
Change superclass of the RoleBinding element (page 51) into 'SACM:UtilityElement'
Change Figure 12.1 Formal Assertions Class Diagram

Incorporate 9.1.2 DomainClaim (p 31) in a coherent way into merged SACM metamodel

All references are against document ptc/2012-04-04
Rename section 12.1.2. DomainClaim into ReferencedClaim
Change text on page 51 from
DomainClaim is an element of meaning which represents an informal proposition about
the state of affairs in the domain about which the assurance case is developed.
Superclass
DomainAssertion
Semantics
DomainClaim is an element of meaning that states a generic proposition about the
assurance case domain. DomainClaim is an informal element that represents claim as
prose in a natural language (formal or informal), without identifying its structure.
DomainClaim element can represent informal claims (claims not linked to any formal
definition of its meaning, such as an ontology developed by some community of
meaning) or unstructured claims (where the subjects are not identified).
Usually claims state existence of a formally defined relationship between several
individual domain objects and involve several subjects bound to specific roles. Assertion
element can be used to capture this structure of a claim in a more formal way. In
particular, Assertion element can link the proposition to an external vocabulary or
ontology that defines the exact meaning of the proposition, as well as the exact subjects
of the proposition.
into
ReferencedClaim is an element of meaning that represents an informal assertion about the
state of affairs in the subject area about which the assurance case is developed.
ReferencedClaim can be linked to a Claim element of the Argumentation part of the
assurance case.
Superclass
FormalAssertion
Associations claim:Argumentation::Claim [0..1] Claim element in the Argumentation part of the
assurance case
Semantics
ReferencedClaim is an element of meaning that states an assertion about a subject area of
the assurance case. ReferencedClaim represents the claim as prose in a selected natural
language (formal or informal), without identifying its structure. ReferencedClaim
element can represent informal claims (claims not linked to any formal definition of its
meaning, such as an ontology developed by some community of meaning) or
unstructured claims (where the subjects are not identified).
Usually claims assert existence of a formally defined relationship between several
individual subjects and involve several objects bound to specific roles. An Assertion
element can be used to capture this structure of a claim in a more formal way. In
particular, the Assertion element can link the proposition to an external vocabulary or
ontology that defines the exact meaning of the proposition, as well as the exact subjects
of the proposition.
Change text on page 39 from
DomainClaim subclass represents an informal assertion.
into
ReferencedClaim subclass represents an informal assertion.
Rename element DomainClaim at Figure 12.1, page 50
Change text on page 51 from
For informal assurance cases, a DomainClaim element can be used, which only contains
the verbalization of the claim in a natural language.
into
For semi-formal and informal assurance cases, a ReferencedClaim element can be used,
which only contains the verbalization of the claim in a natural language.
Change text on page 69 from
The Evidence Relations Class Diagram focuses at the evidence relations between
EvidenceItem, such as Exhibit and DomainAssertion, such as DomainClaim.
into
The Evidence Relations Class Diagram focuses at the evidence relations between
EvidenceItem, such as Exhibit and Assertion or ReferencedClaim
Change text on page 70 from
The EvidenceItem object, such as an Exhibit or a Document that has evidentiary relations
to a DomainAssertion object such as a DomainClaim.
into
The EvidenceItem object, such as an Exhibit or a Document that has evidentiary relations
to a FormalAssertion object such as an Assertion or a ReferencedClaim.
Change text on page 81 from
Alternatively an informal DomainClaim can be used.
into
Alternatively an informal ReferencedClaim can be used.
Change the entry in Annex A, page 108 from 'DomainClaim' into 'ReferencedClaim'
Change text in Annex A, page 108 from
based on Software Assurance Evidence Metamodel (10.1.2) [‘DomainClaim’] into
based on Software Assurance Evidence Metamodel (10.1.2) [‘ReferencedClaim’]

Incorporate 9.1.1 Assertion (p30) in a coherent way into merged SACM metamodel

All references are against document ptc/2012-04-04
Change the description of the Assertion element, section 12.1.1, pages 50-51 into:
An Assertion is a relationship involving one or more formal objects, taken as formal
proposition that has a distinct, separate existence, a self-contained piece of information
that can be referenced as a unit. Assertion is the key constituent of a conceptual model
underlying the assurance case. Assertion represents an asserted fact about the subject area
for which the assurance case is being developed.
Superclass
FormalAssertio
Attributes
• facctype:String Designation of the fact type
Associations
• role:RoleBinding[0..*] Set of role bindings that further describe which
DomainObject are bound to the roles that are determined by the fact type.
• definition:MOF::Element A link to an entry of an external SBVR vocabulary or
an OWL ontology defining the fact type of the assertion.
Semantics
Assertion is an element of meaning that states existence of a relationship between several
individual formal objects. In a formal assurance case, the nature of the relationship is
specified through a reference to an external vocabulary, such as an SBVR vocabulary or
an OWL ontology. SACM assumes that the community of interest for the assurance case
will acquire or develop such vocabularies for the corresponding subject area. In a semiformal
assurance case the nature of the relationship can be described informally through a
'content' property. In this case the 'definition' property and the 'facttype' property shall not
be used. However the references to the exact FormalObjects through RoleBinding
elements can be still stated. The 'content' property of the FormalAssertion element
provides the verbalization of the assertion, in the form of an expression of the assertion in a selected natural language. For informal assurance cases, a ReferencedClaim element
can be used, which only contains the verbalization of the claim in a natural language.

Incorporate 9.2.3 UnknownSubject (p34) in a coherent way into merged SACM metamodel

All references are against document ptc/2012-04-04
Rename section 12.2.3 UnknownSubject (page 54) into UnknownObject
Change text on page 54 from
UnknownSubject represents an unknown individual, existence of which is however is
determined by the pattern of relationships in the fact model, and that is involved in
assertions constituting the conceptual model underlying the assurance case.
Superclass
FormalObject
Semantics
UnknownSubject is an element of meaning. UnknownSubject shall be used in fact model
underlying the assurance case to represent unknown subjects of assertions, in particular
when more than one assertion refers to the same subject.
into
UnknownObject represents an unknown individual, existence of which is however is
determined by the pattern of relationships in formal statements, and that is involved in
assertions constituting the conceptual model underlying the assurance case.
Superclass
FormalObject
Semantics
UnknownObject is an element of meaning. UnknownObject shall be used in the
conceptual model underlying the assurance case to represent unknown subjects of
assertions, in particular when more than one assertion refers to the same subject. An
UnknownObject is not linked to an external noun concept definition (as opposed to an
Object element).
Rename class UnknownSubject on Figure 12.2 into UnknownObject

Incorporate 9.2.2 Object (p33) in a coherent way into merged SACM metamodel

All references are against document ptc/2012-04-04
Add to definition of Object (pages 53-54):
Attributes
concept:String Designation of the noun concept
Associations
definition:MOF::Element A link to an entry in an external SBVR vocabulary or an
OWL vocabulary defining the noun concept of the object.

Incorporate 8.1.12 IsReleasableTo (p28) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
connection to the SACM common classes is accomplished through the element's superclass. No other
change is anticipated.
Disposition: Closed, no change

Incorporate 8.1.11 HasSecurityClassification (p28) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
connection to the SACM common classes is accomplished through the element's superclass. No other
change is anticipated.
Disposition: Closed, no change

Incorporate 8.1.10 HasVersion (p27) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
connection to the SACM common classes is accomplished through the element's superclass. No other
change is anticipated.
Disposition: Closed, no change

Incorporate 8.1.9 IsExpressedInLanguage (p26) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
connection to the SACM common classes is accomplished through the element's superclass. No other
change is anticipated.
Disposition: Closed, no change

Incorporate 9.2.4 CompositeSubject (p34) in a coherent way into merged SACM metamodel

All references are against document ptc/2012-04-04
Rename section 12.2.4 CompositeSubject into CompositeObject (page 54)
Change text 'CompositeSubject' into 'CompositeObject' in section 12.2.4
Rename class CompositeSubject into CompositeObject on Figure 12.2
change the rolename of the CompositeObject in containment association to
FormalElement into 'composite' at Figure 12.1

Incorporate 8.1.6 HasMedia (p25) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
connection to the SACM common classes is accomplished through the element's superclass. No other
change is anticipated.
Disposition: Closed, no change

Incorporate 8.1.8 IsBasedOn (p26) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
connection to the SACM common classes is accomplished through the element's superclass. No other
change is anticipated.
Disposition: Closed, no change

The ARM approach to the description of elements seems better: use an attribute called “content” in an abstract class to contain the “prose” description, and allow this attribute to be inherited by sub-classes.

No Data Available

It is not clear why the EvidenceEvaluation relationship types “weakens” and “amplifies” are themselves between Evidence relations.

Change text in section 14.5.3, page 84 from
For example, one may assert that the evidence that support the claim that “Bob is married
to Alice” weakens the claim that “Bob is single” (see weakens element). These
dependencies help further evaluation of evidence.
into
For example, let's assume the following evidentiary relationships:
Exhibit A supports claim "Bob is married to Alice"
Exhibit A challenges claim "Bob is single"
We can observe that the claim "Bob is married to Alice" conflicts with the claim "Bob is
single"
Let's further assume the following evidentiary relationship:
Exhibit C supports claim Exhibit A is likely a forgery
We can observe that
The evidence assertion Exhibit C supports claim "Exhibit A is likely a forgery" weakens
support given by the Exhibit A to the claim "Bob is married to Alice"
at the same time we do not directly assert that
Exhibit C challenges the claim "Bob is married to Alice"
Evidence observations help capture dependencies between related claims and thus
facilitate evaluation of evidence.
Change text in section 14.5.4, page 85 from
Weakens element asserts that one EvidenceRelation-1 element weakens another
EvidenceRelation-2 element. This has a different meaning that the statement that any
evidence supporting DomainAssertion-1 that is the assertion of EvidenceRelation-1,
challenges the DomainAssertion-2 that is the assertion of the EvidenceRelation-2.
Weakens relation may imply a conflict between DomainAssertion-1 and
DomainAssertion-2. In that case evidence in support of DomainAssertion-1 is not
relevant to DomainAssertion-2. For example, one may assert that the evidence that
support the claim that “Bob is married to Alice” weakens the claim that “Bob is single.”
Weakens dependencies help further evaluation of evidence.
into
Weakens element asserts that the subject EvidenceRelation weakens another
EvidenceRelation2. This statement has a different meaning than a statement about
existence of an evidence item that (directly) challenges the FormalAssertion that is
involved in the EvidenceRelation2. Weakens relation may imply a conflict between the
subject FormalAssertion that is involved in the subject EvidenceRelation and FornalAssertion2. In that case the evidence in support of the subject FormalAssertion is
not relevant to FormalAssertion2.
change text in the Semantics subsection from:
The Weakens element asserts a state of affairs that the EvidenceRelation-1, identified as
relation1 of the Weakens element, weakens EvidenceRelation-2 that is identified as
relation2 of the Weakens element.
into
The Weakens element asserts a state of affairs that the EvidenceRelation-1, identified as
the 'subject' of the Weakens element, weakens EvidenceRelation-2 that is identified as the
'relation' of the Weakens element. The Weakens statement asserts a negative contribution
made by one EvidenceEvaluation to another EvidenceEvaluation.
Change text on page 85 from:
This characteristic is verbalized as follows: “Evidentiary support to DomainAssertion-1
weakens evidentiary support to DomainAssertion-2”
into
This characteristic is verbalized as follows: “Evidentiary support to the subject
FormalAssertion weakens evidentiary support to FormalAssertion-2”, where "Evidentiary
support to a FormalAssertion C1" is an objectified assertion that there is an evidence
item E1 that supports the FormalAssertion C1.
Change text section 14.5.5, page 85 from
Amplifies element asserts that one EvidenceRelation-1 element amplifies another
EvidenceRelation-2 element. This has a different meaning that the statement that any
evidence supporting DomainAssertion-1 that is the assertion of EvidenceRelation-1,
supports the DomainAssertion-2 that is the assertion of the EvidenceRelation-2.
Amplifies relation may imply a coupling between DomainAssertion-1 and
DomainAssertion-2. In that case evidence in support of DomainAssertion-1 may be
relevant to DomainAssertion-2. For example, one may assert that the evidence that
support the claim that “Bob is married to Alice” amplifies the claim that “Bob is not
single.” Amplifies dependencies help further evaluation of evidence.
into
Amplifies element asserts that the subject EvidenceRelation amplifies another
EvidenceRelation2. This statement has a different meaning than the statement about
existence of an evidence item that (directly) supports the FormalAssertion that is
involved in the EvidenceRelation2. Amplifies relation may imply a coupling between
subject FormalAssertion and the FormalAssertion2. In that case evidence in support of
the subject FormalAssertion may be relevant to the FormalAssertion2.
Change text in the Semantics subsection from "The Amplifies statement represents a
negative contribution made by one EvidenceEvaluation to another EvidenceEvaluation."
into
The Amplifies statement asserts a positive contribution made by one EvidenceEvaluation
to another EvidenceEvaluation."
Change text on page 86 from This characteristic is verbalized as follows: “Evidentiary support to DomainAssertion-1
amplifies evidentiary support to DomainAssertion-2”
into
This element can be verbalized as follows: “Evidentiary support to the subject
FormalAssertion amplifies evidentiary support to FormalAssertion-2”

The use of a “content” attribute is suggested for the “stmt” attribute. See comment 5.

All references are against document ptc/2012-04-04
Change the description of the 'stmt' attribute for class FormalAssertion (used to be
DomainAssertion but is being renamed as the result of the resolution to related issue
16735), on page 39 from
• stmt:String The statement that is the expression of the domain assertion
(verbalization of the statement in a natural language).
into
• content:String The statement in a selected language that is the expression of the
formal assertion (verbalization of the assertion in a natural language). Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
DomainAssertion but is being renamed as the result of the resolution to related issue
16735), Figure 10.1, page 35
Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
DomainAssertion but is being renamed as the result of the resolution to related issue
16735), Figure 14.4, page 80
Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
DomainAssertion but is being renamed as the result of the resolution to related issue
16735), Figure 12.1, page 50
Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
DomainAssertion but is being renamed as the result of the resolution to related issue
16735), Figure 14.1, page 69
Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
DomainAssertion but is being renamed as the result of the resolution to related issue
16735), Figure 14.5, page 83
Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
DomainAssertion but is being renamed as the result of the resolution to related issue
16735), Figure 14.6, page 86
Change text on page 51 from
In a semi-formal assurance case the nature of the relationship can be described informally
through a stmt property.
into
In a semi-formal assurance case the nature of the relationship can be described informally
through a 'content' property.
Change Reference schema for Domain Assertion on page 106 from
Reference schema: stmt of Domain Assertion
into
Reference schema: content of Formal Assertion

To stipulate the structure of the id of an element is over-constraining. If the URL of the organisation is important to capture, then there should be a separate attribute for it; the name of the SAEM class is surely redundant. It should be sufficient to state that, whatever the identifiers used, they are to be globally unique, and let the implementers solve the problem how they will.

Add to the semantics of ModelElement:
id of the model element shall be unique in the corresponding package (AssuranceCase,
Argumentation or EvidenceContainer). Integration of multiple packages into a larger
package, for example, adding Argumentation and EvidenceContainer to an
AssuranceCase shall not affect the uniqueness of ids of all the objects involved.
Add to the semantics of AssuranceCase:
AssuranceCase shall have a globally unique gid attribute.
Constraints
gid is a string that has the following structure: unique url of the organization that created the assurance case
the text 'AssuranceCase'
a unique number
For each contained object of the assurance case the gid+id identifier is globally unique,
i.e., no two elements of the same type produced by the same organization shall have the
same number.
Add to the semantics of EvidenceContainer:
EvidenceContainer shall have a globally unique gid attribute.
Constraints
gid is a string that has the following structure:
unique url of the organization that created the evidence container
the text 'EvidenceContainer'
the unique number
For each contained object the gid+id identifier is globally unique, i.e., no two evidence
elements of the same type produced by the same organization shall have the same
number.

Page 1, section 1.2, 2nd paragraph:
This sentence is representative of the systemic grammatical errors that pervade the document, which centre mainly around missing definite and indefinite articles. The sentence should perhaps read: “The level of confidence that a given software system is trustworthy is called Software Assurance (SwA) and the process that establishes the level of confidence is called SwA process.” (Italics indicate inserted words.)

Page 20-21, sections 9.1 and 9.1.1:
The paragraph stating “The most common form of an exhibit ...” is repeated in these two sections. In general, there is a considerable amount of repeated text in the document, usually between the descriptions and the semantics.

The paragraphs, mentioned in the text of the issue have been removed. Several typos have been corrected in
the process of providing resolutions to other issues.
Disposition: Closed, no change

Rather than trying to enumerate all the possible properties that evidence could possess, it may be better to consider a extensible mechanism such as the TaggedValue class in ARM. This principle would simplify the model considerably if applied to all such properties, by the time Provenance, TimingProperty, CustodyProperty, EvidenceProperty and DocumentProperty sub-classes have been taken into account. Detailed enumerations such as these are bound to be incomplete; user defined values are more flexible.

This has been already resolved through related issues 16730, 16731, 16736, 16773,
16740, 16756, 16760 and 16845 to the extent consistent with the intent of the Evidence
Metamodel to provide a structured an well-defined (interoperable) way of constructing
and exchanging statements related to evidence.
Disposition: Duplicate

Since, as stated under Constraints, an exhibit shall not have more than one electronic source, then this could be made into an attribute of the Exhibit class rather than an association.

The intent of the Evidence Metamodel is to provide more structured ways of constructing
statements related to evidence. One of the goals is to facilitate normalized representation
of such statements as well as the mapping of such statements to RDF triples. Therefore, a
uniform mechanism was selected, which involves using an explicit association class
technique, where the extra association class directly corresponds to a verb in the evidence
statement. The above suggestion does not satisfy these objectives.
Disposition: Closed, no change

Assuming that a document has only one medium (which is likely, otherwise there would be two exhibits), then the model would be simplified by making “medium” an attribute of a Document.

This issue was raised during the review of the Evidence metamodel by Integrate.
Reject - current situation allows optionality (And is more fact oriented the current way).
The modeling style of the Evidence metamodel uses MOF in a disciplined way which facilitates a more
straightforward mapping to RDF triples and to SBVR statements. In particular, the modeling style of the
Evidence Metamodel introduces explicit "attribute association classes" named with verbs or verb phrases
when an attribute of an entities is modeled. Shortcutting this pattern using "natural modeling style" breaks
this pattern and makes RDF mapping more complicated.
Disposition: Closed, no change

The class DocumentAttribute does not seem to be described in the standard

All references are against document ptc/2012-04-04
remove class DocumentAttribute from EvidenceElements diagram (Figure 10.1, see
resolution 16729 and related)
move sections 14.3.1-14.3.8 from DocumentAttributes section 14.3 from chapter 14 to
chapter 11 to the bottom of section 11.2 and delete the rest of section 14.3
rename class DocumentAttribute into DocumentProperty (new section 11.2)
delete entire Associations subsection from Document section.
Change text of 1st para of section DocumentProperty into:
"This class defines characteristics of documents. Other characteristics common to all
Exhibits are defined using ExhibitProperty.".
change superclass of DocumentProperty to ExhibitProperty (new section 11.2)
add DocumentPropertyClass to EvidenceAssertions diagram (see resolution 16730)
move classes HasVersion,
IsExpressedInLanguage, IsReleaseableTo, HasSecurityClassification from class diagram
Exhibits to class diagram DocumentProperties (new section 11.2)
move sections 11.1.10, 11.1.9, 11.1.12, 11.1.11 from section 11.1 into the new section
11.2 remove the ShortTitle attribute from the attribute subsection of the Document element
(page 42, 11.1.2)
rename class ExtendedDocumentAttribute into ExtendedDocumentProperty
Change text in section ExtendedDocumentAttribute (introduced as part of resolution to
16845 as follows:
Change text "ExtendedDocumentAttribute" into "ExtendedDocumentProperty" (5
occurences)
Change superclass of ExtendedDocumentProperty (former ExtendedDocumentAttribute)
to DocumentProperty
Change Figure 14.3 Document Attributes Class Diagram as follows:
Modifications to this diagram accumulate resolution 16845

The class “IsPartOf” is an example of an instance in the standard where a class is used to represent a relationship where a simple UML association would do. The concept is that an Exhibit can be part of other Exhibits. This is most naturally expressed as an “isPartOf” association that has Exhibit as its source and target. Introducing a class for this relationship clutters the model.

This issue was raised during the review of the Evidence metamodel by Integrate.
Reject - current situation is fact oriented (aligns with SBVR). The modeling style of the
Evidence metamodel uses MOF in a disciplined way which facilitates a more straightforward mapping to
RDF triples and to SBVR statements. In particular, the modeling style of the Evidence Metamodel
introduces explicit "association classes" named with verbs or verb phrases when a relation between two
entities is modeled. Shortcutting this pattern using "natural modeling style" breaks this pattern and makes
RDF mapping more complicated.
Disposition: Closed, no change

Can assertions not be deleted, if not revoked?

The common resolution is provided under issue 16845.
Disposition: Merged

This state transition diagram could be simplified by amalgamating the two main states at either end of the “re-evaluated” transition. Note that the transitions “transferred”, “evaluated” and “revoked” have analogous behaviour on these two states. Similarly in Figure 3.

see pages 36 - 37 of ptc/2012-06-04

The description of Object starts with the class name FormalObject, which is probably a copying error.

All references are against document ptc/2012-04-04
Change text on page 53 from
FormalObject represents a known individual that can be involved in assertions
constituting the conceptual model underlying the assurance case.
into
Object element represents a known individual that can be involved in assertions
constituting the conceptual model underlying the assurance case (formal statements).

The phrase “an individual” without qualification usually refers to a person, which is not intended here. This should be stated as “an individual fact” or “an individual concept

change 'individual' to 'object' in 12.2.3, page 54
change 'individuals' to 'objects' in 12.2.4 page 54
change 'individual' to 'object' in 12.2.1, page 53
change 'individual' to 'object' in 12.2.2, page 53

Incorporate 11.4.1 EvidenceInterpretation (abstract) (p60) in a coherent way into merged SACM metamodel

Change rolename of the EvidenceElement in section 14.4.1, page 81, from: element:EvidenceElement[1]
into
subject:EvidenceElement[1]
Change rolename of EvidenceElement from 'element' into 'subject' on Figure 14.4
Add class ProvidesContext to diagram 14.4
Remove class ProvidesContext from Figure 14.7
Add definition of ProvidesContext after section 14.4.5 IsScopedBy (at the end of section
14.4) as follows:
"14.4.6. ProvidesContext
ProvidesContext element represents statements that assert that a certain evidence element
provides a context for the interpretation of another evidence element.
Superclass
EvidenceInterpretation
Associations
subject:EvidenceElement[1] The subject of the ProvidesContext clause
context:EvidenceElement[1] The element that is asserted to represent the context for the
subject
Semantics
ProvidesContext element establishes a relationship between two evidence elements where
the 'context' evidence element (usually an EvidenceGroup) provides a context for the
'subject' evidence element (usually a FormalAssertion, or an EvidenceAssertion). A
'context' is defined as the set of evidence elements (including evidence items, evidence
assertions and even project elements) that are important for understanding of the 'subject'
evidence element. The concept of a context is more informal than the related concept of
'scope' (see 'IsScopedBy' assertion).
"
Delete class Supercedes
Move class EvidenceGroup to EvidenceElements diagram
Move section 14.7.1 EvidenceGroup from section 14.7 to chapter 10 Evidence Elements
Delete section 14.7 Evaluation Context Class Diagram, pages 88-89
Replace Figure 14.4 with the following: diagrams on p 88 of ptc/2012-06-04

Incorporate 11.5.2 Conflicts (p64) in a coherent way into merged SACM metamodel

The resolution to this issue is provided by the related issue 16805
Disposition: Merged

Incorporate 11.5.1 EvidenceObservation (abstract) (p64) in a coherent way into merged SACM metamodel

Change rolenames from Conflicts (section 14.5.2, page 84) into
subject: FormalAssertion[1] The subject DomainAssertion
assertion: FormalAssertion[1] The object DomainAssertion
Change rolenames for Contributes (section 14.5.3, page 85)
subject: EvidenceRelation[1] The subject EvidenceRelation
relation: EvidenceRelation[1] The object EvidenceRelation
Change rolename 'assertion1' on Figure 14.5 into 'subject'
Change rolename 'assertion2' on Figure 14.5 into assertion
Change rolename 'relation1' on Figure 14.5 into 'subject'
Change rolename 'relation2' on Figure 14.5 into 'relation'
Replace Figure 14.5 with the following: <<diagram on p 90 of ptc/2012-06-04>>

Incorporate 11.3.6 CompletenessLevel (enumeration) (p59) in a coherent way into merged SACM metamodel

The common resolution is provided under issue 16845.
Disposition: Merged

Incorporate 11.3.5 Completeness (p58) in a coherent way into merged SACM metamodel

This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
support provided by a certain evidence item. Any connection to the SACM common classes is
accomplished through the element's superclass. No other changes to this element are anticipated according
to the selected level of the integration.
The values of Completeness level are specified by a separate element <<Enumeration>>
CompletenessLevel. Potential changes to these values are addressed by a separate issue 16797.
Disposition: Closed, no change