pith. sign in

arxiv: 2606.11462 · v1 · pith:RL3ALU7Mnew · submitted 2026-06-09 · 💻 cs.SE

Defeater Cards: Characterizing and Managing Safety Assurance Case Defeaters

Usman Gohar , Michael C. Hunter , Salil Purandare , Jordan J. Rios , Myra B. Cohen , Robyn R. Lutz This is my paper

Pith reviewed 2026-06-27 12:05 UTC · model grok-4.3

classification 💻 cs.SE
keywords defeater cardssafety assurance casesdefeaterssafety casesdocumentation standardstraceabilityknowledge reuse5W1H framework
0
0 comments X

The pith

Defeater Cards supply a 5W1H template to document and manage challenges to safety assurance cases.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Safety assurance cases justify that critical systems meet their safety requirements, yet defeaters such as unreliable evidence or reasoning gaps are typically described ad hoc and without standards. The paper introduces Defeater Cards as a new structured documentation artifact derived from a literature survey and thematic analysis that applies the 5W1H framework. The cards are intended to enable systematic characterization of each defeater, support analysis and evolution of the overall case, improve traceability and auditability, and allow reuse of defeater knowledge across systems and product variants. Two cross-domain case studies illustrate how the cards surface hidden assumptions and reasoning gaps.

Core claim

Defeater Cards are a structured documentation artifact for systematically characterizing, reasoning about, and managing defeaters in safety cases. Their structure is informed by documentation criteria identified through literature survey and thematic analysis using the 5W1H framework. The cards are designed to support informed analysis and evolution, improve traceability and auditability, and enable the reuse of defeater knowledge across systems and product variants.

What carries the argument

Defeater Cards, a template organized by the 5W1H questions to capture what the defeater is, who raises it, when and where it applies, why it matters, and how it is addressed.

Load-bearing premise

The documentation criteria identified via literature survey and thematic analysis using the 5W1H framework are sufficient to systematically address the ad hoc, inconsistently described nature of defeaters in safety cases.

What would settle it

A safety case review in which experts equipped with Defeater Cards still fail to document a defeater that is later shown to invalidate a key safety claim.

Figures

Figures reproduced from arXiv: 2606.11462 by Jordan J. Rios, Michael C. Hunter, Myra B. Cohen, Robyn R. Lutz, Salil Purandare, Usman Gohar.

