Pith. sign in

REVIEW 4 major objections 5 minor 49 references

A Taxonomy of Real-World Defeaters in Safety Assurance Cases

T0 review · 4 major / 5 minor · reviewed 2026-08-09 · deepseek-v4-flash

Pith's one-line read Seven categories, derived by open coding published safety cases, organize the defeaters that weaken assurance arguments.

desk verdict A useful synthesis of defeater categories, but the 'real-world' grounding is claimed, not demonstrated: no audit trail from the surveyed cases to the taxonomy. read the letter →

arxiv 2502.00238 v1 pith:2Q37FEOF submitted 2025-02-01 cs.SE

classification cs.SE
keywords defeaterssafetyassurancecasetaxonomyrequirementsidentificationvalidationcyber-physicalsystems
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

Safety assurance cases are structured arguments that a system meets its safety goals, but they can contain hidden weaknesses, called defeaters, that undermine the argument. Identifying defeaters today is largely ad hoc, depending on the analyst's judgment and vulnerable to confirmation bias. This paper claims that open coding of real-world defeaters reported in published assurance cases yields seven broad categories — logical fallacies, contextual, evidence validity, requirements, structural, adversarial, and uncertainty — that can serve as a reusable checklist. If the taxonomy holds, developers and reviewers could systematically probe assurance cases for common weaknesses, improving coverage and reducing unwarranted confidence in safety claims. The authors provide the coded artifacts openly so the taxonomy can be extended.

What carries the argument

The central mechanism is the taxonomy itself: a seven-branch classification of defeaters, built by open coding published assurance cases and iteratively consolidating codes. Open coding means two authors independently assigned codes to each identified defeater, then reconciled and merged overlapping codes into themes, following standard thematic analysis. The taxonomy's structure carries the argument: it turns a scattered list of weakeners into a small set of named categories, each with concrete 'unless...' examples, so that reviewers can check each category systematically. The paper also links each category to possible mitigations, which is what makes it a checklist rather than a mere description.

What would settle it

Take a corpus of assurance cases that were not part of the surveyed sample, from domains like medical devices or autonomous vehicles, enumerate every defeater the cases' authors report, and check whether each can be placed into one of the seven categories without forcing; if a substantial fraction fall outside all categories, the completeness claim is refuted.

Watch

Extended reading notes

Core claim

The central claim is that real-world defeaters can be classified into seven categories, and that this classification, derived from six safety arguments drawn from ten papers plus the authors' own small-uncrewed-aircraft cases, provides a foundation for standardizing defeater analysis. Each category groups related sub-types: logical defeaters follow an existing taxonomy of relevance, acceptability, and sufficiency fallacies; contextual defeaters cover faults, human errors, configuration, monitoring, and environmental factors; evidence validity defeaters cover ML/AI concerns, data drift, inadequate metrics, and testing gaps; requirements defeaters cover missing, incorrect, ambiguous, stale, and inconsistent requirements; structural defeaters cover redundancy and interdependencies; adversarial defeaters cover malicious intent; and uncertainty defeaters cover epistemic, aleatoric, and ontological unknowns. The paper evaluates the taxonomy by applying it to a new assurance case for a small-uncrewed-aircraft flight authorization system and reports that it can serve as a safety checklist and guide. The authors intend the taxonomy to be a starting point that the community extends.

Load-bearing premise

The taxonomy's completeness rests on the assumption that the six safety arguments from ten papers, plus the authors' own small-uncrewed-aircraft cases, fairly represent the range of defeaters in real-world safety assurance cases; if the sample is unrepresentative, the seven categories will miss common failure modes and the checklist will underperform.

Editorial extensions

