GSN - Argevide

Getting ready for AI system certification

Andrzej Wardziński — Wed, 08 Apr 2026 17:06:20 +0000

Certification of AI systems is a complex process that includes both AI regulations and industry regulations. In particular, the AI Act Regulation (EU 2024/1689) defines the concept of high-risk systems for which additional requirements have been defined. For such a complex process, the use of assurance case gives the opportunity to effectively manage the development of the system for its certification.

The AI Act defines high-risk systems a little differently than we are used to in the field of critical systems, because in addition to systems affecting human health and critical infrastructures, it includes also systems affecting fundamental rights in the EU, work, access to services, justice or democratic processes. The use of AI in a medical system, for example imaging diagnosis, is a typical example of high-risk systems within the meaning of the AI Act.It is a safety-critical system, subject to regulations and standards for the safety of medical devices.

Certification requirements for medical AI

To talk about the use of assurance cases for such systems, we need to start by defining the scope of formal requirements.

Such a system meets the criteria of a high-risk system within the meaning of the AI Act, which also specifies the requirements for its certification of conformity before authorization for use.
ISO 13485 is a basic requirement on the qualification side of medical systems. The standard specifies the requirements for a quality management system (QMS), which is also required by the AI Act.
Another required industry standard is ISO 14971 for risk management for medical devices. Risk management is also required in the AI Act for high-risk systems.
We must also not forget about the MDR (EU Medical Device Regulation 2017/745) for medical devices.
Reviewing the AI Act, we will also find cybersecurity requirements, where there is no direct requirement to apply ISO 27001, but in this standard we will find the required security controls.

A more detailed analysis may identify more standards and regulations (such as GMPL), but the presented group provides a good basis for working on the AI system and preparing for its certification. Therefore, we have a fairly wide range of processes and documentation that are subject to evaluation for the approval of the system. There are several independent assessment points, including clinical credibility assessment, quality management system (QMS) audits, and finally, system compliance assessment for the AI Act and MDR.

System certification is not the end, but a transition point to the system operation phase. We then have post-market audits, especially after incidents. And more importantly for AI systems, for each new version, if the AI model is modified, recertification is required, unless certification involves continuous learning. All this together creates the need for strong management of the consistency of all documentation and control of changes and versioning. Assurance case can be the focal point of this work.

The main benefits of using an assurance case for such a system are, above all:

Efficiency of the preparation process and the certification itself thanks to the systematic approach and transparency provided by the argumentation
Risk reduction through the more efficient and earlier detection of vulnerabilities and non-conformities
Uniform reporting for all areas of the system throughout the life of the system
Easier interaction with auditors and the certification body

Efficiency of building assurance case versions for new versions of the system, especially when automating argumentation generation in the CI/CD pipeline.

Where to start?

The certification or qualification of systems often involves adhering to numerous regulations and standards. This is also the case with this system. The first decisions usually concern the organization of the assurance case process and the argumentation architecture. It is good when these activities start early, at the stage of the system concept. Argumentation templates, in particular those covering an integrated set of requirements for applicable regulations and standards, are a good starting point.

The scope of certification requirements includes safety requirements, but also requirements specific for AI technology. The main requirements relate to the accuracy and sensitivity of models for minimizing false positives and negatives, and clinical validation. This applies directly to the safety in medical sector, but there are also requirements that are specific to AI, for example, avoiding the bias or interpretability, i.e. the ability to explain decisions. A full decomposition of the requirements creates a complex argumentation template that can be adapted to a given system and its specifics.

The use of an assurance case gives a good level of process control at every stage and allows you to reduce the risk.

Artykuł Getting ready for AI system certification pochodzi z serwisu Argevide.

Eight ways to ruin an assurance case

Andrzej Wardziński — Tue, 10 Feb 2026 11:11:03 +0000

An assurance case used in a systematic and professional manner can not only be useful for system certification, but also as a communication tool in the system assurance process helping in early detection of problems and decision-making. Its effectiveness stems from its focus on goals and building confidence. However, this can be lost if you don’t work with assurance cases in the right way. It can become a costly and useless artifact. You risk failure during qualification or certification of the system.

