News - Argevide

Inspection readiness managed with assurance cases

Andrzej Wardziński — Mon, 18 May 2026 14:09:30 +0000

Regulations and standards in some industries require an organization to maintain readiness for control, audit, or inspection. Examples include GMP (Good Manufacturing Practices) in the pharmaceutical industry, MDR (Medical Device Regulation) for medical devices, and more recently the AI Act for high-risk AI systems. Maintaining inspection readiness requires coordinated cooperation between the relevant units, and this is where the use of assurance case can be helpful. The assurance case structure ensures that audit objectives are explicitly linked to the evidence. It also supports control over the documentation timeliness and change management. When implemented for a process or system, dynamic assurance cases are an effective means of maintaining inspection readiness. An assurance case serves as a knowledge base on readiness, and at the same time it has mechanisms to help control consistency, completeness and maintain up-to-date evidence.

Effectiveness and vulnerability detection

Structured arguments force the connection of compliance goals with all evidence items into a logical chain of dependencies. This makes audits easier. This is useful for maintaining readiness for inspection. Assurance case tools show the readiness status for each area in real time. When an assurance case is integrated with a document management system, it is possible to efficiently verify readiness for inspection. This allows for quick detection of gaps and vulnerabilities, and after all, the point is to detect and fix them yourself so that they are not detected during external audits.

Most of the time during inspections is spent searching, selecting and preparing data, rather than analyzing it. Sometimes the analysis is only 20% of the control time. The use of assurance case changes this, because the data is organized from the beginning and this is maintained at all times. More time can be spent on analysis. Audits are more effective. Even if the initial structure of the argument is not optimal, subsequent inspections also provide feedback to help improve it. Good assurance cases ensure high inspection efficiency.

Structural arguments facilitate inspections and verifications, which can sometimes be interpreted as helping the inspectors rather than the inspected units. But here we control our own readiness for inspections and this feature of the assurance case becomes an advantage for us.

Assurance cases are a universal solution effective at the level of the entire organization, it can include various business units, systems and technologies. In this way, the assurance case also becomes a communication platform.

Communication and clear responsibilities

A single inspection readiness management platform creates a means of communication not only between units of the organization, but also in communication with inspectors. Because assurance cases facilitate inspections, inspectors are happy to work with them. Each section of the argument has a clearly defined goal and context, making communication more specific and goal-oriented. There is less ambiguity and misunderstanding of the other side, which helps to create a more positive and productive environment. The problem of information silos is practically reduced, because the decomposition of argumentation is automatically linked to responsibilities for its parts.

Individual parts of the assurance case have their owners, so they automatically participate in communication on a given topic. We avoid a lot of ambiguity about liability. For each piece of evidence, the argument also specifies its source. Such information makes it easier to assign responsibilities and shows the inspectors that the organization has real control over the areas covered by the inspection.

Change management

When there is a change in a process, product, or regulation, an assurance case helps in quick evaluation of its scope. The argument structure helps to identify the argument branches that need to be updated. If there are relationships, they are explicitly defined in the argumentation and are taken into account in the analysis of the scope of changes.

Some changes are due to the passage of time itself. Evidence of compliance is often not valid indefinitely. Their expiration is reported and causes the need to run specific actions, such as performing a re-review and renewal.

All changes are explicitly specified and reported. Reports show the current state of readiness for inspections, indicating areas requiring action or expected to require action in the near future. The assurance case data is subject to configuration management and versioning. This enables analysis of any previous version.

Customization and scalability

Changes can also result from business decisions and events. By their nature, assurance cases provide the flexibility to adapt the structure of argumentation to the specifics of processes or systems. This gives us flexibility while remaining under the control of change management processes. At all times, the consistent argument structure and the associated evidence are maintained.

Divide and rule. This principle also applies to the assurance case. We can divide the case into modules and distribute responsibilities accordingly. This is integrated with permission management, authorising the right people to perform tasks such as providing and updating evidence, or conducting reviews. The entire assurance case solution can be scaled for large organisations and systems.

Summary