If this is right

  • Safety analysts can use the seven categories as a checklist when reviewing an assurance case, reducing the chance of overlooking a whole class of weaknesses.
  • The shared terminology across categories improves communication among developers, reviewers, and regulators, making it easier to argue that a case has been probed for common defeaters.
  • The taxonomy can serve as an external knowledge source to improve automated defeater generation, including LLM-based approaches, by focusing them on known categories rather than free-form brainstorming.
  • Because the taxonomy is extensible, new defeater types from emerging technologies such as ML/AI components or adversarial threats can be added without restructuring the existing categories.
  • The example 'unless...' statements for each sub-category give reviewers concrete prompts to instantiate in their own system context.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the taxonomy is adopted in practice, a natural next step is to link each category to a library of standard mitigations or verification activities, turning the checklist from a detection aid into a remediation guide.
  • The completeness of the taxonomy could be tested against accident and incident reports: if the defeaters that actually contributed to past safety failures in cyber-physical systems do not fit the seven categories, the classification would need revision.
  • A quantitative variant of this work would measure inter-rater reliability of the coding process, giving evidence about whether the categories are clear enough for practitioners to apply consistently.
  • The sample's reliance on publicly available cases may disproportionately represent well-documented, research-adjacent systems; applying the same open-coding method to confidential industrial or regulatory cases would reveal whether some categories are over- or under-represented.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes a taxonomy of 'real-world defeaters' for safety assurance cases, derived from a literature survey of 10 papers (six safety arguments) and the authors' own sUAS assurance cases, coded thematically by two authors. The taxonomy has seven broad categories—logical, contextual, evidence validity, requirements, structural, adversarial, and uncertainty defeaters—each with sub-types and illustrative examples. The authors argue that the taxonomy can serve as a safety checklist to standardize defeater analysis and improve coverage, and they evaluate it by applying it to their own sUAS automated flight authorization assurance case. The paper provides an open-source artifact and frames the work as a first step toward standardizing defeater analysis, with user-study validation left to future work.

Significance. If the taxonomy's empirical grounding were fully demonstrated, this would be a useful contribution: it consolidates disparate defeater terminology, builds on prior fallacies and uncertainty taxonomies, and offers a practical checklist for safety analysts. The open-source artifact and the explicit framing as an extensible taxonomy are strengths, as is the identification of seven categories that plausibly cover many assurance-case weaknesses. However, the paper's central claim—that the categories arise from real published cases and can be applied consistently—is not currently supported by auditable evidence, because the coding process lacks traceability and the evaluation is not independent. With added transparency and reliability evidence, the taxonomy could become a valuable reference for both practitioners and researchers working on assurance case evaluation and LLM-supported defeater generation.

major comments (4)
  1. [Section III-A and III-B] The survey methodology is not auditable: the paper reports no screening counts, no inclusion/exclusion criteria, and no per-paper list of extracted defeaters. Section III-A states only that 'six safety arguments from 10 papers' resulted from the search, and Section III-B describes open coding without providing a codebook or a mapping from individual defeaters found in each surveyed paper to the final categories. Without this traceability, the reader cannot verify that the seven categories are grounded in the surveyed 'real-world' cases rather than imported from prior taxonomies (e.g., Greenwell et al. [22] or Ramirez et al. [26]) or from the authors' own sUAS cases.
  2. [Section III-B] The claim that two authors independently coded defeaters and reached consensus is not supported by any inter-rater agreement metric, a list of initial codes, or a description of how disagreements were resolved. Because the taxonomy's reliability as a checklist depends on consistent application by different analysts, the absence of these data is load-bearing; a reader cannot tell whether the categories are reproducible or idiosyncratic.
  3. [Section IV, Tables I-VII] The taxonomy tables mostly present invented 'Unless...' examples rather than quoted defeaters from the surveyed literature. This makes it impossible to distinguish categories that were induced from published safety arguments from categories that were constructed for illustrative purposes. The paper should either quote or cite the specific defeaters from each of the 10 surveyed papers that support each sub-type, or clearly state which categories are synthesized and which are adopted from prior works.
  4. [Section V and Conclusion] The evaluation is not independent: it applies the taxonomy to an assurance case developed by the same team [28], and the Conclusion states that 'validation of the taxonomy with user studies is left to future work.' Consequently, the claim that the taxonomy 'can serve as a safety checklist' that improves coverage and quality is currently unsupported. At minimum, the paper should report the results of applying the taxonomy to an independently developed assurance case, or temper the checklist claim and present the contribution as a provisional taxonomy only.
