Argevide

Accelerate assurance case development with AI

Andrzej Wardziński — Fri, 09 Oct 2026 20:45:21 +0000

An assurance case is rarely created in one go. The argument matures with the system: it is developed, commented on, supplemented, reviewed and corrected, and each of these steps requires the time and effort of experienced engineers. Below, we show how this cycle can be accelerated by using AI tools connected to PREMIS via MCP. Importantly, users can work with their own AI tools that they are already familiar with, and these tools may already have knowledge of the system the argument is about.

AI support for work on assurance cases

The Model Context Protocol (MCP) is an open standard that allows language models to use functions exposed by an application. Through the MCP interface, PREMIS provides AI tools with the same operations that an engineer uses: reading the assurance case, creating elements with links, editing and moving elements, modifying relationships, and adding comments with a priority. The AI is not limited to producing content in the chat window; it can work directly on the argument the team is developing. The user still decides whether the AI only proposes changes or actually applies them to the argument in PREMIS.

The user controls the AI’s involvement in the work on the assurance case in two ways. The first is technical: permissions in PREMIS. If the access token grants read-only permissions, the AI cannot modify the argument. The second is the instructions the user gives to their own AI tool, which determine what the AI does in the chat and what actions it performs on the argument in PREMIS.

Using an engineer’s own AI tool also gives them the ability to manage access to documentation or system models that are used as evidence in the argument. As a result, the AI tool may already have knowledge of the system the argument is about when it starts working on an assurance case and connects to PREMIS for the first time. This allows the AI to develop and review the argument more effectively.

AI-supported activities

As a simple example, consider a functional safety argument containing a claim about hazard identification and analysis. Let’s assume that this claim is supported by only one piece of evidence, the HARA report. This example is shown in the video below. Although the HARA report is the main evidence and usually refers to the full hazard analysis documentation, relying on this report alone is a major simplification and leaves out any argument about the hazard analysis process itself. For example, the auditor is given no justification that all hazards have been identified and has to infer this from the report. As a result, the auditor has to analyse the HARA report themselves and can only accept or reject it as a whole. Such oversimplified arguments, which shift analytical work onto auditors, should be identified during reviews.

The first activity in which AI can support an engineer is reviewing the argument. The AI can carry out the review, while the engineer defines its scope and criteria. The results of the review can be presented in the chat or saved in the argument as prioritised comments. For the claim mentioned above, the review comment should point out the need to develop the argument instead of referring to only one piece of evidence.

The second activity is proposing and discussing changes. The AI presents a specific change proposal that can be discussed. The engineer can evaluate the proposed change, indicate the elements to be corrected, and finally accept or reject it. It is important for the expert to confirm whether the AI correctly understands a given part of the argument. On the one hand, the AI can point out weaknesses in the argument that a human has missed, and on the other hand, every comment and suggested change must be analysed and verified by an expert. A change can be discussed for as long as necessary before it is accepted.

Making changes is the third activity. Changes can be scattered and affect many places in the argument. Having the AI make such changes often saves considerable time compared with doing them manually. After making a change, the AI tool reports the scope of the change, for example by listing the added or modified elements. How the change is presented depends on its type: for modified elements, the before and after states are shown.

The next important activity is tracking how the review findings are addressed and verifying the changes made. The AI tool summarises the changes made, how many review comments have been addressed and how many are still outstanding. If the review findings exist only in the AI chat, progress can only be tracked there. If they are recorded as comments in PREMIS, progress can be tracked independently of the AI, including by other team members. Systematically handling review comments is as important as the review itself. To close the review, we need to be sure that each comment has been checked and either addressed or rejected with justification

Process efficiency

The main goals are, of course, to make the process more efficient and effective. Work on the assurance case requires the involvement of experts, so any reduction in their workload is a measurable saving. All work must be carried out under expert supervision, but some tasks can be successfully delegated to AI tools. In practice, a model in which AI advises on changes to the argument or checks them works well. To make the best use of experts’ time, it is also worth using AI to identify minor inconsistencies, reference or versioning errors, typos, and inaccurate wording. While these issues are of little substantive importance, they can be time-consuming, especially if detected late. Overall, the involvement of AI in assurance case work enables experts to focus more on the conceptual aspects of the argument and assessing its strength, rather than on mechanical editing tasks. The MCP interface in PREMIS makes this possible. PREMIS thus becomes a platform for discussion and collaboration between the engineering team and AI, ensuring high process efficiency.