We usually advise on how to build a trustworthy argument, but today we’ll take a a different approach and discuss how you can effectively ruin an assurance case. The following list presents eight of the worst practices for working with arguments. There are probably more, but these are definitely damaging. If you recognise any of these in your own work, you should expect your argument to be unusable.

Programmers use the concept of code smells, or poor programming practices. When they notice them in their code, they should perform appropriate refactoring to improve the code structure and quality. Below is a list of practices we can call argumentation smells.

Let’s start with the assurance case goals.

1. Define a very general goal

Why spend time precisely defining the top claim of the argument? Give flexibility with a general definition of the top claim and its context, especially the system environment and conditions of use. The claimed properties of the system don’t need to be measurable to start real work.

In reality, imprecise goals are a recipe for failure. Different stakeholders can interpret them differently. Even if you do a good engineering job and provide high-quality evidence, the overall result will be deemed untrustworthy. The only solution is to precisely define the goals, context, and acceptance criteria from the outset.

2. Develop argument when the system is already completed

Why bother with arguments when you’re busy developing the system? You could simply gather the documentation you’ve created at the end and build the argument around it. Build the system first, then create GSN diagrams.

Assurance cases are about reasoning, not just diagrams. The real goal is to build confidence as early as possible. The required evidence should be identified early to ensure that satisfies the requirements when produced. Later it will be too expensive to produce or fix it. Late argument development can generally lead to some risks being discovered late, when the design is locked, or some relevant evidence will not be available. The only way to avoid this is to start working on the assurance case early on, working iteratively through the phases of the system life cycle and using the argument in the decision-making process to produce the right evidence.

3. Simply decompose claims

Simply decompose claims into other claims without any explanation about the reasoning. No strategies, no justifications. When needed just use simple strategie like “Argue by testing / analysis / process compliance” avoiding analysis if this sufficient and adequate. Another simple strategy you may use is for example “we followed ISO 26262 / DO-178C / IEC 61508, therefore the system is safe”. Use possible simplifications when decomposing the argument.

An unexplained claim decomposition does not constitute an argument. Creating an argument means defining a strategy with explicit inference rules and their justification, and, if necessary, also providing a confidence argument. The reasoning must cover the full scope and context of the claim, and any exceptions, conditions, assumptions, uncertainties, or limitations should be clearly stated. Each step of the reasoning should increase the level of confidence in achieving safety and other required system characteristics. Constantly ask, “Does this really build confidence?” Also, ask experts for verification.

4. Ignore reported assurance or confidence issues

Assign responsibility for the assurance case to someone who has little influence on project decisions. Treat the assurance case as administrative and documentation work for certification purposes. Do not involve decision-makers in this work.

The reality is that if we are to truly reduce risk in a system, an assurance case is a tool that allows us to quickly identify necessary decisions. Therefore, the decision-maker should be responsible for developing the arguments. Typically, projects employ two main roles: one responsible for development and the other for verification and quality control. We can recommend a third management role responsible for assurance to be added to these roles, such as a Lead Assurance Architect, for example. Whatever is the role name, it’s crucial that assurance case outcome should have influence on project decisions. Any assurance case warnings, risks and evidence requests should not be ignored. Any issue arising from assurance cases should result in appropriate actions to ensure the required confidence in the assurance case.

5. Use evidence at hand

When you argue by testing, simply use a test report. Don’t waste time on checking if it’s sufficient to fully support the claim. Use evidence that fits. Trust that the evidence you have is appropriate for the purpose of your argument.

A cheap and misleading approach. The need for evidence stems from the argument, and it is the argument that generates the requirements for evidence. First, look at the argument for the evidence needed, and only then for the documentation available, not the other way around. If evidence doesn’t fully meet the requirements, either try to strengthen or supplement it, or explicitly describe the gaps and deviations. Each piece of evidence should be carefully assessed. This builds trust in the argument.