minor comments (5)
  1. [Figure 3] The sub-type label 'Redudancy' is misspelled and should read 'Redundancy.'
  2. [Figure 1] The word 'Maintainence' is misspelled and should read 'Maintenance.'
  3. [Table I] In the 'Ignoring the Counter-Evidence' row, the example ends with 'conditions..' (double period), and in the 'Pseudo-precision' row the phrase 'is likely not perfect' is vague; consider stating that the precision is not justified.
  4. [Table VII] The heading 'Goal: The SUAS's obstacle detection system...' uses 'SUAS' while the rest of the paper uses 'sUAS'; please make the capitalization consistent.
  5. [Section III-A and footnote 1] The artifact link is provided, but the text does not describe what the artifact contains (e.g., raw extracted defeaters, coding spreadsheets, or only the taxonomy figures). A short description of the artifact contents would help readers assess the reproducibility of the coding process.

Circularity Check

1 steps flagged · score 3.0 of 10

Evaluation case overlaps with the survey corpus, so the 'new real-world' validation is not independent; no equation-level circularity.

  1. fitted input called prediction [Section III-A (Survey methodology) and Section II-B/Contributions (Evaluation)]
    "Finally, we incorporated safety arguments developed by our team for sUAS, resulting in six safety arguments from 10 papers. ... Our evaluation of the proposed taxonomy is centered on an assurance case [28] we are developing for a sUAS automated flight authorization system. ... 3) Evaluating the defeater taxonomy in an initial application on a new real-world assurance case and suggesting potential mitigations."

    The taxonomy is claimed to be derived by open coding from a corpus that explicitly includes 'safety arguments developed by our team for sUAS,' and [28] is a team-developed sUAS safety argument. The paper does not state that [28] was held out from the coding process, so calling the application to [28] an 'initial application on a new real-world assurance case' presents the input corpus as if it were an independent test. The categories were fit, at least in part, on this case, and the case is then used as evidence of the taxonomy's usability. This is the fitted-input-called-prediction pattern: the evaluation is not independent unless [28] is excluded from the survey, which the paper never says.

full rationale

This is a qualitative taxonomy paper, not an equation-level derivation, so the usual formal circularity patterns (self-definition, fitted parameters renamed as predictions) mostly do not apply. The taxonomy has independent anchors: it surveys published assurance cases and transparently builds on external taxonomies, notably Greenwell et al. [22] for logical fallacies and Ramirez et al. [26] for uncertainty, so those categories are not secretly the authors' own prior work. The main circularity concern is the evaluation. Section III-A includes 'safety arguments developed by our team for sUAS' in the survey corpus, and Section II-B says the evaluation is centered on the team-developed assurance case [28], with no statement that [28] was held out. The third contribution then calls this 'an initial application on a new real-world assurance case,' which conflates training input with evaluation target. The absence of per-paper defeater-to-category mappings and inter-rater statistics is an auditability and validity threat, but that alone is not circularity. Overall, the central taxonomy does not reduce to its inputs by construction, but the validation claim is weakened by the overlap between the coding corpus and the evaluation case.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No numeric free parameters or physical entities are introduced. The taxonomy is a qualitative classification; the load-bearing premises are representativeness of the literature sample, reliability of consensus-based coding, and validity of the external taxonomies adopted as building blocks.