Figure 1
Figure 1. Figure 1: sUAS Safety Assurance Case fragment with example defeaters [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Structural overview of the Defeater Card: Categorizing identi [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Proposed Defeater Card template with sections based on 5Ws, 1H framework to support dialectic reasoning. B. The What? (Identification and Evaluation) The first question focuses on what is being evaluated, identifying which part of the assurance case is being challenged and providing the necessary context. Affected Node(s): This captures the assurance case node impacted by the defeater. A single defeater ca… view at source ↗
Figure 4
Figure 4. Figure 4: Example Defeater Card for an sUAS Assurance Case. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Example Defeater Card for a Molecular Program [84] Assurance Case. [PITH_FULL_IMAGE:figures/full_fig_p010_5.png] view at source ↗
read the original abstract

Safety assurance cases provide structured justifications that safety-critical systems meet their safety requirements. Recently, the notion of defeaters has emerged as a rigorous means of challenging the validity of safety arguments. Examples of defeaters might include overly strict claims, unreliable evidence, or reasoning gaps. However, defeaters remain ad hoc, lack structured support for critical reflection, are inconsistently described, are difficult to review, and lack documentation standards. To address this, we propose Defeater Cards, a new structured documentation artifact for systematically characterizing, reasoning about, and managing defeaters in safety cases. Drawing on a literature survey and thematic analysis, we identify documentation criteria that inform the card's structure, based on the 5W1H framework. Defeater Cards are designed to support informed analysis and evolution, improve traceability and auditability, and enable the reuse of defeater knowledge across systems and product variants. We demonstrate their applicability through two cross-domain case studies, showing how they expose hidden assumptions, surface reasoning gaps, and support ongoing safety assurance case evolution. To support adoption and community reuse, we also release an open-source repository of defeater cards as a baseline upon which researchers and practitioners can build and describe lessons learned.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper proposes Defeater Cards, a structured documentation artifact for characterizing, reasoning about, and managing defeaters in safety assurance cases. Drawing on a literature survey and thematic analysis using the 5W1H framework, it identifies documentation criteria to address the ad hoc and inconsistently described nature of defeaters. The cards are intended to support analysis, evolution, traceability, auditability, and reuse across systems and variants. Applicability is demonstrated through two cross-domain case studies that expose hidden assumptions and reasoning gaps, and an open-source repository of cards is released as a reusable baseline.

Significance. If the cards prove effective in practice, the work could standardize defeater handling in safety cases for safety-critical systems, a key area in software and systems engineering. The release of the open repository supports reproducibility, community reuse, and incremental extension, which are positive contributions to the field.

major comments (2)
  1. [Methods (literature survey and thematic analysis)] The section describing the literature survey and thematic analysis does not report the number of papers surveyed, the exact coding protocol, inter-rater reliability statistics, or how disagreements among coders were resolved. These details are needed to assess whether the 5W1H-derived documentation criteria are robust and comprehensive enough to systematically address the ad hoc nature of defeaters.
  2. [Case studies section] The two case studies are presented as demonstrations of applicability rather than controlled evaluations. The paper does not provide concrete metrics or before/after comparisons showing that the cards measurably improve traceability or reduce reasoning gaps, which weakens the claim that they enable systematic management.
minor comments (2)
  1. [Abstract] The abstract mentions 'two cross-domain case studies' but does not name the domains; adding this would improve clarity for readers.
  2. [Defeater Cards structure] Notation for the 5W1H criteria could be presented in a table for easier reference when the cards are described.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive review and recommendation for minor revision. We address each major comment below.

read point-by-point responses

  1. Referee: [Methods (literature survey and thematic analysis)] The section describing the literature survey and thematic analysis does not report the number of papers surveyed, the exact coding protocol, inter-rater reliability statistics, or how disagreements among coders were resolved. These details are needed to assess whether the 5W1H-derived documentation criteria are robust and comprehensive enough to systematically address the ad hoc nature of defeaters.

    Authors: We agree that greater methodological transparency is warranted. In the revised manuscript we will expand the relevant section to report the number of papers surveyed, describe the coding protocol in detail, provide inter-rater reliability statistics, and explain how coder disagreements were resolved. These additions will allow readers to evaluate the robustness of the derived criteria. revision: yes

  2. Referee: [Case studies section] The two case studies are presented as demonstrations of applicability rather than controlled evaluations. The paper does not provide concrete metrics or before/after comparisons showing that the cards measurably improve traceability or reduce reasoning gaps, which weakens the claim that they enable systematic management.

    Authors: The case studies are deliberately framed as demonstrations of applicability, consistent with the manuscript's stated claims of showing how the cards expose hidden assumptions and reasoning gaps. The paper does not advance quantitative claims about measurable improvements, which would require a different study design. We will add a short discussion of possible future metrics and evaluation approaches to clarify the intended scope. revision: partial

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper is a methodological proposal for Defeater Cards, constructed via external literature survey and thematic analysis under the 5W1H framework. No equations, parameters, derivations, or self-referential fitting exist. The central claim (structured documentation criteria suffice to systematize defeater handling) is grounded in cited external sources rather than reducing to the paper's own inputs or self-citations. Case studies function as applicability demonstrations, not closed-loop validations. The work remains self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the assumption that safety assurance cases are the appropriate context and that structured documentation will meaningfully improve their management; no free parameters or invented physical entities are involved.

axioms (1)
  • domain assumption Safety assurance cases provide structured justifications that safety-critical systems meet their safety requirements.
    Stated in the opening sentence of the abstract as the foundational context for the work.
invented entities (1)
  • Defeater Cards no independent evidence
    purpose: Structured documentation artifact for characterizing, reasoning about, and managing defeaters using 5W1H criteria.
    New artifact introduced by the paper; no independent evidence outside the proposal itself is provided in the abstract.

pith-pipeline@v0.9.1-grok · 5765 in / 1393 out tokens · 27756 ms · 2026-06-27T12:05:28.220759+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

88 extracted references · 6 canonical work pages

  1. [1]

    Software considerations in airborne systems and equip- ment certification,

    RTCA, “Software considerations in airborne systems and equip- ment certification,”DO-178C, 2011

    2011

  2. [2]

    ISO 26262 safety cases: Compliance and assurance,

    R. Palin, D. Ward, I. Habli, and R. Rivett, “ISO 26262 safety cases: Compliance and assurance,” 2011

    2011

  3. [3]

    A safety stan- dard approach for fully autonomous vehicles,

    P. Koopman, U. Ferrell, F. Fratrik, and M. Wagner, “A safety stan- dard approach for fully autonomous vehicles,” inSAFECOMP. Springer, 2019, pp. 326–332

    2019

  4. [4]

    Assurance case guidance,

    Assurance Case Working Group, “Assurance case guidance,” ACWG, Tech. Rep. SCSC-159, 2021

    2021

  5. [5]

    Assurance 2.0: A manifesto,

    R. Bloomfield and J. Rushby, “Assurance 2.0: A manifesto,” arXiv preprint arXiv:2004.10474, 2020

    work page arXiv 2004

  6. [6]

    Knight,Fundamentals of Dependable Computing for Software Engineers

    J. Knight,Fundamentals of Dependable Computing for Software Engineers. CRC Press, 2012

    2012

  7. [7]

    A survey of tool- supported assurance case assessment techniques,

    M. Maksimov, S. Kokaly, and M. Chechik, “A survey of tool- supported assurance case assessment techniques,”ACM Comput- ing Surveys (CSUR), vol. 52, no. 5, pp. 1–34, 2019

    2019

  8. [8]

    AdvoCATE: An assurance case automation toolset,

    E. Denney, G. Pai, and J. Pohl, “AdvoCATE: An assurance case automation toolset,” inSAFECOMP. Springer, 2012, pp. 8–21

    2012

  9. [9]

    The goal structuring notation–a safety argument notation,

    T. Kelly and R. Weaver, “The goal structuring notation–a safety argument notation,” inDSN workshop on assurance cases. Cite- seer, 2004

    2004

  10. [10]

    Clarissa: Foundations, tools & automation for assurance cases,

    S. Varadarajan, R. Bloomfield, J. Rushby, G. Gupta, A. Mu- rugesan, R. Stroud, K. Netkachova, and I. H. Wong, “Clarissa: Foundations, tools & automation for assurance cases,” inDASC, 2023, pp. 1–10

    2023

  11. [11]

    Handling obstacles in goal- oriented requirements engineering,

    A. van Lamsweerde and E. Letier, “Handling obstacles in goal- oriented requirements engineering,”IEEE TSE, vol. 26, pp. 978– 1005, 2000

    2000

  12. [12]

    Towards measurement of confidence in safety cases,

    E. Denney, G. Pai, and I. Habli, “Towards measurement of confidence in safety cases,” inESEM. IEEE, 2011, pp. 380–383

    2011

  13. [13]

    Elimina- tive induction: A basis for arguing system confidence,

    J. B. Goodenough, C. B. Weinstock, and A. Z. Klein, “Elimina- tive induction: A basis for arguing system confidence,” inICSE, 2013, pp. 1161–1164

    2013

  14. [14]

    A taxonomy of real-world defeaters in safety assurance cases,

    U. Gohar, M. C. Hunter, M. B. Cohen, and R. R. Lutz, “A taxonomy of real-world defeaters in safety assurance cases,” in2025 IEEE/ACM Workshop on Multi-disciplinary, Open, and RElevant Requirements Engineering (MO2RE). IEEE Computer Society, Apr. 2025, pp. 3–9

    2025

  15. [15]

    Obstacle analysis in re- quirements engineering: Retrospective and emerging challenges,

    E. Letier and A. van Lamsweerde, “Obstacle analysis in re- quirements engineering: Retrospective and emerging challenges,” IEEE Trans. Software Eng., vol. 51, no. 3, pp. 795–801, 2025

    2025

  16. [16]

    An independent review into the broader issues sur- rounding the loss of the RAF Nimrod MR2 Aircraft XV230 in Afghanistan in 2006,

    C. Cave, “An independent review into the broader issues sur- rounding the loss of the RAF Nimrod MR2 Aircraft XV230 in Afghanistan in 2006,”The Stationary Office, Tech. Rep, 2006

    2006

  17. [17]

    SafeCert: Towards automated safety-case generation for risk assessment in small uncrewed aerial vehicles,

    M. C. Hunter, U. Gohar, S. Purandare, K. Kjeer, R. Lutz, B. A. Duncan, J. Cleland-Huang, and M. Cohen, “SafeCert: Towards automated safety-case generation for risk assessment in small uncrewed aerial vehicles,” inAIAA AVIATION FORUM AND ASCEND 2025, 2025, p. 3169

    2025

  18. [18]

    Se- mantic analysis of assurance cases using s(CASP),

    A. Murugesan, I. H. Wong, R. J. Stroud, J. Arias, E. Salazar, G. Gupta, R. Bloomfield, S. Varadarajan, and J. Rushby, “Se- mantic analysis of assurance cases using s(CASP),” inICLP Workshops, 2023

    2023

  19. [19]

    Understand- ing and evaluating assurance cases,

    J. Rushby, X. Xu, M. Rangarajan, and T. L. Weaver, “Understand- ing and evaluating assurance cases,”NASA, no. 20160000772, 2015

    2015

  20. [20]

    ATTEST: Automating the review and update of assurance case arguments,

    F. U. Muram and M. A. Javed, “ATTEST: Automating the review and update of assurance case arguments,”Journal of Systems Architecture, vol. 134, p. 102781, 2023

    2023

  21. [21]

    Automatically detecting fallacies in system safety arguments,

    T. Yuan, S. Manandhar, T. Kelly, and S. Wells, “Automatically detecting fallacies in system safety arguments,” inPrinciples and Practice of Multi-Agent Systems: International Workshops: IWEC 2014, and CMNA XV and IWEC 2015. Springer, 2016, pp. 47– 59

    2014

  22. [22]

    CoDe- feater: Using LLMs to find defeaters in assurance cases,

    U. Gohar, M. C. Hunter, R. R. Lutz, and M. B. Cohen, “CoDe- feater: Using LLMs to find defeaters in assurance cases,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, p. 2262–2267

    2024

  23. [23]

    AI-Supported Eliminative Argumentation: Practical Experience Generating Defeaters to Increase Confidence in Assurance Cases,

    T. Viger, L. Murphy, S. Diemert, C. Menghi, J. Joyce, A. D. San- dro, and M. Chechik, “AI-Supported Eliminative Argumentation: Practical Experience Generating Defeaters to Increase Confidence in Assurance Cases,” inISSRE. IEEE, 2024

    2024

  24. [24]

    Ai documentation: A path to accountability,

    F. Königstorfer and S. Thalmann, “Ai documentation: A path to accountability,”Journal of Responsible Technology, vol. 11, p. 100043, 2022

    2022

  25. [25]

    Using obstacle analysis to identify contingency re- quirements on an unpiloted aerial vehicle,

    R. R. Lutz, A. Patterson-Hine, S. Nelson, C. R. Frost, D. Tal, and R. Harris, “Using obstacle analysis to identify contingency re- quirements on an unpiloted aerial vehicle,”Requir. Eng., vol. 12, no. 1, pp. 41–54, 2007

    2007

  26. [26]

    Engineering and verifying requirements for programmable self-assembling nanomachines,

    R. R. Lutz, J. H. Lutz, J. I. Lathrop, T. H. Klinge, E. R. Hender- son, D. Mathur, and D. A. Sheasha, “Engineering and verifying requirements for programmable self-assembling nanomachines,” inICSE, 2012

    2012

  27. [27]

    Requirements engineering for safety-critical molec- ular programs,

    R. R. Lutz, “Requirements engineering for safety-critical molec- ular programs,” inRE. IEEE, 2022, pp. 302–308

    2022

  28. [28]

    Safety case templates for autonomous systems,

    R. Bloomfield, G. Fletcher, H. Khlaaf, L. Hinde, and P. Ryan, “Safety case templates for autonomous systems,”arXiv preprint arXiv:2102.02625, 2021

    work page arXiv 2021

  29. [29]

    Assurance case guidance: Challenges, common issues and good practice, version 1,

    A. C. W. Groupet al., “Assurance case guidance: Challenges, common issues and good practice, version 1,”Safety Critical Systems Club, 2021

    2021

  30. [30]

    Model cards revisited: Bridging the gap between theory and practice for ethical ai requirements,

    T. Puhlfürß, J. Butzke, and W. Maalej, “Model cards revisited: Bridging the gap between theory and practice for ethical ai requirements,” inIEEE RE, 2025, pp. 280–291

    2025

  31. [31]

    Red-teaming for generative AI: Silver bullet or security theater?

    M. Feffer, A. Sinha, W. H. Deng, Z. C. Lipton, and H. Heidari, “Red-teaming for generative AI: Silver bullet or security theater?” inAIES, 2024, pp. 421–437

    2024

  32. [32]

    Available: https://www.anthropic.com/news/ evaluating-ai-systems

    [Online]. Available: https://www.anthropic.com/news/ evaluating-ai-systems

  33. [33]

    Dynamic safety cases for through-life safety assurance,

    E. Denney, G. Pai, and I. Habli, “Dynamic safety cases for through-life safety assurance,” inICSE, vol. 2. IEEE, 2015, pp. 587–590

    2015

  34. [34]

    Data cards: Purposeful and transparent dataset documentation for responsible AI,

    M. Pushkarna, A. Zaldivar, and O. Kjartansson, “Data cards: Purposeful and transparent dataset documentation for responsible AI,” inACM FAccT, 2022, pp. 1776–1826

    2022

  35. [35]

    Model cards for model reporting,

    M. Mitchell, S. Wu, A. Zaldivar, P. Barnes, L. Vasserman, B. Hutchinson, E. Spitzer, I. D. Raji, and T. Gebru, “Model cards for model reporting,” inACM FAccT, 2019, pp. 220–229

    2019

  36. [36]

    V olere,

    J. Robertson and S. Robertson, “V olere,”Requirements Specifi- cation Templates, 2000

    2000

  37. [37]

    A family-based approach to safety cases for controlled airspaces in small uncrewed aerial systems,

    M. Hunter, U. Gohar, M. Cohen, R. Lutz, and J. Cleland-Huang, “A family-based approach to safety cases for controlled airspaces in small uncrewed aerial systems,” inAIAA AVIATION FORUM AND ASCEND 2024, 2024, p. 4626

    2024

  38. [38]

    arXiv preprint arXiv:2504.13839 , year =

    L. Staufer, M. Yang, A. Reuel, and S. Casper, “Audit cards: Con- textualizing ai evaluations,”arXiv preprint arXiv:2504.13839, 2025

    work page arXiv 2025

  39. [39]

    Documentation for safety critical software,

    P.-J. Courtois and D. L. Parnas, “Documentation for safety critical software,” inProceedings of 1993 15th International Conference on Software Engineering. IEEE, 1993, pp. 315–323

    1993

  40. [40]

    The interpretation and evaluation of assurance cases,

    J. Rushby, “The interpretation and evaluation of assurance cases,” Comp. Science Laboratory, SRI International, Tech. Rep. SRI- CSL-15-01, 2015. 11

    2015

  41. [41]

    Tool support for assurance case devel- opment,

    E. Denney and G. Pai, “Tool support for assurance case devel- opment,”ASE, vol. 25, no. 3, pp. 435–499, 2018

    2018

  42. [42]

    Mmint-a 2.0: tool support for the lifecycle of model- based safety artifacts,

    A. Di Sandro, G. Selim, R. Salay, T. Viger, M. Chechik, and S. Kokaly, “Mmint-a 2.0: tool support for the lifecycle of model- based safety artifacts,” inACM/IEEE MODELS, 2020, pp. 1–5

    2020

  43. [43]

    Support for argument structures re- view and assessment,

    L. Cyra and J. Gorski, “Support for argument structures re- view and assessment,”Reliability Engineering & System Safety, vol. 96, no. 1, pp. 26–37, 2011

    2011

  44. [44]

    Structured safety case evaluation: a systematic ap- proach to safety case review,

    P. Mayo, “Structured safety case evaluation: a systematic ap- proach to safety case review,” inInternational Conference on System Safety. IET, 2006, pp. 10–pp

    2006

  45. [45]

    Characterizing the chain of evidence for software safety cases: A conceptual model based on the IEC 61508 standard,

    R. K. Panesar-Walawege, M. Sabetzadeh, L. Briand, and T. Coq, “Characterizing the chain of evidence for software safety cases: A conceptual model based on the IEC 61508 standard,” inICST. IEEE, 2010, pp. 335–344

    2010

  46. [46]

    Sys- tematic evaluation of (safety) assurance cases,

    T. Chowdhury, A. Wassyng, R. F. Paige, and M. Lawford, “Sys- tematic evaluation of (safety) assurance cases,” inSAFECOMP Springer, 2020, pp. 18–33

    2020

  47. [47]

    Reasoning about confidence and uncertainty in assurance cases: A survey,

    L. Duan, S. Rayadurgam, M. P. Heimdahl, A. Ayoub, O. Sokol- sky, and I. Lee, “Reasoning about confidence and uncertainty in assurance cases: A survey,” inSEHC, FHIES 2014. Springer, 2017, pp. 64–80

    2014

  48. [48]

    Confidence as- sessment in safety argument structure-quantitative vs. qualitative approaches,

    Y . Idmessaoud, D. Dubois, and J. Guiochet, “Confidence as- sessment in safety argument structure-quantitative vs. qualitative approaches,”IJAR, vol. 165, p. 109100, 2024

    2024

  49. [49]

    Toward a theory of assurance case confidence,

    J. B. Goodenough, C. B. Weinstock, and A. Z. Klein, “Toward a theory of assurance case confidence,”Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2012

    2012

  50. [50]

    Examining proposed uses of llms to produce or assess assurance arguments, NASA/TM–20250001849,

    M. Graydon and S. Lehman, “Examining proposed uses of llms to produce or assess assurance arguments, NASA/TM–20250001849,” Tech. Rep., 2025

    2025

  51. [51]

    LLMs as judges: Toward the automatic review of GSN-compliant assurance cases,

    G. Yu, M. Sivakumar, A. B. Belle, S. Ghari, S. Wang, and T. C. Lethbridge, “LLMs as judges: Toward the automatic review of GSN-compliant assurance cases,”arXiv preprint arXiv:2511.02203, 2025

    work page arXiv 2025

  52. [52]

    Defeaters and eliminative argumentation in Assurance 2.0,

    R. Bloomfield, K. Netkachova, and J. Rushby, “Defeaters and eliminative argumentation in Assurance 2.0,”arXiv preprint arXiv:2405.15800, 2024

    work page arXiv 2024

  53. [53]

    Incre- mental assurance through eliminative argumentation,

    S. Diemert, J. Goodenough, J. Joyce, and C. Weinstock, “Incre- mental assurance through eliminative argumentation,”Journal of System Safety, vol. 58, no. 1, pp. 7–15, 2023

    2023

  54. [54]

    Leveraging artifact trees to evolve and reuse safety cases,

    A. Agrawal, S. Khoshmanesh, M. Vierhauser, M. Rahimi, J. Cleland-Huang, and R. Lutz, “Leveraging artifact trees to evolve and reuse safety cases,” inIEEE ICSE, 2019

    2019

  55. [55]

    Towards dynamic safety assurance for industry 4.0,

    M. A. Javed, F. U. Muram, H. Hansson, S. Punnekkat, and H. Thane, “Towards dynamic safety assurance for industry 4.0,” Journal of Systems Architecture, vol. 114, p. 101914, 2021

    2021

  56. [56]

    Towards continuous safety assurance for autonomous systems,

    P. Schleiss, F. Carella, and I. Kurzidem, “Towards continuous safety assurance for autonomous systems,” inIEEE ICSRS, 2022, pp. 457–462

    2022

  57. [57]

    Facilitating the mainte- nance of safety cases,

    O. Jaradat, I. Bate, and S. Punnekkat, “Facilitating the mainte- nance of safety cases,” inCurrent Trends in Reliability, Avail- ability, Maintainability and Safety: An Industry Perspective. Springer, 2015, pp. 349–371

    2015

  58. [58]

    Safety case maintenance: a systematic literature review,

    C. Cârlan, B. Gallina, and L. Soima, “Safety case maintenance: a systematic literature review,” inSAFECOMP. Springer, 2021, pp. 115–129

    2021

  59. [59]

    The 5Ws and 1H of digital journalism,

    S. Waisbord, “The 5Ws and 1H of digital journalism,” inDef- initions of Digital Journalism (Studies). Routledge, 2021, pp. 38–45

    2021

  60. [60]

    Defining a model for content requirements from the law: An experience report,

    M. Ceci, D. Bianculli, and L. C. Briand, “Defining a model for content requirements from the law: An experience report,” inRE. IEEE, 2024, pp. 18–30

    2024

  61. [61]

    A design science research methodology for information systems research,

    K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design science research methodology for information systems research,”Journal of management information systems, vol. 24, no. 3, pp. 45–77, 2007

    2007

  62. [62]

    Driving the development process from the safety case,

    C. Hobbs, S. Diemert, and J. Joyce, “Driving the development process from the safety case,”Safety-Critical Systems Club, 2024

    2024

  63. [63]

    Who audits the auditors? recommendations from a field scan of the algorith- mic auditing ecosystem,

    S. Costanza-Chock, I. D. Raji, and J. Buolamwini, “Who audits the auditors? recommendations from a field scan of the algorith- mic auditing ecosystem,” inACM FAccT, 2022, pp. 1571–1583

    2022

  64. [64]

    Datasheets for datasets,

    T. Gebru, J. Morgenstern, B. Vecchione, J. W. Vaughan, H. Wal- lach, H. D. Iii, and K. Crawford, “Datasheets for datasets,” Communications of the ACM, vol. 64, no. 12, pp. 86–92, 2021

    2021

  65. [65]

    Rationale-based support for software maintenance,

    J. E. Burge and D. C. Brown, “Rationale-based support for software maintenance,” inRationale management in software engineering. Springer, 2006, pp. 273–296

    2006

  66. [66]

    Explicate ’78: Assurance case applicability to digital systems,

    C. M. Holloway and P. J. Graydon, “Explicate ’78: Assurance case applicability to digital systems,” Federal Aviation Adminis- tration, Atlantic City International Airport, NJ, Technical Report DOT/FAA/TC-17/67, January 2018

    2018

  67. [67]

    Guidelines for performing systematic literature reviews in software engineering,

    S. Keeleet al., “Guidelines for performing systematic literature reviews in software engineering,” Technical report, ver. 2.3 EBSE technical report, Tech. Rep., 2007

    2007

  68. [68]

    Robertson and J

    S. Robertson and J. Robertson,Mastering the Requirements Process: Getting Requirements Right, 3rd ed. Addison-Wesley Professional, 2012

    2012

  69. [69]

    Clarke and V

    V . Clarke and V . Braun,Thematic Analysis. Dordrecht: Springer Netherlands, 2014, pp. 6626–6628

    2014

  70. [70]

    Content analysis and thematic analysis: Implications for conducting a qualitative descriptive study,

    M. Vaismoradi, H. Turunen, and T. Bondas, “Content analysis and thematic analysis: Implications for conducting a qualitative descriptive study,”Nursing & health sciences, vol. 15, no. 3, pp. 398–405, 2013

    2013

  71. [71]

    Ai auditing: The broken bus on the road to ai accountability,

    A. Birhane, R. Steed, V . Ojewale, B. Vecchione, and I. D. Raji, “Ai auditing: The broken bus on the road to ai accountability,” inIEEE SaTML, 2024, pp. 612–643

    2024

  72. [72]

    Artificial intelligence risk management framework (ai rmf 1.0),

    N. AI, “Artificial intelligence risk management framework (ai rmf 1.0),”URL: https://nvlpubs. nist. gov/nistpubs/ai/nist. ai, pp. 100–1, 2023

    2023

  73. [73]

    D. N. Walton,The new dialectic: Conversational contexts of argument. University of Toronto Press, 1998

    1998

  74. [74]

    A taxonomy of fallacies in system safety arguments,

    W. S. Greenwell, J. C. Knight, C. M. Holloway, and J. J. Pease, “A taxonomy of fallacies in system safety arguments,” in24th ISSC, 2006

    2006

  75. [75]

    An investigation of proposed techniques for quantifying confidence in assurance arguments,

    P. J. Graydon and C. M. Holloway, “An investigation of proposed techniques for quantifying confidence in assurance arguments,” Safety science, vol. 92, pp. 53–65, 2017

    2017

  76. [76]

    The extent and consequences of p-hacking in science,

    M. L. Head, L. Holman, R. Lanfear, A. T. Kahn, and M. D. Jennions, “The extent and consequences of p-hacking in science,” PLoS biology, vol. 13, no. 3, p. e1002106, 2015

    2015

  77. [77]

    Different horses for different courses: Comparing bias mitigation algorithms in ml,

    P. Ganesh, U. Gohar, L. Cheng, and G. Farnadi, “Different horses for different courses: Comparing bias mitigation algorithms in ml,” inWorkshop on Algorithmic Fairness Through the Lens of Metrics and Evaluation. PMLR, 2025, pp. 96–118

    2025

  78. [78]

    AI risk assessment: a scenario-based, proportional methodology for the ai act,

    C. Novelli, F. Casolari, A. Rotolo, M. Taddeo, and L. Floridi, “AI risk assessment: a scenario-based, proportional methodology for the ai act,”Digital Society, vol. 3, no. 1, p. 13, 2024

    2024

  79. [79]

    Risk assessment at AGI companies: A review of popular risk assessment techniques from other safety- critical industries,

    L. Koessler and J. Schuett, “Risk assessment at AGI companies: A review of popular risk assessment techniques from other safety- critical industries,”arXiv preprint arXiv:2307.08823, 2023

    work page arXiv 2023

  80. [80]

    NASA risk management handbook,

    H. Dezfuli, A. Benjamin, C. Everett, G. Maggio, M. Stamatelatos, R. Youngblood, S. Guarro, P. Rutledge, J. Sherrard, C. Smith et al., “NASA risk management handbook,” Tech. Rep., 2011

    2011

Showing first 80 references.