It’s important to note that claims and evidence operate at different levels of abstraction. Evidence typically represents technical data, such as analyses, modelling or testing, that we aggregate to form claims about the properties of a system. Technical competence is also important to properly interpret the proofs, understanding all constraints and the context. Trustworthy arguments require trustworthy interpretations of evidence.

6. Ignore assumptions

Specify assumptions only when and where it’s convenient. They can be also mentioned in descriptions of claims, not as separate elements. Focus on the main argument, not details such as assumptions. It’s assumed they are true, so it doesn’t matter is they are specified or not.

If assumptions aren’t made explicit, readers may assume stronger system properties than actually hold. The system may appear to be safe or secure for scenarios when, in reality, it’s not. Avoiding the discussion on assumptions during assurance case development may lead to late problem identification. Missing assumptions is like a misleading marketing: someone claims the product is very attractive, but forgets to mention limitations and situations where it doesn’t work.

7. Assume certainty and zero residual risk

Focus on the main line reasoning, without going into details of the coverage limits, confidence levels, or known gaps. Assume everything is fully effective. Say you mitigate all risks and skip the problem if the remaining residual risk. Say you fully testand verify the system. Skip properties that cannot be tested and require other ways of verification.

This is a very naïve approach. No system is completely safe or secure. The purpose of an argument is to explicitly demonstrate the remaining level of uncertainty, the limitations, and whether the residual risk is acceptable. System approval should be a well-informed decision that takes all limitations and uncertainties into account.

8. Don’t invest time in updating the argument

The target is to have the assurance case approved. When it’s achieved, treat it as a formal document rather than a technical artefact that requires updates like all system configuration items.

Assurance cases that are not consistent with the current system version become useless for engineers. The argument has value only when it is updated in line with all system artefacts. Otherwise, it would just become a record of the past. To avoid this, you need an effective configuration and change management process. You should maintain explicit status information on whether a given argument fragment is up to date.

Summary

It’s worth checking whether the issues mentioned above are present in your projects. We must respond quickly to them to avoid damaging our arguments and the effectiveness of the process. Proper application of assurance cases requires appropriate preparation, organizational conditions, and technical skills. We should not only ensure that the GSN diagram looks good, but above all, ensure the quality of the assurance case process.

Artykuł Eight ways to ruin an assurance case pochodzi z serwisu Argevide.

Assurance case automation in CI/CD pipelines

Andrzej Wardziński — Thu, 15 Jan 2026 12:11:57 +0000

The use of CI/CD tools (Continuous Integration and Continuous Delivery/Deployment) is increasingly common in the development of critical systems. The same CI/CD pipelines can also be used to automate the creation and maintenance of assurance cases including the argument structure and evidence, and also for the argument verification and status data updating.

CI/CD process and assurance cases

Let’s start with the concept of CI/CD automation processes and see how this can be related to the assurance case for the system being developed. The CI/CD process ensures the automatic creation, testing, and deployment of a system, where the software is its main part. Is the data used in the CI/CD pipeline useful for the assurance case of a given system? Undoubtedly, yes, this data includes at least information about the system configuration and the results of automated tests, which gives us information about system safety of security, and affects the structure of the argument and the evidence used. Additional value is provided by the results of the tests, which can be used to update information about the status of the argument.

The CI/CD process can also include all the information needed to build a safety/security case for a given system. The main artifacts for a security case can be threat models (HARA, STRIDE), SBOM (Software Bill of Materials), SAST / DAST / IAST reports. For safety, these will be hazard models, HAZOP, FMEA, FTA, and others. When the CI/CD process ensures that all artifacts are valid for a given version of the system, we get a consistent set of data and evidence to be used in the assurance case. Automation ensures that when creating a new version of the system, we can receive all the data to create an argument, and one of the final steps of the CI/CD process can be the creation of the assurance case itself. That means that we get an assurance case for each new build of the system.