Applying an assurance case to manage inspection readiness requires a little more work at the initial stage, but later, during maintenance, it significantly speeds up the implementation of inspections and makes them more efficient, also from the perspective of an organization demonstrating compliance and readiness for inspection.

Andrzej Wardziński
Share your comments

Artykuł Inspection readiness managed with assurance cases pochodzi z serwisu Argevide.

Verification of AI-generated work products with assurance cases

Andrzej Wardziński — Tue, 05 May 2026 09:27:58 +0000

The accuracy and thoroughness of documentation are crucial for system certification. While the use of AI can accelerate the preparation of such documentation, it can also impact its quality. How can such documentation be effectively reviewed when it is extensive? It is important that information is presented in a way that makes it easy for humans to review. Structured arguments used in assurance cases facilitate this.

How serious is the problem, and are such reviews needed? In April, the FDA issued a Warning Letter rejecting the drug registration application, citing serious procedural errors including the inappropriate use of AI (see the section ‘Inappropriate Use of Artificial Intelligence‘). The FDA’s approach is very restrictive. The consequences of providing false information in submitted documentation can be severe. What are the causes of these problems? Do documents created by AI merely cover up human errors? Unfortunately, AI not only hallucinates, but also generates errors. A recent Microsoft Research publication, ‘LLMs Corrupt Your Documents When You Delegate‘, indicates that AI can corrupt documents when working with it. They demonstrated that 20 iterations of the AI work on a document can damage up to 25% its contents. While AI can accelerate work, it also creates new risks.

Structured arguments were created to organise information for verification and to make it easier to review the documentation of complex systems. Information that is related and should be verified together because it leads to a specific conclusion is presented side by side in the argument. The verifier doesn’t have to search for the information. An assurance case makes life easier for verifiers, not for system developers. If the AI creates some system documentation, we can also delegate to the AI the task of organising information from that documentation into an argument. Typically, no modifications to the system documentation itself will be necessary, as the argument is an additional information structure that simply references individual documents and their fragments. The created argument provides an insight into the documentation from an auditor’s perspective. Creating arguments can help the AI better understand its goals and improve the documentation. Let the AI create such arguments and let humans verify them. This achieves maximum effect with minimum effort.

How do arguments facilitate verification?

Arguments clearly show how system goals, such as safety or security, can be demonstrated based on the evidence documentation. These arguments are broken down into small inference steps with clearly defined acceptance criteria. Rather than evaluating large blocks of information, we focus on small, specific steps of the argument. If any step is incomplete — for example, if a testing task is incomplete — this is easily identified.
The reasoning steps are interconnected and form a coherent whole. When contextual inconsistencies are identified, specific areas for improvement can be pinpointed. For instance, a component’s operating environment requirements may be incompatible with the target system environment.
Argumentation is a permanent record of information. If we identify incorrect argumentation steps, this is recorded and we can track it until it’s resolved. A complete review and argument change history is maintained. We monitor the process of progress to the point when the argument is fully approved.
Arguments maintain links to the documentation, from system-level goals such as safety, security or compliance, through the design and testing evidence, to the operational documentation. If we identify a gap or error in an argument, we can easily link it to the system’s defined requirements and goals.
With this argument in place, we can produce a review report. This report provides evidence that the AI tasks are overseen by humans. This evidence is important for system certification.

In this way assurance cases can be used to verify the work products generated by AI. Although we cannot avoid human analysis of the documentation, this approach is easier for humans.

Are you planning to use assurance case arguments to verify AI-generated results? Or perhaps you are already doing so? Share your comments.

Artykuł Verification of AI-generated work products with assurance cases pochodzi z serwisu 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 it 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 strategies like “Argue by testing / analysis / process compliance” avoiding analysis if this is 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 whether 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 of the remaining residual risk. Say you fully test and 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 or 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 ansurance 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.

SPI indicators in dynamic assurance cases

Andrzej Wardziński — Wed, 10 Sep 2025 12:51:35 +0000

