Pith. sign in

REVIEW 3 major objections 6 minor 72 references

Agile System Development Lifecycle for AI Systems: Decision Architecture

T0 review · 3 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper proposes that agile AI system development begin by specifying human decisions through a ten-element decision architecture, before any AI technology is chosen.

desk verdict A real idea but a thin validation: the decision architecture concept is new and useful, yet the core ten elements miss uncertainty and utility, and the 'demonstration' is just a hypothetical. read the letter →

arxiv 2501.09434 v2 pith:5JRBT32J submitted 2025-01-16 cs.SE

Asif Q. Gill This is my paper · ORCID
classification cs.SE
keywords agileSDLCdecisionarchitectureAIsystemsautomationsciencetrustworthyrequirementsengineeringinsuranceclaimprocessing
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

This paper tries to establish that agile system development for AI systems can be improved by adding a decision-architecture stage grounded in decision science, not just data and model engineering. The proposal is human-centric: before choosing AI technology, a team should identify and describe the human decisions subject to automation using ten core elements - decision maker, frame, alternatives, preferences, information, decision logic, decision rule, bias, principles, and automation level - and record them in artifacts such as decision catalogs and decision cards. The paper argues that this makes decision requirements the foundation for requirements engineering, AI system architecture, design spikes, and agile planning, which in turn supports auditability, debiasing, and trustworthiness. The approach is demonstrated with an insurance claim processing scenario as an initial proof of concept.

What carries the argument

The central object is the decision architecture: a set of ten decision elements and associated artifacts that capture the building blocks of a human decision. The ten elements are decision maker, frame, alternatives, preferences, information, decision logic, decision rule, bias, principles, and automation level. This architecture carries the argument by converting decision science into decision requirements: it lets teams write each decision as a decision card, collect cards in a decision catalog, model them with notations such as DMN, and then use those requirements to drive AI system architecture and agile release planning.

What would settle it

Apply the proposed Discover-stage method to two or three decision domains with different structures, such as a high-volume loan approval process and a clinical triage process. If stakeholders in any domain identify a decision requirement that cannot be expressed through the ten elements and listed artifacts, or if the resulting decision cards cannot reconstruct what a deployed AI system later decides, the claim that these elements form a sufficient core set is refuted.

Watch

Extended reading notes

Core claim

The paper's central discovery is the proposal of decision architecture as a distinct domain inside the Discover stage of an agile SDLC for AI systems. It asserts that human decisions can be analyzed and specified independently of AI technology through a core set of ten elements, and that gaps between current and future decision states can be captured as decision requirements. The proposed architecture treats bias as an explicit element, calls for debiasing techniques, and defines artifacts - decision org chart, decision canvas, decision card, decision prompt, decision catalog, decision hierarchy, decision process model, decision service, information model, rule model, enterprise knowledge graph, decision table, decision matrix, and decision tree - that make decisions legible for both humans and AI systems. If this is right, teams can design and audit AI decision automation from the human decision outward, rather than from a chosen model backward.

Load-bearing premise

The argument stands on the assumption that the ten decision elements in Table II are a sufficient and general core set for describing any human decision targeted for AI automation, and that these elements can be captured as decision requirements before the AI technology is selected.

Editorial extensions

If this is right

  • Decision requirements become first-class agile artifacts that can be prioritized, estimated, grouped by dependency, and allocated to releases and iterations.
  • Bias and debiasing are brought into the early SDLC, so human bias is less likely to be baked into AI systems.
  • AI system architecture is defined as the realization of a human decision architecture, with application, data, and algorithm components traced back to decision cards.
  • Post-deployment, decision logs, traces, events, and metrics can be tied to the decision architecture, supporting audit and assurance.
  • The approach extends beyond the insurance scenario to any decision-automation domain, and gives enterprise architecture frameworks a missing decision domain.

