Reviewing Assurance Arguments – A Step-By-Step Approach
T. P. Kelly
Department of Computer Science
University of York
E-mail: tim.kelly@cs.york.ac.uk
Abstract
An assurance case based regime requires a strong
review element. Typically, one party is responsible for
preparing the assurance case. Another party (the
certification authority) is responsible for accepting the
assurance case. Assurance cases are, by their nature,
often subjective. The objective of assurance case
development, therefore, is to obtain mutual acceptance
of this subjective position. The move from less
prescriptive standards to “goal-based” standards has
both strengthened the need for assurance cases, and
increased the required review capability of the
acceptance authorities. This paper presents a
structured approach to assurance case review –
focusing primarily on helping to assess the level of
assurance offered by the assurance case argument.
1. Introduction
An assurance case based regime requires a strong
review element. Typically, one party is responsible for
preparing the assurance case. Another party (the
certification authority) is responsible for accepting the
assurance case. Assurance cases are, by their nature,
often subjective. The objective of assurance case
development, therefore, is to obtain mutual acceptance
of this subjective position. The move from less
prescriptive standards to “goal-based” standards has
both strengthened the need for assurance cases, and
increased the required review capability of the
acceptance authorities.
In this paper we first discuss the role of review
within the assurance case development lifecycle and
the typical problems experienced in reviewing
assurance cases. Against this backdrop, we then
present a staged argument review process that ranges
from identifying simple problems of argument
comprehension to the more difficult challenges of
argument criticism and defeat.
2. Role of Review in the Lifecycle
The most obvious position in the system lifecycle
for review of the assurance case position is “pre-
operational” – i.e. just prior to the system being
approved to enter service. However, staged safety case
review (alongside staged production of the assurance
case, as advocated in [1] and [2]) is far less risky (in
project risk terms). If there are problems with the
arguments and evidence being offered up by the
assurance case it is desirable to find this out as early as
possible in the lifecycle.
The most compelling staged reviews of assurance
cases will involve representatives from the acceptance
authority. It is often not possible to get an acceptance
authority to “sign in blood” that an interim assurance
case is acceptable. Instead, the concern when
involving these stakeholders is to obtain the “non-
negative” response – i.e. to know that the assurance
case, as it stands, doesn’t contain any serious flaws in
reasoning or weaknesses in evidence.
Even where it isn’t possible to involve the
acceptance authorities in interim review activities, self-
review (by the preparing organization) of an assurance
case is still an extremely useful activity. (Often the
most difficult people to convince of the assurance of a
system are those that know it best!). Self-review either
requires the involvement of people within the
organization who have maintained some independence
from the assurance case development, or the
involvement of people capable of imaginative role-
play. (“If I were the acceptance authority, what would
I find unconvincing about this argument?”) .
3. Problems Experienced in Assurance
Case Review
A key difficulty reported by those regularly
involved in the activity of reviewing and accepting
assurance cases lies in discerning the elements and
structure of the argument being presented. The first
step in reviewing any argument is first to be able to
clearly identify the argument being put forward. Too
often, reviewers are required to perform “industrial
archaeology” to uncover the arguments and evidence.
This difficulty can often lead to rounds of review
comments primarily concerned with the presentation
rather than the structure of the argument.
Once the argument is uncovered there can be
further difficulties. For example, it can be extremely
easy for the author of the assurance case to assume too
much knowledge of the reader. It will almost always
be the case that the persons responsible for reviewing
the assurance case will have less knowledge of the
system under scrutiny than the developers. It can be
easy for the developers to make “leaps” of argument
that appear obvious from their perspective or to simply
refer to system concepts (or the dreaded TLAs1) that
are confusing for the reader.
4. A Staged Argument Review Process
Figure 1 illustrates a staged approach to reviewing
assurance case arguments:
Step 1 Step 2 Step 3 Step 4
Well-
Expressive Argument
Argument formedness
Comprehension (Syntax)
Sufficiency Criticism
Checks & Defeat
Checks
Figure 1 - A Staged Argument Review Process
Reviewing assurance case arguments can be
thought of as consisting of, at least, the following four
steps:
• Step 1 - Argument comprehension
• Step 2 - Well-formedness checks
• Step 3 - Expressive sufficiency checks
• Step 4 - Argument criticism and defeat
These steps are presented both in the order of
necessity (e.g. we cannot check if the argument is well-
formed before we fully comprehend the structure of
the argument) and the order of difficulty. The latter
stages require more intellectual effort and domain
knowledge that the former.
Given that the steps are presented in order of
necessity, where a step cannot be satisfactorily
completed – e.g. in Step 2 the argument appears to not
be “fully connected” – there may be little point in
1
Three Letter Acronyms
proceeding to the next step. Argument review can
require considerable expertise and effort. It would
therefore by sensible to “halt” the process if
insufficient information at any one step was likely to
create cascading problems for later steps. For
example, an argument may simply appear to be weak
(Step 4) because it has not been adequately expressed
(Step 3).
The following sections expand upon the activities
and concerns of each of the four steps.
4.1. Step 1 – Argument Comprehension
In order to assess the argument it is first essential
that the reviewer can understand the argument being
presented. This step involves attempting to identify
the key claims, strategies, assumptions, context and
evidence of the assurance case. Where the assurance
case has been presented textually, it can often be useful
to markup the text with colored highlighters (using
different colors for evidence, assumption, claim etc.)
when reviewing the document.
Having identified the essential elements of the
assurance case, it is then necessary to identify the links
of the argument. For example, this activity involves
determining the argument approaches (strategies) that
are being used to support the claims identified, and the
evidence items being used to support the arguments. If
these links are not immediately obvious from the text
of the assurance case report, it will be necessary to
annotate the document further with cross-references.
At this point, if the assurance argument isn’t already
captured in a structured form (such as the Goal
Structuring Notation [3] – GSN – or Claims,
Argument, Evidence – CAE [4]) it can often be useful
to attempt to re-represent the argument using one of
these notations. Constructing such a representation of
the argument structure can be the ‘acid test’ of whether
the reader truly understands the nature of the argument
being presented.
4.2. Step 2 – Well-Formedness Checks
Even before looking at the detail of the argument, it
can be possible at this stage to identify structural errors
in the argument under review. For example, circular
arguments (in which the premises of the argument
depend in some way on the conclusions of the
argument) are rarely considered acceptable. At this
stage it may be possible to identify claims “without
support” – where no supporting argument or evidence
is offered up. Conversely, evidence may be present,
but its role in the argument unclear.
 It is often desirable that the argument is “fully