Assurance cases are used not only during system development but also during operation. For many systems, Safety Performance Indicators (SPIs) are used in this context. They are used to monitor and report the system safety performance over time. They help to identify whether safety goals are being achieved and provide early warning signals of emerging risks. They are also useful in identifying weaknesses in the safety management system.

Assurance cases should not ignore SPIs, as they provide essential information about the system safety during its operation. However the nature of these indicators is different from regular assurance case evidence. SPI values change over time, so the argument must be able to handle this variability. We need dynamic assurance cases that can react to changes of the reported SPI.

Assurance case process to incorporate SPI data

There are three steps of this process that can be performed automatically:

Transfer the SPI data. The goal is to connect to the SPI measurement system and transfer SPI data into evidence references in the assurance case. SPI data is maintained as dynamic evidence within the argument. This means that data in the argument can be updated daily or more frequently when needed. We use a simple generic data format for SPI values in PREMIS that can represent any type of values, including textual and numerical information.
Interpret the SPI data. This is done by updating the base claim based on the supported SPI evidence. PREMIS allows to define conditions on SPI values to determine the resulting claim assessment. There are three possible statuses for SPI indicators: the SPI status can be OK (acceptable risk level), Warning (risk soon) and Alert (at risk).
Propagate the SPI status information. PREMIS assessment propagation mechanism automatically updates the assessment in the assurance case. Depending on the argument structure, changes of the SPI indicators values may affect the assessment of related claims in the argument, including the top claim. Exceeding the threshold of a single critical SPI indicator may even result in the top claim being rejected.

This process is fully automated when PREMIS arguments are connected to source systems that provide SPI values. This could be a single system integrating all SPIs, or it could be multiple source systems reporting individual metrics. It could be any system that provides network access to its data (an API) or has the ability to transmit the data in any other way, for example by email. We use Jira integrated with PREMIS as the main source of SPI data.

Dynamic evidence, such as SPIs, changes the way arguments are handled. The point is that, most of the time, dynamic evidence works like regular evidence, but it can occasionally turn into counter-evidence. This happens when the indicator’s value indicates that some security requirements are not met. The system’s safety or security argument can only be accepted if the measurement data confirms that the system actually meets the safety and security goals. When a dynamic proof indicates that this is not the case, a response is required, not by changing the argument, as is the case with defeaters, but by changing the value of the evidence – in this case, the SPI indicator. It’s the system operation that needs to be corrected. The argument needs any changes only when the system or the operation process is modified. If the correction involves design changes or the release of a new system version, the relevant parts of the argument should also be updated. Regardless of the associated argumentation changes, it is essential that the dynamic evidence reverts to its accepted state, so that it no longer acts as counter-evidence.

How does it work in practice?

A simple example of a Safety Performance Indicator is the number of open safety issues in Jira. We can have an epic in Jira for collecting safety issues in one place, or a filter to select issues covered by the indicator. Let’s say we have a safety epic and all safety issues should be linked to it as sub-issues. Some issues may not be relevant and we define the SPI as a number of open security issues with major or critical priority. If the indicator value exceeds zero, it should report an ALARM. This can be represented by the following rules in PREMIS:

In some cases we may want to add a WARNING state to be used when the indicator value is close to the limit, but the limit is not exceeded yet.

Depending on the settings of your assurance case the result of the SPI value verification can affect the status of the supported base claim and other claims up the argument structure to the top claim. The diagram below shows an example where the SPI measurement implemented as argument evidence resulted in a WARNING status of the supported base claim, which is then propagated up to the top claim. The top claim can only be accepted when all SPI indicators report the status OK.

Although assurance cases are not intended for tracking safety issues and managing their resolution, they should maintain the current status of system safety. Assurance cases are live artefacts, and one aspect of this involves the use of dynamic evidence, such as performance indicators.

PREMIS supports dynamic evidence, including SPI reporting where you can define rules and conditions when an alarm, a warning or the OK status should be reported.

Contact us if you have questions or want more information how they could be used in your assurance cases.

Artykuł SPI indicators in dynamic assurance cases pochodzi z serwisu Argevide.