Reading between the lines

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

  • Editorial extension, not in the paper: if the ten elements are general, the architecture could serve as a pre-model-selection checklist in regulated sectors; a missing element would show up as a decision requirement that cannot be expressed, creating a simple test of generality.
  • Editorial extension: decision cards and catalogs could double as a runtime audit trail, letting each automated decision be traced to its originating frame, logic, and bias treatment.
  • Editorial extension: the paper's framing implies a measurable prediction - AI decision-automation projects that complete a decision-architecture discovery phase before selecting technology should show fewer failures from technology-first causes; this could be tested against project outcome data.
  • Editorial extension: the duality of human and algorithmic bias suggests a joint debiasing evaluation comparing purely human, purely AI, and human-with-AI decision pipelines.
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

3 major / 6 minor

Summary. The paper proposes enhancing agile system development lifecycles (SDLC) for AI systems by introducing a "decision architecture" embedded in the Discover stage. Drawing on decision science literature, it identifies ten core decision elements (Table II) and a set of artifacts such as decision catalogs and decision cards (Table III). The proposed approach is illustrated with a hypothetical insurance claim processing scenario. The central claim is that this decision-driven, technology-agnostic architecture improves the analysis, specification, auditability, and trustworthiness of AI decision automation.

Significance. If the proposed decision architecture is accepted as a sound and sufficiently complete foundation, the paper addresses a real gap: existing agile SDLCs focus on functional/non-functional requirements and data/model-centric AI pipelines, with limited support for explicitly capturing the human decision-making requirements that AI systems automate. The paper's strengths include a coherent integration of decision science concepts, practical artifacts (decision catalog, decision cards, decision prompts), and a technology-agnostic framing that can be adopted incrementally in agile teams. The insurance claim example provides a concrete illustration of how the artifacts might be used. However, the paper is a conceptual proposal rather than an empirical validation; its load-bearing claim about the sufficiency of the ten decision elements is not fully justified, and the single hypothetical scenario does not establish usability in the stronger sense used in the abstract.

major comments (3)
  1. [Section II.C and Table II] The claim that the ten decision elements in Table II form a sufficient "core set" for representing decisions subject to AI automation is undermined by the paper's own discussion of decision science. Section II.C lists "choice under uncertainty" as a major decision type and describes decisions as having probabilistic positive or negative outcomes, while canonical decision analysis (Howard & Abbas [44]) centers on alternatives, probabilities, outcomes/utilities, and a decision rule. Table II contains decision maker, frame, alternatives, preferences, information, decision logic, decision rule, bias, principles, and automation level, but it has no explicit element for probability, uncertainty, risk tolerance, or utility/outcome value. "Preferences" is defined only as anchors or priorities, not as a utility function, and the decision card format in Section III.C does not prompt for probability estimates, risk preferences, or utility weights. For decisions with uncertain outcomes, the architecture therefore cannot capture essential specification content without ad hoc additions.
  2. [Section III.C and Section IV] The paper simultaneously asserts that the ten elements are a "core set" and states that "Additional elements can also be considered, if required" and that "only core decision architecture elements are listed here," with Section IV adding that "New elements and artifacts can be discovered or existing can be modified as per the specific context." This makes the completeness claim unfalsifiable: if any missing element is discovered, it can simply be added. The paper should either provide a principled derivation of why these ten elements are necessary and sufficient, or reframe the contribution as an initial, extensible set of decision elements rather than a core set. Without this clarification, the decision cards and requirements backlog built on the ten elements may inherit an unjustified completeness assumption.
  3. [Abstract and Section III.A/IV] The abstract and conclusions state that the approach was "demonstrated" and that the work "indicated the usability" of decision science for enhancing agile SDLC. However, the only evidence is a single hypothetical insurance claim scenario with no evaluation criteria, user study, domain expert validation, or comparison against alternative approaches. The scenario is useful as an illustrative walkthrough, but it does not by itself demonstrate usability. The authors should soften these claims or add an explicit evaluation protocol, such as applying the decision cards and catalog in a real or simulated multi-domain setting and collecting structured feedback.
