Argument building blocks were originally proposed for CAE assurance cases, but the approach is applicable to all types of assurance cases. The building blocks approach says that there are five types of possible support for a claim – you can provide supporting evidence or use one of four types of strategy: decomposition, substitution, concretion or calculation.
There are two simple questions about the argument building blocks. The first is whether it gives value to care about what kind of claim support I use. The second is whether just four types of strategies are sufficient to describe any argument in any insurance case.
Sometimes we produce or we receive for a review overly complex or unclear arguments in assurance cases. We need to dig into such arguments to understand and verify the reasoning. Any way of organizing arguments, such as building blocks, can be useful here.
Some published GSN patterns (some of them are quite old) are quite condensed to present a sophisticated argument in one diagram. You need read the description to understand precisely their logic. An example of a condensed reasoning is in the “Hazard Directed Integrity Level Argument” pattern. In this pattern, claim G3 is decomposed into G4 and G5 using two GSN pattern operators: multiplicity (the black ball) and choice (the diamond). In fact, there are two reasoning steps hidden here.
Description of strategy S1 explains this:
The strategy is to argue that all subsystems on which the subsystem in question {Subsystem X} depends (identified by the context reference C5) are also developed to an appropriate integrity level. For each subsystem identified it is necessary to put forward a goal either of the form G4 […] or G5.
This fragment of the pattern can be presented more explicitly with two steps of reasoning, and each of which can be constructed with an argument building block. C3 is supported by a Decomposition Block with the multiplication pattern operator. We add a new claim _G3A to implement this block. The new elements we add to extend the original template have identifiers with an underscore prefix.
Claim _G3A is supported by a Substitution Block with two subclaims G4 and G5. Depending on the subsystem context the user can select the substitution for the suitability goal. Whichever subclaim is selected, the suitability goal will be substituted by the IL requirements for the subsystem development process.
This form of the argument is longer, however it’s easier to analyse and verify. You don’t need to follow the building blocks approach in all your assurance cases but it is a good practice to explicitly specify strategies and justifications for all reasoning steps. This makes the reasoning step clear and understandable. Building blocks make it easier to identify what kind of a justification and context are needed.
What do you think of argument building blocks? Do they help you keep your argument clear and easy to analyse?