connected” – i.e. that there are no disconnected
fragments of argument with an unclear relationship to
the overall argument being presented.
Given that the above checks can be thought of as
simply relating to the syntax and structure of the
assurance argument it is possible to provide tool
support (e.g. see [4]) to perform some of these checks
automatically (provided that the argument is captured
using a structured notation such as GSN or CAE).
4.3. Step 3 – Expressive Sufficiency Checks
The purpose of this review is to assess whether the
arguments have been sufficiently expressed in order for
the argument to be truly understood. Often elements
of an argument can be implicit. In GSN, the purpose
of a strategy node is to explain the relationship
between a parent goal and child goals in the argument.
Explicit documentation of strategies is useful wherever
this relationship is unclear. At this stage in the review
process it may be felt that that further explanation of
the inferences within the argument is required before
any further review.
Equally, in GSN it is possible to add references to
contextual information (using the Context symbol)
wherever the meaning of a goal (claim) is unclear. For
example if a goal states that, “The throttle will
continue to operate safely in the presence of faults”,
unless the context of the ‘faults’ under discussion is
clear the claim is ambiguous. In this review step, it
may be necessary to demand further context to be
defined before any further review should sensibly take
place.
This step is concerned with elements that are
missing from the description of the argument that
prevent gaining a full understanding of the argument.
4.4. Step 4 – Argument Criticism and Defeat
In this step it is first important to recognize the
distinction between inductive and deductive arguments
(as this alters the nature of possible criticisms of the
argument). A deductive argument is an argument that
proceeds without any room for probability [5]. An
inductive argument is one that is based upon the
estimation of the probable truth of the premises [5]. In
an inductive argument the probable truth of the
premises is passed through the argument to the
conclusion. Assurance case arguments are rarely
provable deductive arguments. Instead they are more
commonly inductive.
For deductive arguments, it is possible to simply
question the validity of the inference of the arguments
in terms of truth or falsity. For inductive arguments,
the situation is more complicated. The question in this
case is of the overall sufficiency of the argument – i.e.
are the premises of the argument “strong enough” to
support the conclusions being drawn. The sufficiency
of the relationship between the premises and
conclusion of the argument can depend on a number of
attributes:
• Coverage – To what extent does the
argument / evidence presented ‘cover’ the
conclusion? For example, a conclusion
regarding all hazards that presents evidence
for only a subset has a potential problem of
coverage.
• Dependency – The level of assurance
offered up by multiple forms of evidence or
strands of argument may not be so
convincing if they are not truly independent.
For example, on inspection two forms of
evidence may both be found to use a
common flawed model of the system as a
starting point.
• Definition – It could be considered
undesirable to over-constrain or under-
constrain the argument or evidence being
presented. For example, an argument of
safety that is assured only for a narrowly
defined operational context (“The system is
safe on Tuesdays”) may be considered
insufficient for the purposes of approving
safe operation of the system.
• Directness – To what extent does the
argument or evidence directly address the
conclusion being sought? Against a specific
product claim, process evidence can be
regarded as ‘indirect’. Indirect arguments
are often considered unconvincing.
• Relevance – How relevant is a piece of
evidence or argument to the conclusion
being sought. An argument that the
“System is safe” because the “Sky is Blue”
suffers from a problem of relevance.
Although this is an extreme example, often
more subtle problems of relevance can exist.
For example, the claim that a later version of
a software item satisfies a requirement based
upon test evidence relating to a previous
version can present a problem of relevance.
• Robustness - How fragile is the argument to
possible changes in the evidence and
consequent claims? For example, consider
 an argument where an objective is argued to