minor comments (6)
  1. [Section II.C] The phrase "irrecoverable resources" is nonstandard; consider "irreversible" or "non-recoverable." Also, "This provides the rational for" should be "the rationale for."
  2. [Section III.C] The text says "debasing techniques" where it likely means "debiasing techniques" (the same section mentions "debias" correctly). Please correct for consistency.
  3. [Table II, row 6] The "Examples" column for Decision logic lists categories ("Decision process, algorithms, calculations, models, reasoning") rather than concrete examples; consider providing a specific insurance-related example such as "claim score threshold" or "fraud probability calculation."
  4. [Reference [64]] The publishing body is misspelled as "OMG Stadnards Development Organization"; it should be "OMG Standards Development Organization."
  5. [Section III.D] There is a typo: "Al algorithms and related models are trained" should read "AI algorithms and related models are trained."
  6. [Figures] Figures 1-4 are referenced in the text (e.g., Fig. 4 in Section III.C and III.D), but the provided manuscript does not include the actual figure images; ensure the final version contains all figures and that each is legible and properly captioned.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the decision architecture is synthesized from external decision science sources, and the paper's self-citations are supporting rather than load-bearing.

full rationale

This is a conceptual/position paper, not an empirical derivation. The central contribution, the ten-element decision architecture in Table II, is explicitly grounded in external decision science literature (Howard & Abbas [44], Hastie & Dawes [45], Haselton et al. [46]), and the ISO/IEC/IEEE 42010 definition of architecture [48]. The insurance claim scenario is an illustrative application, not a fitted dataset, so no prediction reduces to its own input. The paper's self-citations (e.g., adaptive enterprise architecture [67], trimodal thinking [68], Decision Catalog [49]) are used for supporting context and auxiliary artifacts; removing them would not alter the proposed decision architecture or its stated basis. No equation, fitted parameter, or stated result is shown to be equivalent to an input by construction. The main weaknesses are adequacy/completeness concerns (e.g., the core set of ten elements is asserted rather than derived, and uncertainty/utility are not explicit elements), but these are substantive validity gaps, not circularity. Therefore the paper is self-contained with respect to the circularity criteria, and any self-citation is minor and non-load-bearing.

Assumptions & free parameters 0 free parameters · 4 assumptions · 1 invented entities

The framework introduces no numerical parameters. Its load-bearing assumptions are domain premises about AI system development and the representational completeness of the proposed decision elements, none of which are empirically validated. The main invented conceptual entity is the decision architecture domain itself, embedded in the agile SDLC.

assumptions (4)
  • domain assumption AI systems differ sufficiently from traditional software to require an enhanced full-scale SDLC rather than only AIOps, MLOps, or DevOps practices.
    The paper motivates this with the 80% failure statistic and the distinct attributes of AI systems in Section II.A, but it does not demonstrate that existing AI lifecycle practices are inadequate.
  • ad hoc to paper Decision science categories can be operationalized as a core set of ten decision elements that are sufficient for specifying AI system requirements.
    Table II presents the ten elements as a core set, but no derivation or validation shows that these elements are necessary or sufficient across decision domains.
  • domain assumption Bias identification and debiasing during decision architecture design will propagate into trustworthy AI systems.
    Section III.C asserts this link between decision architecture design and trustworthy AI, but no empirical evidence or causal mechanism is demonstrated.
  • domain assumption A human-centric, decision-driven agile SDLC will reduce the root causes of AI project failure cited from RAND [41].
    Section I.B presents the proposed solution as addressing these root causes, but the causal efficacy of the framework is not tested.
invented entities (1)
  • Decision architecture as an explicit domain within agile SDLC
    purpose: Captures decision elements and artifacts in the Discover stage to guide AI system design for decision automation.
    This is the paper's central proposed conceptual entity. Its only demonstration is a hypothetical insurance claim scenario, and no falsifiable prediction or external benchmark is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Agile System Development Lifecycle for AI Systems: Decision Architecture." pith.science (2026). https://pith.science/paper/5JRBT32J