The approach is effective when the entire CI/CD process is designed from the beginning to provide all the information needed for the assurance case. This enables the achievement of a Safety/Security Case driven development process, where the entire system development process is focused on providing the arguments and evidence needed for system certification.

Argument generation process

Technically, the assurance case integration process in the CI/CD process can include the four activities shown in the diagram below.

The first step concerns the argument template. Even if you use simple scripts to generate arguments, you need to verify them before applying them. We use templates, which gives the opportunity to use a universal tool for generating arguments. We recommend preparing a metamodel of the system data tailored for the assurance process. This will enable us to verify the template’s correctness and consistency with the metamodel. When needed, you can develop modular templates.

The second step is crucial for obtaining data to build arguments. Data in a CI/CD process is typically placed in a GIT repository using different file formats. If a file from the repository is to be used directly as evidence in an argument, then a reference to it can be used, but in many cases it is necessary to extract the data from a file. The argumentation generator needs input data that constitutes a consistent ontology according to the metamodel of the system data. Some data may be directly accessible, but it is often necessary to use AST parsing to extract the right data. As a result of the step, we have data about a given version of the system in a model format ready to be used to generate arguments.

The third step is the main step of argument generation for the system version based on its data model according to the assurance case template. Depending on the templates structure, specified conditions and parameters, an argument is created for a given version of the system with references to the relevant evidence. The argument is saved in a JSON format that conforms to the OMG SACM metamodel and can be further processed.

The last, fourth step is to verify the argument. This includes checking for completeness, consistency, and other correctness conditions. As a result, in addition to the argumentation itself, we get a report of its verification.

Subsequent actions related to the generated arguments are carried out when the CI/CD process is completed. For example, the PREMIS tool is used to visualize argumentation in GSN diagrams and generate reports. You can also combine the generated argument modules with other modules that are created manually in PREMIS.

Are you interested in insurance case automation, or do you have any questions? Get in touch!

Artykuł Assurance case automation in CI/CD pipelines pochodzi z serwisu Argevide.

Eliminative Argumentation

Andrzej Wardziński — Fri, 05 Dec 2025 16:52:07 +0000

Eliminative argumentation is an alternative approach to building an assurance case. The argument is typically constructed positively and focuses on demonstrating why we believe the goal has been achieved. Eliminative argumentation relies on the constant questioning of “what if?”. The structure of the argument can be quite similar to that of a standard positive argument, but the focus is on identifying weaknesses in the argument that hinder its purpose. This is achieved by explicitly pointing out possible weaknesses as defeaters and then explicitly demonstrating that they are not valid. The strength of this approach lies in the explicit presentation of all known defeaters. This avoids the error of excessive optimism and distorting the facts to suit the intended purpose.

The process of building an eliminative argumentation is also slightly different. For each step of reasoning, starting with the top claim, an analysis is performed to identify all possible reasons why the goal cannot be achieved. Each obstacle is explicitly described in the argument as a defeater. In the next step, for each defeater, an argument must be found, supported by evidence, that a given defeater is ineffective. For this argument, it is also necessary to examine possible further defeaters that could render it ineffective. The work on the argumentation continues until no more defeaters can be identified and all defeaters have been successfully rejected.

We will examine the application of the eliminative argumentation approach using a simple example taken from the first publication on this approach, the 2015 SEI report “Eliminative Argumentation: A Basis for Arguing Confidence in System Properties.” The purpose of the argument is to demonstrate that the light in the room is working.

Now let’s look at this using the eliminative argumentation approach. The main goal will be the same, but we don’t create a positive strategy around it. Instead, we look for conditions that might prevent the bulb from turning on. We add these conditions as “unless…” stipulations. We start by saying that the bulb will turn on unless there’s no power. Next, we can say that the bulb will turn on unless the switch is not connected. Once the list of known problems is exhausted, we can add “unless another, as yet unknown, problem occurs.”

The condition for completing this step of the argumentation development is the lack of knowledge of other possible defeaters. If we learn of any other possible reason that could prevent the proposed postulate from being met, it should be added as another defeater.