However, these efficiency gains come with risks. Insufficient or absent expert supervision can lead to serious problems with the quality of the argument. If the certification body or regulator finds problems, the result may be rejection due to errors and misuse of AI, as illustrated by FDA Warning Letter 320-26-58 issued in April 2026. The benefits of using AI can only be achieved if it remains a tool for the expert, who is responsible for the quality of the assurance case at all times. AI can support the expert, but it is up to them to decide which tasks can be delegated to the AI. The role of AI is to be an assistant to engineers, and this approach is supported by PREMIS.

Artykuł Accelerate assurance case development with AI pochodzi z serwisu Argevide.

Audit trail in PREMIS and ALCOA+

Andrzej Wardziński — Thu, 03 Sep 2026 15:10:51 +0000

Auditability is an important aspect of systems used in critical industries, such as automotive, energy, aviation or pharmaceuticals. In the latter, the term audit trail is used, which means an automatically created and secured record of the history of activities performed in the system. PREMIS implements audit trail records in accordance with the ALCOA+ principles, which ensure the effectiveness and usability of these records.

What is an audit trail?

An audit trail involves the automatic collection of data to identify who created, modified or deleted what data and when, while preserving the initial and new values. The aim is to ensure the integrity, traceability and accountability of the data and enable the reproduction of events during an audit or inspection. Below, we will break this down into more detailed requirements and demonstrate their implementation in PREMIS.

This mechanism protects against data manipulation, falsification and unauthorised changes, and enables you to determine responsibility for individual data and changes within the system. This makes it a key aspect of quality management systems, with a wide range of applications. It is also a prerequisite for effective system security (cybersecurity). An audit trail does not protect data against attacks; rather, it provides the basis for analysing events and accounting for activities. In section 3.3, ‘Audit and Accountability‘, NIST SP 800-53 defines ‘audit records’ (AU-3), which are equivalent to audit trails. The audit trail is fundamental to many industries and applications. Therefore, PREMIS has been designed from scratch to ensure its effective use.

The audit trail itself is defined in Annex 11 of the Good Manufacturing Practice (GMP) guidelines, which are the fundamental regulations for the pharmaceutical industry. It is also defined in the ‘Best Practices for Data Management and Data Integrity in GMP/GDP Regulated Environments’ guidelines. In the US, the main relevant regulation is 21 CFR Part 11 (Electronic Records; Electronic Signatures). The use of an audit trail is also related to good practices for ensuring data integrity, namely ALCOA+, which we will discuss in more detail below. Without ensuring data integrity in accordance with ALCOA+, an audit trail alone is not very effective.

How PREMIS implements the audit trail

PREMIS implements a data management mechanism that records changes to the data, saving each subsequent version in the database. This includes all assurance case argumentation data, including assessment and references to evidence. If the evidence is stored in PREMIS-managed repositories, it is also included. This allows the history of changes to be presented for each element of the argument, as well as at the level of the entire argumentation.

The following audit trail requirements are implemented by PREMIS:

Audit trail records are automatically created for all actions on the argumentation data, and this feature cannot be disabled, even by the PREMIS administrator. The records include all actions relating to the creation, modification and deletion of data.
The audit trail data is complete. Deleted data is marked as such but is still stored in the system for audit purposes.
All records are timestamped in UTC to ensure that the time of each event is clearly determined.
Each version of the data, including earlier versions and the version resulting from the change, is preserved. It is possible to compare the state of the data before and after a change.
Each event is uniquely assigned to an individual user account.
Users and administrators can view the history of changes and data versions (including the full argumentation version), but cannot modify this data.
Access to audit trail data requires dedicated permission.
The audit trail is an integral part of the PREMIS data and is subject to backup and disaster recovery processes.