@misc{pith2026250109434,
  author       = {Pith},
  title        = {Pith review of: Agile System Development Lifecycle for AI Systems: Decision Architecture},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5JRBT32J}},
  note         = {Machine review of arXiv:2501.09434}
}
read the original abstract

Agile system development life cycle (SDLC) focuses on typical functional and non-functional system requirements for developing traditional software systems. However, Artificial Intelligent (AI) systems are different in nature and have distinct attributes such as (1) autonomy, (2) adaptiveness, (3) content generation, (4) decision-making, (5) predictability and (6) recommendation. Agile SDLC needs to be enhanced to support the AI system development and ongoing post-deployment adaptation. The challenge is: how can agile SDLC be enhanced to support AI systems? The scope of this paper is limited to AI system enabled decision automation. Thus, this paper proposes the use of decision science to enhance the agile SDLC to support the AI system development. Decision science is the study of decision-making, which seems useful to identify, analyse and describe decisions and their architecture subject to automation via AI systems. Specifically, this paper discusses the decision architecture in detail within the overall context of agile SDLC for AI systems. The application of the proposed approach is demonstrated with the help of an example scenario of insurance claim processing. This initial work indicated the usability of a decision science to enhancing the agile SDLC for designing and implementing the AI systems for decision-automation. This work provides an initial foundation for further work in this new area of decision architecture and agile SDLC for AI systems.

Figures

Figures reproduced from arXiv: 2501.09434 by the authors.