For each deeater identified in the argument, you must now provide evidence that the given defeater will not occur in your system. This may be described by one or more claims or a strategy supported by an argument. It is important to present convincing evidence that the defeater doesn’t pose z risks or the risk is sufficiently low. For unknown defeaters, you should demonstrate that you have completed enough identification activities and identified enough of them that continuing will no longer provide any benefit in reducing the risk level.

The resulting argument has a similar structure to the traditional approach, but it explicitly states the defeater challenging the argument goals. In our example, the list of evidence is almost identical. The only difference stems from the fact that justification J1 in the first diagram is not supported by any evidence.

Although it requires more work, eliminative argumentation has the advantage that it explicitly presents defeaters, which facilitates argument verification. This allows for a potentially higher level of argument quality and trustworthiness.

This approach can now be used in PREMIS. The methods of arguments presentation and the assessment functions have been extended to include a new type of argumentation elements, defeaters.

Artykuł Eliminative Argumentation pochodzi z serwisu Argevide.

Managing system limitations in safety assurance cases (SOTIF)

Andrzej Wardziński — Thu, 20 Nov 2025 13:56:01 +0000

Safety cases are usually based on functional safety arguments to demonstrate that failures will not result in hazardous situations. But accidents may have causes related to the system behaviour different than failures. This is where SOTIF comes in. This stands for Safety of the Intended Functionality. What does it mean? It covers mitigation of hazard factors related to unexpected situations or system limitations. One example of an unexpected situation is bright sunlight making it difficult for an autonomous vehicle to identify lanes. Another example is a system misuse, such as a system operator giving commands that is not foreseen for the current operation mode. SOTIF helps us assure safe system behaviour in unexpected situations.

SOTIF extends functional safety

Functional safety focuses on the risk arising from system faults or failures, i.e. hardware or software malfunctions. In the automotive sector, this is described in the ISO 26262 standard. Safety assurance for other causes related to system limitations and unexpected situations are regulated in the SOTIF standard ISO 21448.

The SOTIF safety assurance process involves a few steps:

The boundaries and scope of the intended functionality must be defined within the Operational Design Domain (ODD).
System behaviour is analysed for potential unsafe scenarios.
Mitigation measures are identified, which can be related to functional modifications to achieve SOTIF goals.
The planned mitigation measures are implemented and verified.
Validation is performed under diverse and representative conditions.
Field monitoring for SOTIF evaluation and maintenance is defined for implementation during system operation.

SOTIF arguments

SOTIF implementation needs to be demonstrated in the system safety case. Guidance how to do this and examples of GSN arguments are provided in ISO 21448. A sample top-level argument for the pre-release SOTIF process of safety assurance is presented below. A separate claim is specified for each main phase of the SOTIF process.

This argument should be extended to include a second branch of the argument for the operational phase of the system life cycle. This argument is focuses on demonstrating the capabilities of the SOTIF safety maintenance process, since the argument is to be developed and approved before the system operation starts. During the system operation this can be supplemented with evidence that these actions are actually performed.

As SOTIF extends functional safety, there is a question how these two arguments relate to each other. There are a few common actions or work products shared between functional safety and SOTIF, such as:

identified hazards,
limitations and assumptions of functional safety,
safety goals and safety requirements,
safety requirements verification and validation.

You can develop separate assurance case modules for functional safety and for SOTIF, they can refer to shared artifacts where necessary. Probably, you will need a claim to demonstrate that functional Safety and SOTIF measures are consistent and jointly sufficient to achieve the acceptable system risk level.

You can browse the sample SOTIF assurance case online in PREMIS using this link.

Summarizing, joint SOTIF and functional safety assurance case covers hazards related to both failures and system limitations including unexpected situations. ISO 21448 is dedicated for automotive sector but this approach is also useful in other industries.

Artykuł Managing system limitations in safety assurance cases (SOTIF) pochodzi z serwisu Argevide.