Below is an example of an argument element’s change history window. Information about who changed what, when, and how much was changed is presented.

Change history is collected for entire assurance case arguments. The window fragment below shows version 1.3 of the argument as of August 28th. You can review the full argument from this version and create a copy to continue further work from that point.

ALCOA+ principles to ensure data integrity

ALCOA was created in the 1990s as an informal mnemonic tool to help FDA inspectors check data integrity. Dr. Stan W. Woollen originated the tool and wrote down these rules as a checklist, creating the acronym ALCOA based on the main words. These words are: Attributable, Legible, Contemporaneous, Original and Accurate. The checklist was so effective that it became popular in the industry, and over time the term began to be used in regulations as well. However, with technological developments after 2010, the ALCOA rules became insufficient, so they were expanded and a plus sign was added to the end of the name. This is how the name ‘ALCOA+’ was created. The most comprehensive description of the rules can now be found in the PIC/S guide PIC/S PI 041-1.

How does PREMIS support ALCOA?

ALCOA, established in the 1990s, encompasses five principles:

Attributable. It must be possible to identify the person or system that performed the recorded action and the time of its execution. This also applies to all data creation, modification, and deletion activities.
Legible. Audit trail data should be legible, meaning it can be easily interpreted. Electronic data should be user-friendly and searchable.
Contemporaneous. Evidence of actions, events, or decisions should be recorded at the time they occur in the system, not replayed later.
Original. The original record is the first capture of information. This exact information should be retained as the audit trail.
Accurate. Audit trail data should contain accurate versions of business data (before and after the change).

The extension marked with a plus sign, included in the ALCOA+ rulebook, includes ALCOA requirements and four new ones:

Complete. All information relevant to event recovery should be recorded, including available metadata. Do not record only the main data items.
Consistent. Information should be created, processed and stored maintaining logical connections, in particular the order (chronology) of events, but also a clearly defined time format, units of measurement or rounding.
Enduring. Data should be stored in such a way that they are available for the entire period in which they may be needed, which formally means maintaining the data throughout the required retention period.
Available. Data should be available for review at any time during the required retention period, in a readable format, by all authorized persons.

All of the above ALCOA+ requirements are implemented by PREMIS.

Practical benefits

In addition to meeting formal requirements, the audit trail at PREMIS provides real operational and business value:

makes it easier to detect errors and abuses before they grow into a serious quality problem;
shortens the time of preparation for audits and inspections, and at the same time reduces stress and the risk of new comments (observations);
facilitates the analysis of deviations and the determination of the sequence of events;
increases trust and responsibility in teams when, on the one hand, everyone knows that their actions can be checked, but there is also no risk of unfounded accusations;
gives the possibility of reconstructing historical data and resuming work on its basis, which makes it possible to reduce the consequences of erroneous actions in business processes;
It allows you to conduct analyses of the occurrence of errors or user behavior over a long period of time.

The audit trail and the ALCOA+ rules are not only a formal requirement, but a useful business practice that reduces the risk of errors in processes and provides the basis for effective actions in exceptional situations. From the early stages of work, PREMIS has been designed and developed in accordance with these principles.

Artykuł Audit trail in PREMIS and ALCOA+ pochodzi z serwisu Argevide.

Building CRA conformance with PREMIS

Andrzej Wardziński — Fri, 21 Aug 2026 06:32:13 +0000

PREMIS implements a goal-oriented approach, which is effective in achieving and controlling compliance with regulations such as the CRA (Cyber Resilience Act). Achieving cyber resilience requires coordinated processes and maintaining the consistency and currency of many of their results as evidence of compliance. PREMIS makes this easier. There is no substitute for an efficient technical process for monitoring cybersecurity or handling vulnerabilities and incidents, but effective oversight of all processes to achieve and maintain compliance with CRA and other related regulations and standards is equally important.

CRA goes into effect

The Cyber Resilience Act introduces new requirements for manufacturers of products containing digital elements. These include product cybersecurity, vulnerability management, incident reporting, technical documentation, compliance assessment, and security maintenance throughout the product’s support lifecycle.
The regulation is being implemented in two stages. From September 11, 2026, it becomes mandatory to notify actively exploited vulnerabilities and serious incidents.