Figure 1
Figure 1. Agile SDLC, decision architecture and AI systems Agile SDLC for AI systems has two parts ( [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Agile SDLC for AI systems C. Discover Discover stage is organized into five key areas: decision architecture, requirements engineering, AI system architecture, design spikes and plan. All these connected areas of discovery are presented in [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Discover [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: AI system architecture stack and developer platform example D. Develop Develop stage uses the developer platform ( [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

72 extracted references · 70 canonical work pages

  1. [44]

    Foundations of Decision Analysis

    R.A. Howard, A.E. Abbas, “Foundations of Decision Analysis”. Pearson, 2016

    work page 2016

  2. [1]

    A brief history of agile methods

    E.F. Casali, “A brief history of agile methods”. Intense Minimalism, 2012. Available: https://intenseminimalism.com/2012/a-brief-history-of-agile- methods/

    work page 2012

  3. [2]

    https://agilemanifesto.org/

    Agile Alliance, Manifesto for Agile Software Development, 2001. https://agilemanifesto.org/

    work page 2001

  4. [3]

    Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, New York: Dorset House, 2002

    J.A. Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, New York: Dorset House, 2002

    work page 2002

  5. [4]

    Smart, BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle

    J.F. Smart, BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications, 2014

    work page 2014

  6. [5]

    Cockburn,

    A. Cockburn,. Agile Software Development. Addison -Wesley, Boston, 2002

    work page 2002

  7. [6]

    Stapleton, DSDM: The Method in Practice

    J. Stapleton, DSDM: The Method in Practice. Addison-Wesley, 1997

    work page 1997

  8. [7]

    Ambler, and M

    S. Ambler, and M. Lines, Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working, 2019

    work page 2019

Show all 72 references
  1. [8]

    Beck, Extreme Programming Explained: Embrace Change

    K. Beck, Extreme Programming Explained: Embrace Change. Addison - Wesley, ISBN 978-0-321-27865-4, 1999

    1999

  2. [9]

    Palmer and J.M

    S.R. Palmer and J.M. Felsing, A Practical Guide to Feature -Driven Development. Prentice-Hall Inc, Upper Saddle River, 2002

    2002

  3. [10]

    Poppendieck and T

    M. Poppendieck and T. Poppendiec, Lean Software Development: An Agile Toolkit. Addison-Wesley Professional, 2003

    2003

  4. [12]

    Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises

    D. Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007

    2007

  5. [13]

    Newkirk, and A.A

    J.W. Newkirk, and A.A. Vorontsov, Test -Driven Development in Microsoft .NET, Microsoft Press, 2004

    2004

  6. [14]

    L. Bass, I. Weber, and L. Zhu, DevOps: A Software Architect's Perspective. Addison-Wesley, 2015

    2015

  7. [15]

    Abrahamsson, O

    P. Abrahamsson, O. SaloJussi, J. Ronkainen, J. Warsta , Agile Software Development Methods: Review and Analysis , VTT Technical Research Centre of Finland, VTT Publications 478, Otamedia, 2002. Available: https://arxiv.org/abs/1709.08439

    2002 arXiv

  8. [16]

    An evaluation of the degree of agility in six agile methods and its applicability for method engineering

    A. Q.umer, and B . Henderson-Sellers, "An evaluation of the degree of agility in six agile methods and its applicability for method engineering.", Information and Software Technology, vol. 50, no. 4, 2008

    2008

  9. [17]

    A framework to support the evaluation, adoption and improvement of agile methods in practice

    A. Qumer, and B . Henderson-Sellers, "A framework to support the evaluation, adoption and improvement of agile methods in practice." , Journal of Systems and Software vol. 81, no. 11, 2008

    2008

  10. [18]

    Empirical studies of geographically distributed agile development communication challenges: A systematic review

    Y.I. Alzoubi, A .Q. Gill, and A . Al-Ani, "Empirical studies of geographically distributed agile development communication challenges: A systematic review." Information & Management, vol. 53, no. 1, 2016

    2016

  11. [19]

    DevOps: Concepts, practices, tools, benefits and challenges

    G.B. Ghantous, and A. Gill, "DevOps: Concepts, practices, tools, benefits and challenges.", PACIS2017, 2017

    2017

  12. [20]

    Systematic literature reviews in agile software development: A tertiary study

    R. Hoda, N . Salleh, J . Grundy, and H .M. Tee, "Systematic literature reviews in agile software development: A tertiary study." , Information and software technology vol. 85, 2017

    2017

  13. [21]

    Scaling for agility: A reference model for hybrid traditional -agile software development methodologies

    A.Q. Gill, B . Henderson-Sellers, and M . Niazi, "Scaling for agility: A reference model for hybrid traditional -agile software development methodologies.", Information Systems Frontiers, vol. 20 2018

    2018

  14. [22]

    A survey of DevOps concepts and challenges

    L. Leite, C. Rocha, F. Kon, D. Milojicic, and P. Meirelles, "A survey of DevOps concepts and challenges." ACM Computing Surveys (CSUR) , vol. 52, no. 6, 2019

    2019

  15. [23]

    Applying Distributed Cognition Theory to Agile Requirements Engineering

    J. Buchan, D. Zowghi, and M . Bano, "Applying Distributed Cognition Theory to Agile Requirements Engineering." , In Requirements Engineering: Foundation for Software Quality: 26th International Working Conference, REFSQ 2020, Pisa, Italy, March 24–27, 2020

    2020

  16. [24]

    What’s Missing in Requirements Engineering for Responsible AI?,

    D. Zowghi and M. Bano, "What’s Missing in Requirements Engineering for Responsible AI?," in IEEE Software, vol. 40, no. 6, pp. 11 -15, Nov.- Dec. 2023

    2023

  17. [25]

    A Proposal for the Dartmouth Summer Research Project on Artificial Intelligence

    J.L. McCarthy, M.L. Minsky, N. Rochester, and C.E. Shannon, "A Proposal for the Dartmouth Summer Research Project on Artificial Intelligence", 1956

    1956

  18. [26]

    Grobelnik, K

    M. Grobelnik, K. Perset, and S. Russell , What is AI? Can you make a clear distinction between AI and non-AI systems? OECD, 2024

    2024

  19. [27]

    Managing innovation in the era of AI,

    Z. Tekic, and J. Füller, "Managing innovation in the era of AI," Technology in Society , vol73, 2023, https://doi.org/10.1016/j.techsoc.2023.102254

    2023

  20. [28]

    Use Case Catalog and Assessment for AI Applications in Intralogistics of Manufacturing Companies

    O. Sospeter, M. Finke, J. Belke, F. Dyck, and C. Kürpick., "Use Case Catalog and Assessment for AI Applications in Intralogistics of Manufacturing Companies." Procedia CIRP, vol. 118, pp. 74-79, 2023

    2023

  21. [29]

    Automating Higher Education Through Artificial Intelligence?,

    K. Michael, J. Pitt, J. Sargent and E. Scornavacca, "Automating Higher Education Through Artificial Intelligence?," in IEEE Transactions on Technology and Society, vol. 5, no. 3, pp. 264-271, Sept. 2024,

    2024

  22. [30]

    Notes from the AI frontier: Insights from hundreds of use cases

    M. Chui, J. Manyika, M. Miremadi, N. Henke, R. Chung, P. Nel, and S. Malhotra, “Notes from the AI frontier: Insights from hundreds of use cases." McKinsey Global Institute 2, 2018

    2018

  23. [31]

    Using AI to enhance business operations

    M. Tarafdar, C.M. Beath, and J.W. Ross, "Using AI to enhance business operations." MIT Sloan Management Review 60, no. 4, 2019

    2019

  24. [32]

    Opportunities, challenges, and benefits of AI innovation in government services: a review

    K. Alhosani, and S.M. Alhashmi, "Opportunities, challenges, and benefits of AI innovation in government services: a review." Discover Artificial Intelligence 4, no. 1, 2024

    2024

  25. [33]

    Failures in the Loop: Human Leadership in AI-Based Decision-Making,

    K. Michael, J. R. Schoenherr and K. M. Vogel, "Failures in the Loop: Human Leadership in AI-Based Decision-Making," in IEEE Transactions on Technology and Society, vol. 5, no. 1, pp. 2 -13, March, 2024, doi: 10.1109/TTS.2024.3378587

    2024

  26. [34]

    Explainable AI for cybersecurity automation, intelligence and trustworthiness in digital twin: Methods, taxonomy, challenges and prospects

    I.H. Sarker, H. Janicke, A. Mohsin, A. Gill, and L. Maglaras, "Explainable AI for cybersecurity automation, intelligence and trustworthiness in digital twin: Methods, taxonomy, challenges and prospects." ICT Express, 2024

    2024

  27. [35]

    The EU Artificial Intelligence Act

    EU. The EU Artificial Intelligence Act. Available: https://artificialintelligenceact.eu/

  28. [36]

    Policy for responsible use of AI in government

    Australian Government. Policy for responsible use of AI in government. Available: https://architecture.digital.gov.au/responsible -use-of-AI-in- government

  29. [37]

    AI Principles overview

    OECD. AI Principles overview. Available: https://oecd.ai/en/ai-principles

  30. [38]

    AI Standards

    NIST. AI Standards. Available: https://www.nist.gov/artificial - intelligence/ai-standards

  31. [39]

    Saltz, What is the AI Life Cycle?, Data Science Process Alliance, 2024

    J. Saltz, What is the AI Life Cycle?, Data Science Process Alliance, 2024. Available: https://www.datascience-pm.com/ai-lifecycle

    2024

  32. [40]

    Hegde, All the Ops: DevOps, DataOps, MLOps, and AIOps, IBM,

    S. Hegde, All the Ops: DevOps, DataOps, MLOps, and AIOps, IBM,

  33. [41]

    The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI

    J. Ryseff, B.F. De Bruhl, and S.J. Newberyy, “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI”, RAND, 2024

    2024

  34. [42]

    Configuration information system architecture: Insights from applied action design research

    A.Q. Gill, and E. Chew, "Configuration information system architecture: Insights from applied action design research." Information & Management 56, no. 4, 2019

    2019

  35. [43]

    Adaptive enterprise architecture as information: Architecting intelligent enterprises

    A.Q. Gill, “Adaptive enterprise architecture as information: Architecting intelligent enterprises”. World Scientific Publishing, Singapore, 2022

    2022

  36. [45]

    Hastie and R.M

    R. Hastie and R.M. Dawes. Rational choice in an uncertain world: the psychology of judgment and decision making. California: Sage Publications, 2001

    2001

  37. [46]

    The evolution of cognitive bias

    M. G. Haselton, D. Nettle and P.W. Andrews , “The evolution of cognitive bias”. In The handbook of evolutionary psychology. Buss, D.M., Ed. New Jersey: Wiley Online Library. 968-987, 2015

    2015

  38. [47]

    Schwartz and A

    B. Schwartz and A. Ward, Maximizing versus satisficing: Happiness is a matter of choice, 2002

    2002

  39. [48]

    Defining architecture

    ISO/IEC/IEEE 42010. Defining architecture. Available: http://www.iso- architecture.org/ieee-1471/defining-architecture.html

  40. [49]

    Digital Government Ecosystem: Adaptive Architecture for Digital and ICT Investment Decision Making

    A.Q. Gill and M. Hansnata, "Digital Government Ecosystem: Adaptive Architecture for Digital and ICT Investment Decision Making.", In Proceedings of the 25th Annual International Conference on Digital Government Research, pp. 555-564. 2024

    2024

  41. [50]

    A user’s guide to debiasing. In The Wiley Blackwell handbook of judgment and decision making

    J.B. Soll, K.L. Milkman, and J.W. Payne, “A user’s guide to debiasing. In The Wiley Blackwell handbook of judgment and decision making ”, vol. II. Oxford: Blackwell Publishing. 2015

    2015

  42. [51]

    Claims Automation

    Expert.ai. Claims Automation . Available: https://www.expert.ai/products/claims-automation/

  43. [52]

    A framework to support non-fragile agile agent-oriented software development,

    A. Qumer and B. Henderson-Sellers, "A framework to support non-fragile agile agent-oriented software development,", SoMeT (2006): 84-100

    2006

  44. [53]

    Schoemaker, P

    P. Schoemaker, P. and J.E. Russo, A pyramid of decision approaches. California Management Review, vol. 36, 9-31, 1993

    1993

  45. [54]

    Software engineering for machine learning: A case study

    S. Amershi S, A. Begel, C. Bird, R. DeLine, H. Gall E. Kamar, N. Nagappan, B. Nushi B, and T. Zimmermann, “Software engineering for machine learning: A case study”, In 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-S...

    2019

  46. [55]

    AI-Based Decision Support Systems in Industry 4.0, A Review ,

    M. Soori, F.K.G. Jough, R. Dastres, and B Arezoo , "AI-Based Decision Support Systems in Industry 4.0, A Review ," Journal of Economy and Technology, 2024

    2024

  47. [56]

    AI Decision Making: What Is It, Benefits & Examples , 2025

    Intellias. AI Decision Making: What Is It, Benefits & Examples , 2025. Available: https://intellias.com/ai-decision-making/

    2025

  48. [57]

    The Role of Generative AI in Software Development Productivity: A Pilot Case Study

    M. Coutinho, L . Marques, A . Santos, M . Dahia, C . Franca, and R .S. Santos, "The Role of Generative AI in Software Development Productivity: A Pilot Case Study." , arXiv preprint arXiv:2406.00560 , 2024

    2024 arXiv

  49. [58]

    The influence of Artificial intelligence on productivity in Software development

    D. Glushkova, "The influence of Artificial intelligence on productivity in Software development." PhD diss., Politecnico di Torino, 2023

    2023

  50. [59]

    Impact of adopting AI tools by software developers towards productivity and sustainability

    M.A. Hassan, "Impact of adopting AI tools by software developers towards productivity and sustainability.", 2024

    2024

  51. [60]

    AI Tools introduced in Software Development. Analysis of Code quality, Security and Productivity Implications

    A,M. Dincă, A.M., SD. Axinte, G. Tod-Raileanu, and I.C. Bacivarov, “AI Tools introduced in Software Development. Analysis of Code quality, Security and Productivity Implications”, In 2024 IEEE 30th International Symposium for Design and Technology in Electronic Packaging (SIIT...

    2024 arXiv

  52. [61]

    Enhancing software development practices with AI insights in high-tech companies

    D. Ajiga, P .A. Okeleke, S .O. Folorunsho, and C . Ezeigweneme, "Enhancing software development practices with AI insights in high-tech companies." IEEE Software Engineering Institute, Technical Report TR- 2024-003, 2024

    2024

  53. [62]

    Future of software development with generative AI

    J. Sauvola, S. Tarkoma, M. Klemettinen, J. Riekki, and D . Doermann, "Future of software development with generative AI." Automated Software Engineering 31, no. 1, 2024

    2024

  54. [63]

    Wiesinger, P

    J. Wiesinger, P. Marlow, and V. Vuskovic. Agents, Google, 2024. Available: https://medium.com/@penkow/summary-of-googles-ai- white-paper-agents-d5670ae495c9

    2024

  55. [64]

    Available: https://www.omg.org/spec/DMN

    OMG Stadnards Development Organization, Decision Model and Notation Version 1.6 Beta 1, 2024. Available: https://www.omg.org/spec/DMN

    2024

  56. [65]

    Re-thinking Traceability: A prototype to record and revisit the evolution of design artefacts

    M. Gutierrez Lopez, G . Rovelo Ruiz, K . Luyten, M . Haesen, and K . Coninx, "Re-thinking Traceability: A prototype to record and revisit the evolution of design artefacts." In Proceedings of the 2018 ACM International Conference on Supporting Group Work, 196-208. 2018

    2018

  57. [66]

    Brownlow Davies, Introducing AI Penetration Testing , Bugcrowd,

    J. Brownlow Davies, Introducing AI Penetration Testing , Bugcrowd,

  58. [67]

    Adaptive enterprise architecture drivenagiledevelopment

    A.Q. Gill, "Adaptive enterprise architecture drivenagiledevelopment." In 2015 International Conference on Information Systems Development , 2015

    2015

  59. [68]

    Trimodal Thinking for Architecting Human-Centric AI Systems: Fast, Slow and Control

    A. Gill, "Trimodal Thinking for Architecting Human-Centric AI Systems: Fast, Slow and Control." Authorea Preprints, 2024

    2024

  60. [69]

    Kremb, 5 prompt frameworks to level up your prompts: RTF, RISEN, RODES, Chain of thought and Chain of density , 2023

    M. Kremb, 5 prompt frameworks to level up your prompts: RTF, RISEN, RODES, Chain of thought and Chain of density , 2023. Available: https://www.thepromptwarrior.com/p/5-prompt-frameworks-level- prompts

    2023

  61. [70]

    Available: https://c4model.com/ Asif Q

    C4 Model, The C4 model for visualising software architecture. Available: https://c4model.com/ Asif Q. Gill (Senior Member, IEEE ) is Professor and Head of Discipline Software Engineering at the School of Computer Science, University of Technology Sydney. He is also the Directo...

  62. [73]

    He is also an associate editor of the IEEE Transactions on Technology & Society and Springer Nature Discover Data journals. He is often in vited and involved as a professional keynote speaker, editor, conference chair, organizer and reviewer for several national and internatio...

  63. [2023]

    Available: https://developer.ibm.com/articles/all -the-ops-devops- dataops-mlops-and-aiops/

  64. [2024]

    Available: https://www.bugcrowd.com/blog/introducing-ai- penetration-testing

Pith tools

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