LTAC – Simple text assurance case format

Andrzej Wardziński — Thu, 30 Oct 2025 04:41:04 +0000

When working with assurance case arguments, a simple text argument format can be useful. This should be understandable to humans and usable with AI tools, while also being formally defined so this can be imported into assurance case editors. For this purpose, we are introducing LTAC – Lightweight Text Assurance Case. It’s a simplified text format for presenting assurance case arguments. Let’s look at an example argument. Is it easy to read and understand?

- Claim G1: System is acceptably safe to operate
  - Context C1: System Definition
  - Strategy S1: Argue by mitigating all hazards
    - Claim G2: All  hazards have been identified
      - Evidence E1: Hazard analysis report
    - Claim G3: All identified hazards have been mitigated
      - Strategy S3: Decompose mitigation argument by identified hazards
        - Claim S5: All identified hazards have been accurately assessed
        - Claim S6: Mitigation strategies have been implemented for all hazards
        - Claim S7: The effectiveness of the mitigation measures has been validated
    - Claim S4: Continuous monitoring of risks is in place

The above argument fragment is human-readable, which is crucial. It can easily be reviewed and modified as needed.

When this argument is pasted into PREMIS, we get the GSN diagram as shown below.

LTAC arguments can be created manually, but also using AI tools or scripts. If you want to use an AI tool, first give it an instruction to use LTAC notation according to the LTAC specification. Once the AI tool learns the LTAC notation, it can easily create and analyse arguments in this way.

As the argumentation gets larger, this textual form becomes more difficult for humans to review. However, the argument fragments in LTAC are still easy to use.

There’s another major limitation to LTAC. This text-based argumentation is effective when there are no argument element descriptions or metadata, such as ‘undeveloped’ tags or other similar information. In such cases, more advanced textual notations, including those using YAML, can be used. However, when the data for a single argument element is more complex and not presented in a single line, it becomes more difficult for manual analysis.

LTAC is an effective solution when you use AI tools and want to review the argument before inserting it into the assurance case tool. It works well with PREMIS.

Artykuł LTAC – Simple text assurance case format pochodzi z serwisu Argevide.

Using confidence arguments in assurance cases

Andrzej Wardziński — Tue, 21 Oct 2025 12:06:10 +0000

Confidence arguments help to justify that main arguments in assurance cases are sound and trustworthy. While the main argument directly addresses system safety or security, the purpose of the confidence argument is to answer the question why we should trust that the main argument is right. Some standards and guidelines, and also some certifiers require an explicit demonstration of the confidence argument, that is a consistent and complete justification that the main argument is trustworthy.

The starting point is demonstrating confidence in a single argumentation step. There are a few ways how you may do this. Here, we present the use of Justification type of argument elements. GSN Community Standard version 3 in section 1:2.2.18 says: “A justification can also be connected to a strategy, to provide backing for the argument described by the strategy.” That’s the point. We need explicit backing for the argumentation reasoning step described by a strategy. The backing should say why should trust that the reasoning is sound, it covers the full context of the claim, all required premises are available and all known problems or weaknesses are resolved. To create such backing we have extended the Justification element to allow it to be supported by an argument. We also allow justifications to be linked to confidence claims. This approach allows to keep the main argument and the confidence argument separate.

PREMIS extends the GSN argument structure to allow justifications to be supported by arguments. The diagram below shows on the left a simple safety argument with justification J1 that is a link (a citation) of a confidence claim CC1. Its argument structure is presented on the right. This example illustrates how the confidence argument can be implemented and how it is related to the main safety argument.

This approach can be used for individual argumentation steps and for complete assurance cases.

The main argument asserts that an acceptable level of system safety has been achieved. Each claim in this argument contributes to achievement of the system safety.
The confidence argument should justify that each argumentation step of the main argument is valid. This does not contribute directly to the system safety, but it is required to trust in the main safety argument. If we cannot provide a convincing confidence argument for a given step of the main argument, we cannot trust its validity.

Example of safety and process reliability argument branches