The full application of the regulation – including but not limited to product safety requirements, secure updates, technical documentation, conformity assessment and cooperation with authorities – will be required from 11 December 2027. It is worth implementing new areas gradually to consistently build and maintain a high level of cyber resilience of products.

The areas of CRA requirements and the scope applicable to each of the two stages of the implementation of the regulation are shown in the tables below. This layout is mapped in the compliance template in PREMIS.

How does PREMIS supports CRA compliance?

Goal-oriented compliance means managing relationships between compliance objectives, specific requirements, and records and evidence of compliance. For CRA, this is complemented by relations between product versions, threat models, SBOMs, security testing and corrective actions, and technical documentation. This allows you to trace the path from a single CRA requirement to a specific proof of its implementation. This evidence is monitored and kept up to date. Thanks to this, audit readiness is maintained and there is no problem of preparing documentation only during the preparation for the audit.

Key capabilities of PREMIS include:
‒ decomposition of CRA requirements into specific, enforceable duties,
‒ assigning responsibility for the implementation of individual requirements,
‒ collecting and assessing evidence of compliance along with checking its up-to-dateness,
‒ support for communication of all people involved for quick detection and resolution of problems,
‒ traceability between requirements, risks, documentation and products,
‒ Real-time compliance status monitoring,
‒ maintaining audit readiness.

CRA does not apply to a single project, but to the entire product portfolio of an organization. PREMIS enables you to reuse compliance templates, manage multiple products at once, apply a unified approach across teams, and monitor supplier and subcontractor compliance. This ensures that the process remains efficient even in large organizations that manage multiple products and versions.

Continuous process for audit readiness

PREMIS helps transform CRA compliance from a one-time project into a structured, repeatable, and scalable process. An organization can start with a single product and then expand seamlessly into other CRA areas, as well as related regulations and standards. Throughout this growth, it maintains consistency, timeliness, and control over all processes. This is possible thanks to a goal-oriented approach, full traceability of requirements and evidence, and ongoing audit readiness.

The template contains about 100 requirements with suggested evidence and recommendations and comments on what auditors are looking for. At the same time, it is a platform for cooperation between different people and teams. The compliance team typically manages the entire compliance model, and individual teams, including DevSecOps, provide evidence of compliance. Much of this data can be automatically processed by PREMIS, but human supervision over the processes is still crucial.

CRA is a product cybersecurity regulation, and some organizations may also be subject to standards or regulations related to organizational security, such as NIS 2 or ISO 27001. These are two distinct perspectives, but their implementation shares common security controls. The processes are therefore highly integrated. Even so, each regulation or standard requires its own separate compliance demonstration.

The CRA template is easy to use and gives a lot of information and recommendations to support the process. Read more information on the CRA service page. Write to us when you have any questions. We will be happy to support you in an effective implementation

Artykuł Building CRA conformance with PREMIS pochodzi z serwisu Argevide.

Assurance case architecture for space systems

Andrzej Wardziński — Tue, 14 Jul 2026 04:27:01 +0000

Space systems are developed using rigorous processes. In Europe, these are most often in accordance with ECSS (European Cooperation for Space Standardization) standards. These standards describe processes that ensure a high level of safety and reliability in the execution of missions. While the use of assurance cases is not explicitly required by ECSS standards, they are often used in practice for complex systems as an element of verification in the project reviews of subsequent phases of the system life cycle.

The context of space projects and ECSS standards

Before moving on to the subject of argumentation for space systems, it should be said that the processes related to such systems are tightly organised throughout development up to flight acceptance, then during operation, which can last many years, until disposal. Strict rules regarding requirements management, testing, verification and validation, and reviews are applied. Reviews continuously generate RIDs (Review Item Discrepancy) requests, the resolution of which is tracked. The gates of the successive phases are defined and the conditions for passing through them are precisely defined. We are talking primarily about the ECSS standards used in Europe, but NASA’s standards are equally rigorous. In such formalised processes, is the use of an assurance case an additional formality, or does it offer benefits?