be ‘just’ satisfied vs. an argument where
achievement exceeds the objectives by a
some margin. The latter would be
considered by many to offer greater
assurance.
When providing feedback from this step in the
review process it is best to be as specific as possible in
identifying the problems present. Almost all of the
above criticisms could be labeled as presenting an
“insufficient” argument. However to say, for example,
that the problem with the argument is a “lack of
coverage” is more useful to the assurance case
developer when attempting to rectify the problems.
It is worth recognizing that criticisms of the
argument at this stage – e.g. a concern of argument /
evidence relevance – could simply relate to
weaknesses in expression (Step 3). For example, if (in
GSN) an argument strategy was disclosed the
relevance of the claims may be better understood (and
thus less likely criticized).
4.4.1 Auditing the Evidence
There is a requirement with assurance case review
to audit what is being presented. For example, do all
the items of evidence being referred to by the
assurance case argument actually exist? If they exist,
do they support the claims of the assurance case as
presented. For example, if a claim is made that “All
hazards have been closed out in the hazard log”, will
review of the hazard log show this to be true?
In abstract, the evidence (as referenced) may
support the arguments as stated. However, if this
evidence item isn’t considered sufficiently
‘trustworthy’ the argument may be undermined. In
law the concept of “integrity” of evidence is used
(especially in the case of forensic evidence). For
example, if the evidence collection and analysis
process cannot be assured, evidence can be ruled
inadmissible.
For assurance cases, there are a number of possible
factors to consider when assessing the integrity of
evidence:
• “Buggy-ness” – how many “faults” are
there in the evidence presented? Upon
review, the more mistakes that can be found
in the evidence, the less confidence is
gained.
• Level of Review – has the evidence been
presented without thorough review by
suitably competent and experienced peers?
(This concept is already embedded in the
requirements of DO178B [6] for
independent review for software items
developed to high Development Assurance
Levels)
• In the case of hand-generated evidence the
experience and competency of personnel
can be regarded as essential ‘backing’
evidence
• In the case of tool-derived evidence, tool
qualification and assurance become
important issues. (Again, the tool
qualification guidelines for DO178B
recognize this issue. DO178B makes an
important distinction between tools where
the output forms part of final delivered
product vs. tools with an ancillary role in the
development process.)
4.4.2 Argument Defeat
A good assurance case cannot be selective in the
arguments and evidence it presents. Facts not included
within the presentation of the assurance case may
challenge the argument. It is necessary to be prepared
to consider if such facts exist. This has been
recognized for safety cases by the most recent issue of
Defence Standard 00-56 (Issue 3) [1]:
“9.5.6 Throughout the life of the system, the
evidence and arguments in the Safety Case should be
challenged in an attempt to refute them. Evidence that
is discovered with the potential to undermine a
previously accepted argument is referred to as
counter-evidence. The process of searching for
potential counter-evidence as well as the processes of
recording, analysing and acting upon counter-
evidence are an important part of a robust Safety
Management System and should be documented in the
Safety Case.”
This is one of the hardest aspects of the review
process owing to the open-ended nature of the
challenge. To know that there is something not
presented within the assurance case requires domain
knowledge.
Two forms of argument defeat can be considered in
this stage:
• Rebuttal
• Undercutting
Rebuttal describes the situation where evidence exists
that allows you to reach a conclusion counter to one
presented in the assurance case. For example, if the
assurance case claims, “Failure Mode X has never
occurred”, rebuttal would be to support the claim,
“Failure Mode X has occurred” by reference to
supporting arguments and evidence (e.g. a previous
incident report). Rebuttal describes a “head to head”
dispute between the claims of the assurance case and
counter-claims that can be substantiated.
Undercutting describes the situation where additional
arguments and evidence can be introduced that
challenge the reasoning (especially the inferences)
presented within the argument. For example, consider
the argument: Premise: “The vehicle is traveling at 80
mph”, Conclusion: “The driver is breaking the speed
limit”. An additional fact may be introduced, namely
that “The vehicle is traveling along a private road”,
that challenges the inference. In this stage of the
review process it is necessary to consider whether
there are any circumstances where the premises of the
argument are true, yet the conclusions false.
6. References
[1] Ministry of Defence, Defence Standard 00-56 (Issue 3):
Safety Management Requirements for Defence Systems,
U.K. Ministry of Defence, December 2004
[2] T. P. Kelly, I. J. Bate, J. McDermid, A. Burns, “Building
a Preliminary Safety Case: An Example from Aerospace” in
Proceedings of the 1997 Australian Workshop on Industrial
Experience with Safety Critical Systems and Software,
Australian Computer Society, Sydney, Australia, October
1997
[3] T. P. Kelly, “Arguing Safety – A Systematic Approach to
Safety Case Management”, DPhil Thesis, YCST-99-05,
Department of Computer Science, University of York, UK,
1998
[4] L. Emmet, G. Cleland, “Graphical Notations, Narratives
and Persuasion: a Pliant Systems Approach to Hypertext
Tool Design”, In Proceedings of ACM Hypertext 2002
(HT’02), June 11-15, 2002, College Park, Maryland, USA
[5] M. Cass, R. Le Poidevin, “A Logic Primer”, Vortext
Publishing, 1993

5. Summary [6] RTCA, DO178B: Software Considerations in Airborne

Systems and Equipment Certification, RTCA Inc., 1992.
With an increasing demand for, and production of,
assurance cases, there is an increasing requirement for
rigorous review of assurance arguments. The inherent
subjectivity of many assurance arguments further
strengthens this requirement. This paper has presented
a systematic review process comprising steps of
increasing difficulty, ranging from identifying
concerns of argument comprehension to identification
of possible causes of argument defeat. Adopting such
a process can significantly help in judging the
adequacy of assurance case arguments.