The argument map diagram below presents this approach applied to a simple assurance case. The argument map shows the pages of the argument diagrams. The top claim name for each page is displayed. The left part of the diagram contains the main safety argument and the confidence argument is shown on the right. You can also browse this assurance case online in PREMIS using this link.

The confidence argument presented here includes just five claims, which is sufficient to demonstrate its structure. It should be based directly on the system development process or its life cycle. The confidence argument should follow the development process and at same time it should be consistent with the structure of the main safety argument. An adequate confidence claim should be provided for each step of the main argument. In practice, there will be hundreds of confidence claims and links to the safety argument. While the use of quality gates and other checkpoints implemented in the safety assurance process can simplify the linking of two arguments, the confidence argumentation must still cover all the requirements of the relevant standards for the development process.

This approach can be extended with additional layers of the argument. For example MISRA Guidelines for Automotive Safety Arguments proposed the next argument layer named Organizational environment that should contain an argument demonstrating that all system life cycle activities are performed by an organization with an appropriate environment, which includes, among others, a Quality Management System (QMS), continuous improvement process, adequate team qualifications.

Separating the argument layers into different argument branches or separate argument modules can make managing large assurance cases easier for development, reviews and maintenance. The relations between the main argument and the layers of the confidence argument are easy to maintain in PREMIS when the structure of the main argument is consistent with the system development process.

Artykuł Using confidence arguments in assurance cases pochodzi z serwisu Argevide.

Building strong assurance cases

Andrzej Wardziński — Fri, 01 Aug 2025 10:46:02 +0000

Strong assurance cases are achieved by building confidence in the validity of reasoning steps and demonstrating how defeaters are handled. These two approaches present two different directions of argumentation. The first one focuses on providing sound basis for the argument while the second aims at defending it against known defeaters.

Which approach is more effective and should be used? The explicit specification of defeaters seems attractive because it provides direct answers our doubts. When I have a “but…” comment, someone can point to a corresponding defeater in the argument and present how it is handled. In this way an assurance case can address the concerns of doubters. They can be satisfied when they find direct answers for their doubts.

On the other hand handling defeaters creates additional explanations for the argument, which should be sound in the first place. If the argument is weak, the response to a defeater should involve a modification of the argument structure. To avoid this we should develop sound arguments from the outset. The best way is to base on proven argument templates and ensure validity of all reasoning steps. The goal is to avoid weaknesses in the whole argument development process.

There are some basic rules that help in the development of sound arguments.

Specify a strategy for each reasoning step, avoid direct supporting claims by subclaims. This will help reviewers to check if the argument decomposition is complete and valid.
Specify a justification why you think the strategy is valid for a given claim in its context. Is it valid in all application scenarios? Have you considered all interactions? Are all subclaims valid in the main claim context? Identify all possible weaknesses. The justification is especially important when you reuse argument structures in a new context.
When the justification is not straightforward, extend it with a confidence argument.

A confidence argument is an argument that supports the credibility of the main assurance argument. The two arguments form an inseparable pair and should be kept together in one assurance case module. This helps to ensure consistency of argument. An argument module can have one or more confidence top claims. The diagram below presents the general schema for the use of conformance argument. Conformance claim CA1 is used to support strategy S1 in the main assurance argument.

The confidence argument for a reasoning step should justify the validity of the reasoning, taking into account the conditions:

The inference rule is valid for a given claim within its context.
The inference rule has been applied correctly and it covers the full required context.
The premises (sub-claims) are correctly defined and satisfy all conditions.
The premises are valid and consistent.
There no unresolved defeaters or rebuttals.

Explicitly specifying strategies and justifications helps to identify weak reasoning early on. Although it may seem to slow down the development process, detecting argument deficiencies enables the argument structure to be adapted early on in the system assurance process. Confidence argument reviews, involving third-party reviewers when possible, are a good system assurance process practice.

You can read more about the use of confidence argument in the paper “Integrating Confidence and Assurance Arguments” published in 2015. The main idea of the confidence argument is still valid.