We would probably not recommend using an assurance case for small CubeSat projects, given the low level of complexity involved. However, it complements the system development process well in larger projects. ECSS standards specify the actions to be taken and the artefacts to be produced. The assurance case demonstrates why you can trust that the system actually possesses the required properties. The argumentation should not merely be a checklist of the standard’s requirements because otherwise we would lose the benefits of using it. Rather, it should present a logical sequence from objectives through argumentation and justification to evidence, all the while remaining in compliance with ECSS standards.

An assurance case helps identify gaps, such as missing evidence.
It improves reviews. For reviewers, it allows reviewers to easily trace from objectives to the supporting evidence.
It makes it easier to scope and manage changes.
It supports communication between the different groups involved in the project.
It documents decisions and their justification, which can be useful especially in long-term projects.

Assurance case architecture

As part of our work, we have developed an assurance case architecture that can be used for various systems where ECSS standards apply, assuming a small level of customisation. Our focus is on unmanned missions, excluding any aspects of planetary missions or return to Earth.

The architecture is organised as a modular assurance case. Each module has a clearly defined purpose and scope of responsibility. MAC (Mission Assurance Case) integrates all lower-level arguments and supports lifecycle phase decisions. MA demonstrates that mission objectives are achievable. TA demonstrates that the system possesses the required technical properties and is decomposed into Safety (TA1), Dependability (TA2), Software Assurance (TA3) and Cybersecurity (TA4) modules. CA demonstrates why the argument should be trusted and is decomposed into Verification & Validation (CA1) and Product Assurance (CA2) modules. OP addresses operational capability, while RG addresses residual risk acceptance and governance. The module diagram below presents all the modules of the assurance case. The argument is still under development, but the architecture appears stable.

The diagram uggests that the modules support the main MAC module while being independent of each other; this, however, is a simplification of the diagram itself. The MA/TA/OP modules share evidence with the RG module, which includes holistic risk management. The binding of these modules to CA modules, which can be called the confidence argument, is done by contracts, which is not shown in the diagram.

Argument evolution

Modules evolve through successive phases of the system life cycle. The first phase, Phase 0 (Mission Analysis), is unique. During this phase, the purpose of the assurance case is not to demonstrate that the system meets the requirements, but rather to show that the system can be built and the mission objectives achieved, that no unacceptable risks have been identified at the mission level and that there are no significant technical or operational barriers. This argument is simpler than the full architecture presented above.

The architecture is applicable starting from Phase A (Feasibility). In each subsequent phase, the argumentation is expanded to include further groups of evidence. In Phase A, these are mainly feasibility analyses and preliminary models. Phase B (Preliminary Definition) adds analyses, engineering designs and budgets. Phase C (Detailed Definition) extends the assurance case with detailed design, safety analyses (FTA, FMECA) and reviews. Full verification and independent assessment are carried out in phase D (Qualification & Acceptance), which ends with a Flight Acceptance Review (FAR).

In Prase E (Utilisation), which can last several years (excluding a short subphase E1 – Launch and Early Orbit Phase), operational data is used. The purpose of the argument is to maintain confidence that the mission objectives are being achieved. To a limited extent, there may be changes to the system itself, such as software updates.This argument is simpler than the full architecture presented above.”

Summary

The presented assurance case architecture is oriented towards the characteristics of the system, which corresponds to the main perspective of reviewers. The full life cycle of such an argumentation spans several years. They have clearly defined responsibilities and can use common evidence through explicit contracts or dependencies between modules. Thanks to this, the architecture is scalable and allows for gradual maturation of the argumentation from phase 0 to phase F. At the same time, it supports reviews carried out in subsequent phases, including the aforementioned FAR, which is the main decision-making point allowing the system to fly.

The architecture of the argument evolves with the successive phases of the system’s life cycle. This architecture will be maintained for a few years. Although we have discussed the basic assumptions of this architecture, there are still many important related topics. These will be covered in subsequent posts.

The presented assurance case architecture is developed as part of a project carried out jointly with the Gdańsk University of Technology.

Andrzej Wardziński

Share your comments

Artykuł Assurance case architecture for space systems pochodzi z serwisu 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.