assumptions (3)
  • domain assumption The 10 surveyed papers and the authors' safety arguments are representative of real-world assurance case defeaters.
    Section III-A describes the search but reports no inclusion statistics; threats to validity in Section III-C admit sample size constraints.
  • domain assumption Open coding by two authors, consolidated by consensus, yields reliable category boundaries.
    Section III-B describes independent coding but no inter-rater agreement metric or codebook artifact is reported.
  • domain assumption Existing taxonomies cited as building blocks, such as Greenwell et al. for logical fallacies and Ramirez et al. for uncertainty, are valid for this synthesis.
    Section IV states the taxonomy was built on existing taxonomies to avoid re-inventing terms.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Taxonomy of Real-World Defeaters in Safety Assurance Cases." pith.science (2026). https://pith.science/paper/2Q37FEOF

@misc{pith2026250200238,
  author       = {Pith},
  title        = {Pith review of: A Taxonomy of Real-World Defeaters in Safety Assurance Cases},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2Q37FEOF}},
  note         = {Machine review of arXiv:2502.00238}
}
read the original abstract

The rise of cyber-physical systems in safety-critical domains calls for robust risk-evaluation frameworks. Assurance cases, often required by regulatory bodies, are a structured approach to demonstrate that a system meets its safety requirements. However, assurance cases are fraught with challenges, such as incomplete evidence and gaps in reasoning, called defeaters, that can call into question the credibility and robustness of assurance cases. Identifying these defeaters increases confidence in the assurance case and can prevent catastrophic failures. The search for defeaters in an assurance case, however, is not structured, and there is a need to standardize defeater analysis. The software engineering community thus could benefit from having a reusable classification of real-world defeaters in software assurance cases. In this paper, we conducted a systematic study of literature from the past 20 years. Using open coding, we derived a taxonomy with seven broad categories, laying the groundwork for standardizing the analysis and management of defeaters in safety-critical systems. We provide our artifacts as open source for the community to use and build upon, thus establishing a common framework for understanding defeaters.

Figures

Figures reproduced from arXiv: 2502.00238 by the authors.