Artykuł Building strong assurance cases pochodzi z serwisu Argevide.

Static and dynamic evidence in PREMIS

Andrzej Wardziński — Mon, 30 Jun 2025 11:31:32 +0000

An assurance case is a structured argument supported by evidence. It can a static safety case referring to static evidence and frozen in a Safety Case Report. And it can a dynamic object referring to dynamic evidence that can evolve. For example the evidence may include Safety Performance Indicators based on measurements during system operation. The key question is how you track the changes of evidence to maintain a valid, consistent and up to date dynamic assurance case.

PREMIS supports four ways in which you can refer to evidence within your assurance case. Each method offers the possibility of creating dynamic assurance cases, but with different levels of automation and technical difficulty.

These four ways are given below and they are presented in the video.

You can refer to off-line evidence. The evidence will not be available in the application for the user, but you may specify its identification data or summary. This option does not support dynamic arguments unless you manually change the evidence data or you have a software agent that can do this for you.
You can upload evidence files to PREMIS and use them in the argument. This option also does not support dynamic arguments unless you manually upload new evidence or you have a software agent that can do this for you.
URL addresses can be used to reference to online evidence items. These are usually static objects, such as PDF files, however you can also use web service addresses for dynamic data.
The last option is an integrated evidence repository. This can be a SharePoint service for storing technical documentation but this approach can also be used for repositories containing dynamic data. What’s important, this integration includes authentication. This is often required to access sensitive data in any system.

The first step for building dynamic assurance case is to decide how you plan to transfer the dynamic data into the argument. This will depend on the technology used to produce the data, if the result is available online, what type of authentication is required, or maybe your systems can send some notifications?

The next step is the decision how these data are presented in your argument. You will probably have argument claims referring to system operation and maintenance process (for example in SOTIF).

The final design step involves planning information propagation and notifications. The information propagation in the argument is usually based on the assessment mechanism and this allows to affect the top claim when major problems are reported in the dynamic data. The results can also be published in online bulletins or reports, or via email notifications.

A dynamic assurance case could be an effective tool for supporting system safety or reliability monitoring. However, all this depends on the first step, which is the decision on how dynamic data is to be presented as evidence in the argument. Any solution that works is a good one.

Artykuł Static and dynamic evidence in PREMIS pochodzi z serwisu Argevide.

Easier GSN argument development

Andrzej Wardziński — Sat, 14 Jun 2025 04:33:16 +0000

Editing GSN arguments in PREMIS is now easier, you can drag elements from the tray directly to the diagram. At the same time, the performance of GSN diagrams in the new version of PREMIS has been improved. Especially generating diagrams is now very fast. The new version also includes improvements in the management of assessments, permissions and evidence repositories.

PREMIS version 1.7 was released on 12 June. The most notable improvement is the enhanced performance of GSN diagrams, which has increased by more than twofold. In particular, diagrams can now be generated for existing arguments very quickly.

Another change that makes working with GSN diagrams easier is the introduction of a container of elements that can be dragged directly onto the argumentation diagram. PREMIS ensures that the argument structure complies with the GSN Standard and indicates where a given new element can be inserted. This is shown by the colour of elements in the diagram. Their background turns green when a new element can be inserted. Red colour indicates that a new element cannot be added in that place.

Other improvements in the new PREMIS version include new features in the folder view, including managing user roles in projects and folders and configuring the assessment method. These features are now also available in the module diagram.

It is now also easier to use internal repositories for storing evidence used in assurance case arguments. A new repository can be created directly in the GSN diagram, and then evidence files can be uploaded into the PREMIS server directly in evidence reference elements (GSN Solutions).

Another useful feature is the presentation of evidence in graphic format directly in the GSN diagram. This is useful when, for example, photos taken during inspections are used as evidence. Graphic files are now also included in the reporting data and can be presented directly in Safety Case Reports.

Artykuł Easier GSN argument development pochodzi z serwisu Argevide.