Figure 1
Figure 1. Overview of the safety assurance case lifecycle, illustrating the roles [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. sUAS Safety Assurance Case fragment with example defeaters. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. A high-level taxonomy of real-world defeaters in assurance cases. The boxes at the top show the seven broad categories. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 47 canonical work pages

  1. [22]

    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,” in 24th ISSC, 2006

  2. [26]

    A taxonomy of uncertainty for dynamically adaptive systems,

    A. J. Ramirez, A. C. Jensen, and B. H. Cheng, “A taxonomy of uncertainty for dynamically adaptive systems,” in IEEE SEAMS, 2012, pp. 99–108

  3. [28]

    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,” in AIAA AVIATION FORUM AND ASCEND 2024, 2024, p. 4626

  4. [1]

    A survey on concepts, applications, and challenges in cyber-physical systems,

    V . Gunes, S. Peter, T. Givargis, and F. Vahid, “A survey on concepts, applications, and challenges in cyber-physical systems,” KSII TIIS , vol. 8, no. 12, pp. 4242–4268, 2014

  5. [2]

    Medical cyber-physical systems: A survey,

    N. Dey, A. S. Ashour, F. Shi, S. J. Fong, and J. M. R. Tavares, “Medical cyber-physical systems: A survey,” Journal of medical systems , vol. 42, pp. 1–13, 2018

  6. [3]

    Autonomous vehicle safety: An interdis- ciplinary challenge,

    P. Koopman and M. Wagner, “Autonomous vehicle safety: An interdis- ciplinary challenge,” IEEE ITSM, vol. 9, no. 1, pp. 90–96, 2017

  7. [4]

    Weaving an assurance case from design: a model-based approach,

    R. Hawkins, I. Habli, D. Kolovos, R. Paige, and T. Kelly, “Weaving an assurance case from design: a model-based approach,” in 2015 IEEE HASE. IEEE, 2015, pp. 110–117

  8. [5]

    Software considerations in airborne systems and equipment certification,

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

Show all 49 references
  1. [6]

    Ascad—adelard safety case development manual,

    R. Bloomfield, P. Bishop, C. Jones, and P. Froome, “Ascad—adelard safety case development manual,” Adelard, vol. 5, 1998

  2. [7]

    Knight, Fundamentals of Dependable Computing for Software Engi- neers

    J. Knight, Fundamentals of Dependable Computing for Software Engi- neers. CRC Press, 2012

  3. [8]

    The goal structuring notation–a safety argu- ment notation,

    T. Kelly and R. Weaver, “The goal structuring notation–a safety argu- ment notation,” in DSN workshop on assurance cases . Citeseer, 2004

  4. [9]

    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

  5. [10]

    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

  6. [11]

    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 Computing Surveys (CSUR), vol. 52, no. 5, pp. 1–34, 2019

  7. [12]

    Clarissa: Foundations, tools & automation for assurance cases,

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

  8. [13]

    Advocate: An assurance case automation toolset,

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

  9. [14]

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

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

  10. [15]

    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

  11. [16]

    Eliminative induction: A basis for arguing system confidence,

    J. B. Goodenough, C. B. Weinstock, and A. Z. Klein, “Eliminative induction: A basis for arguing system confidence,” in ICSE, 2013, pp. 1161–1164

  12. [17]

    CoDefeater: Using LLMs to find defeaters in assurance cases,

    U. Gohar, M. C. Hunter, R. R. Lutz, and M. B. Cohen, “CoDefeater: 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

  13. [18]

    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. Sandro, and M. Chechik, “AI-Supported Eliminative Argumentation: Practical Experience Generating Defeaters to Increase Confidence in Assurance Cases,” in ISSRE. IEEE, 2024

  14. [19]

    Semantic 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, “Semantic analysis of assurance cases using s (CASP).” in ICLP Workshops, 2023

  15. [20]

    Understanding and evaluating assurance cases,

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

  16. [21]

    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

  17. [23]

    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

  18. [24]

    Assurance Case Arguments in the Large: The CERN LHC Machine Protection System,

    L. Millet, S. Diemert, C. Rees, T. Viger, M. Chechik, C. Menghi, and J. Joyce, “Assurance Case Arguments in the Large: The CERN LHC Machine Protection System,” in SAFECOMP Springer, 2023, pp. 3–10

  19. [25]

    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?” in Proceedings of the AAAI/ACM Conference on AIES, 2024, pp. 421–437

  20. [27]

    Taxonomy of machine learning safety: A survey and primer,

    S. Mohseni, H. Wang, C. Xiao, Z. Yu, Z. Wang, and J. Yadawa, “Taxonomy of machine learning safety: A survey and primer,” ACM Computing Surveys, vol. 55, no. 8, pp. 1–38, 2022

  21. [29]

    Towards engineering fair and equitable software systems for managing low-altitude airspace authorizations,

    U. Gohar, M. C. Hunter, A. Marczak-Czajka, R. R. Lutz, M. B. Cohen, and J. Cleland-Huang, “Towards engineering fair and equitable software systems for managing low-altitude airspace authorizations,” in Proceed- ings of the 46th International Conference on Software Engineering:...

  22. [30]

    The art and practice of data science pipelines: A comprehensive study of data science pipelines in theory, in-the-small, and in-the-large,

    S. Biswas, M. Wardat, and H. Rajan, “The art and practice of data science pipelines: A comprehensive study of data science pipelines in theory, in-the-small, and in-the-large,” in ICSE, 2022, p. 2091–2103

  23. [31]

    Sociotechnical harms of algorithmic systems: Scoping a taxonomy for harm reduction,

    R. Shelby, S. Rismani, K. Henne, A. Moon, N. Rostamzadeh, P. Nicholas, N. Yilla-Akbari, J. Gallegos, A. Smart, E. Garcia et al. , “Sociotechnical harms of algorithmic systems: Scoping a taxonomy for harm reduction,” in AAAI AIES, 2023, pp. 723–741

  24. [32]

    Long-term fairness inquiries and pursuits in machine learn- ing: A survey of notions, methods, and challenges,

    U. Gohar, Z. Tang, J. Wang, K. Zhang, P. L. Spirtes, Y . Liu, and L. Cheng, “Long-term fairness inquiries and pursuits in machine learn- ing: A survey of notions, methods, and challenges,” arXiv preprint arXiv:2406.06736, 2024

  25. [33]

    Clarke and V

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

  26. [34]

    M. B. Miles and A. M. Huberman, Qualitative data analysis: An expanded sourcebook. SAGE, 1994

  27. [35]

    Orthogonal defect classification - A concept for in-process measurements,

    R. Chillarege, I. S. Bhandari, J. K. Chaar, M. J. Halliday, D. S. Moebus, B. K. Ray, and M. Wong, “Orthogonal defect classification - A concept for in-process measurements,” IEEE TSE, vol. 18, no. 11, pp. 943–956, 1992

  28. [36]

    Dubrova, Fault-tolerant design

    E. Dubrova, Fault-tolerant design. Springer, 2013, vol. 8

  29. [37]

    van Lamsweerde, Requirements Engineering - From System Goals to UML Models to Software Specifications

    A. van Lamsweerde, Requirements Engineering - From System Goals to UML Models to Software Specifications . Wiley, 2009

  30. [38]

    Security requirements engineering: A framework for representation and analysis,

    C. B. Haley, R. C. Laney, J. D. Moffett, and B. Nuseibeh, “Security requirements engineering: A framework for representation and analysis,” IEEE Trans. Software Eng. , vol. 34, no. 1, pp. 133–153, 2008

  31. [39]

    A survey on adversarial attacks in computer vision: Taxonomy, visualization and future directions,

    T. Long, Q. Gao, L. Xu, and Z. Zhou, “A survey on adversarial attacks in computer vision: Taxonomy, visualization and future directions,” Computers & Security , vol. 121, p. 102847, 2022

  32. [40]

    A taxonomy and terminology of adversarial machine learning,

    E. Tabassi, K. J. Burns, M. Hadjimichael, A. D. Molina-Markham, and J. T. Sexton, “A taxonomy and terminology of adversarial machine learning,” NIST IR, vol. 2019, pp. 1–29, 2019

  33. [41]

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

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

  34. [42]

    Advancing requirements engineering through generative AI: Assessing the role of LLMs,

    C. Arora, J. Grundy, and M. Abdelrazek, “Advancing requirements engineering through generative AI: Assessing the role of LLMs,” in Generative AI for Effective Software Development . Springer, 2024, pp. 129–148

  35. [43]

    Large language model for vulnerability detection: Emerging results and future directions,

    X. Zhou, T. Zhang, and D. Lo, “Large language model for vulnerability detection: Emerging results and future directions,” in Proceedings of the 2024 ACM/IEEE 44th ICSE NIER , 2024, pp. 47–51

  36. [44]

    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

  37. [45]

    Automatically detecting fallacies in system safety arguments,

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

  38. [46]

    Argument-based approach to computer system safety engineering,

    T. Yuan and T. Kelly, “Argument-based approach to computer system safety engineering,” IJCCBS, vol. 3, no. 3, pp. 151–167, 2012

  39. [47]

    A systematic approach and tool support for GSN-based safety case assessment,

    Y . Luo, M. van den Brand, Z. Li, and A. K. Saberi, “A systematic approach and tool support for GSN-based safety case assessment,” Journal of Systems Architecture , vol. 76, pp. 1–16, 2017

  40. [48]

    Systematic evaluation of (safety) assurance cases,

    T. Chowdhury, A. Wassyng, R. F. Paige, and M. Lawford, “Systematic evaluation of (safety) assurance cases,” in SAFECOMP Springer, 2020, pp. 18–33

  41. [49]

    A PRISMA-driven systematic mapping study on system assurance weakeners,

    K. K. Shahandashti, A. B. Belle, T. C. Lethbridge, O. Odu, and M. Sivakumar, “A PRISMA-driven systematic mapping study on system assurance weakeners,” Information and Software Technology, p. 107526, 2024

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.