Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

Building an Open AIBOM Standard in the Wild

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

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

Pith's one-line read This paper argues that the AIBOM specification—an extension of the SPDX software bill-of-materials standard with 36 new fields for datasets and models—is a practical, validated tool for AI supply-chain transparency, supported by four comple

desk verdict The process narrative is the real contribution; the validation claims are self-assessments that need an independent check before being taken at face value. read the letter →

arxiv 2510.07070 v2 pith:BUHNY3XY submitted 2025-10-08 cs.SE

Gopi Krishnan Rajbahadur , Keheliya Gallaba , Elyas Rashno , Arthit Suriyawongkul , Karen Bennet , Kate Stewart , Ahmed E. Hassan This is my paper · ORCID
classification cs.SE
keywords AIBOMSPDXsoftwarebillofmaterialsAIsupplychaintraceabilityactionresearchcompliancestandardization
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 argues that the AI Bill of Materials (AIBOM) specification—an extension of the SPDX software bill-of-materials standard with 36 new fields organized into 'AI' and 'Dataset' profiles—is a practical, machine-readable way to document AI supply chains, and that the open, multi-stakeholder process that produced it is a reusable blueprint for standardization in fast-moving domains. The authors support the first claim with four validations: the specification represents 13 of 14 EU AI Act information obligations, all studied medical-device elements, and more than 90% of surveyed IEEE 7000 ethical-design subclauses; it maps to all 46 atomic requirements drawn from six foundational industry use cases; ten practitioner interviews surfaced no field the specification could not represent; and an industrial case study populated every internal checklist field, extracted 60% of model-card fields, and automated 40% of third-party metadata. The second claim is supported by a retrospective Action Research framing of the working group's diagnose-plan-act-observe-reflect cycles across 82 meetings and more than 90 contributors. A reader should care because AI systems are increasingly subject to compliance, transparency, and provenance obligations, and a standard that slots into the widely used SPDX framework could give organizations a concrete mechanism for meeting them.

What carries the argument

The central object is the AIBOM specification itself, realized as two new SPDX 3.0 profiles: the AI profile (20 fields, five required) and the Dataset profile (18 fields, six required), which sit alongside the existing Core, Licensing, and Software profiles. These profiles make datasets and models first-class supply-chain elements, capturing provenance, architecture, training details, risks, intended use, and ethical metadata. The argument is carried by a traceability mechanism: for each validation, requirements (regulatory clauses, extracted use-case demands, practitioner suggestions, checklist items) are mapped to specific AIBOM fields, with the mapping checked by working-group members not

What would settle it

An independent evaluator who extracts requirements from a broader corpus of AI supply-chain incidents, regulations, and practitioner interviews and finds even one requirement that cannot be expressed in any AIBOM field would falsify the 'all 46 requirements representable' claim. The paper itself already provides a candidate: the EU AI Act's requirement to represent 'parties involved in testing' is admitted to be unrepresentable.

Watch

Extended reading notes

Core claim

The authors' central discovery is that the existing SPDX SBOM standard could be extended through a modular profile architecture into an AIBOM that treats datasets and models as first-class supply-chain elements, and that this extension can be validated against real-world demands. In their account, the AIBOM represents 13 of 14 EU AI Act information obligations, all required elements from US and EU medical-device guidance, and over 40 subclauses from eight IEEE 7000-series standards; it maps to all 46 atomic requirements extracted from six foundational industry use cases; and in an industrial field study it populated every field of internal ethics and legal checklists, enabled extraction of 6

Load-bearing premise

The load-bearing premise is that the 46 requirements extracted from eight selected studies—one being the first author's own prior work—are the complete set of real-world AI supply-chain requirements, and that the authors' own mapping of them to AIBOM fields is objective.

Editorial extensions

If this is right

  • A single machine-readable AIBOM could support EU AI Act registration and medical-device conformity documentation, since the field set aligns with most of those obligations.
  • Model card generation can be partially automated from AIBOM data, reducing manual documentation effort for model publishers.
  • Third-party AI asset ingestion can be partly automated through APIs and web scraping, lowering the cost of documenting external models and datasets.
  • The profile-based extension approach gives other supply-chain standards a template for evolving into new domains without fragmenting the core standard.
  • Configuration and deployment metadata, deliberately deferred to SPDX 3.1, could be added without breaking the existing profiles.

Reading between the lines

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

  • The completeness evidence is self-assessed: the 46-requirement benchmark was extracted by the authors from a small set of studies (one their own prior work), and the field-level mapping was done by the standard's creators; an independent extraction could yield different coverage numbers.
  • The admitted gap for the EU AI Act's 'parties involved in testing' obligation suggests the 13-of-14 claim represents representational coverage rather than full regulatory compliance; a deployment would need a supplementary mechanism for that element.
  • The same Action-Research-plus-profile-extension process could be tested on other evolving domains, such as agentic AI or hardware-software co-design, to see whether it generalizes as a standardization method.
  • A direct comparison of AIBOM against a competing ML-BOM format on the same requirement set would sharpen the evidence that the SPDX approach is the practical one.
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 reports the design and development of the AIBOM specification, an extension of SPDX 3.0 (AI and Dataset profiles) for documenting AI components in software supply chains. It describes a multi-year open standards effort (82 meetings, 92 participants), framed retrospectively as an Action Research (AR) process, and claims to deliver a validated artifact. Validation is presented through four complementary approaches: alignment with the EU AI Act, EU/US medical-device regulations, and IEEE 7000 standards; mapping to six CISA use cases operationalized into 46 atomic requirements; ten practitioner interviews; and an industrial case study. The paper also distills lessons for open standardization in fast-moving domains and outlines future work toward an FMwareBOM.

Significance. The process documentation is a genuine contribution: the descriptive facts—82 meetings, 92 participants, 16 accepted PRs out of 20, the SPDX 3.0 release date, and public meeting records—are credible and useful for the SE community. The AIBOM specification itself has real-world traction as part of SPDX 3.0, which makes this more than a paper-only artifact. The four validation approaches are a reasonable triangulation, and the interview mapping (Section 5.3) is presented in a checkable form. However, the quantitative validation claims—13/14, >90%, 46/46, 100%/60%/40%—rest on self-produced mappings and unverifiable case-study data, with no independent audit or negative control. The AR framing is also explicitly retrospective, which weakens the 'AR at scale' contribution. The paper is likely to be a useful experience report, but its central claim of a 'validated artefact' is currently stronger than the evidence presented.

major comments (4)
  1. [§5.2 (Steps 3–5), Table 3] The headline result 'all 46 distinct requirements representable' is not independently auditable as reported. Requirement extraction was performed by the third author alone; Step 5 verification was done by the first author, who also co-authored one of the eight source studies ([76]). No extraction protocol, inclusion/exclusion criteria, or inter-rater reliability metric is provided. The traceability matrix is not included in the paper—the reader is referred to a Figshare artifact [78]. External feedback came from two affiliated working groups (12 and 4 attendees) with no formal assessment instrument. There is no negative-control mapping of the same 46 requirements to CycloneDX ML-BOM, so the result does not show that AIBOM's coverage is distinctive or that the benchmark is not biased toward SPDX-style fields. Please include the full requirement-to-field matrix in an appendix, add independ
  2. [§5.1, Results] The regulatory alignment numbers (13 of 14 EU AI Act information obligations; 'all required elements' from medical-device regulations; 'more than 90%' coverage of IEEE 7000 subclauses) are produced by the specification's own developers (fourth and fifth authors) with review by the first and sixth authors, but no coding protocol or inter-rater reliability is reported. The denominator for the IEEE 7000 percentage is never stated: 'over 40 subclauses' is not a proportion. The clause-level mapping is delegated to the whitepaper [15], so a reader cannot verify the coverage claims from this manuscript. Provide the clause-to-field mapping in the paper or appendix, state the denominator, and describe how the alignment assessment was made reproducible.
  3. [§5.4, Results] The industrial case study is the only evidence of AIBOM's practical utility in a real deployment, yet it is reported as four unverifiable numbers: 'all' checklist fields populated, 60% of model-card fields extracted, and 40% of third-party AIBOM fields automated. The checklist, model-card set, web-scraping/API scripts, organizational context, and underlying data are not provided. The study is described only via an acknowledgements sentence naming Helen Oakley and Rhea Michael Anthony, not as part of the authored methods. Include de-identified instruments, clear denominators, and the raw extraction data, or reposition the case study as anecdotal evidence rather than a validation result.
  4. [§6, Table 6] The AR framing is explicitly retrospective: the text states, 'we did not initially conceive this project as AR.' As written, the paper demonstrates only that the standard's development can be mapped onto the AR cycle, not that AR guided the effort. This weakens the claimed contribution of 'AR at scale' and the 'blueprint' for future standardization. The paper should prominently state this limitation and distinguish retrospective mapping from a prospective application of the AR method; otherwise the methodological claim outruns the evidence.
minor comments (5)
  1. [§3.2, Outcome 2] The text says the final specification defined 36 fields, then states '20 for the AI profile ... and 18 for the Dataset profile' (20+18=38). Clarify whether the two counts include overlapping fields reused from Core/Software profiles or correct the arithmetic.
  2. [§5.1, Results] 'Over 40 subclauses' and 'more than 90% overall coverage' need an explicit denominator and a statement of how a subclause was counted as covered. This is related to the reproducibility point in the major comments, but the wording is also internally imprecise.
  3. [Table 3] The column header 'number of mapped fields' is ambiguous: it is unclear whether the numbers represent distinct fields, occurrences, or multiple fields per requirement. Add a legend and explain why the same field may be counted multiple times across studies.
  4. [References [15], [78]] The paper relies on the whitepaper and the Figshare artifact for its core mapping results. Even if full reproductions cannot fit in the page limit, at least one representative mapping (e.g., one study's requirements to AI/Dataset fields) should appear in the paper so a reader can judge the mapping quality without leaving the manuscript.
  5. [§5.3] The interview study is a useful sanity check, but the sample of n=10 recruited from the authors' professional networks and the lack of saturation analysis should be acknowledged in the text as limitations when the results are cited.

Circularity Check

0 steps flagged · score 2.0 of 10

Self-assessed validation and minor self-citation, but no derivation-equals-input circularity.

full rationale

This is an experience report rather than a derivation: the central claim is that the SPDX AIBOM specification is a validated artifact, supported by four empirical validation exercises (regulatory/standards alignment, use-case mapping, interviews, and an industrial case study). None of these exercises predicts a quantity from an input that contains that quantity; there is no fitted parameter renamed as a prediction and no equation-level reduction. The most self-referential element is methodological. In §5.2, the third author extracts atomic requirements from eight studies and the first author 'independently verified the extractions and mappings' (Step 5), while the first author is also a co-author of one of those eight studies [76]; the traceability matrix is authored by the standard's creators and is only available via a Figshare DOI [78], not in the paper. This weakens the independence and auditability of the headline 'all 46 distinct requirements' coverage claim, and the paper itself concedes that 'additional time would be required for an exhaustive, line-by-line review.' However, this is a threat to validity and reproducibility, not definitional circularity: the mappings are not forced by construction, the EU AI Act result is explicitly partial (13 of 14), and the use-case requirements originate from external CISA documents and external studies. The practitioner interviews (§5.3) were conducted without showing participants the proposed fields, and the industrial case study (§5.4) uses an outside organization's checklists, providing content independent of the field definitions. Self-citations such as [15], [76], and [78] are used as pointers or evidence sources, but the central claim does not reduce to them. No circular step meeting the quoted-reduction bar is therefore identified; the score reflects minor self-citation and self-assessment rather than load-bearing circularity.

Assumptions & free parameters 0 free parameters · 5 assumptions · 2 invented entities

No fitted numerical parameters: the central freedom is definitional, not statistical. The paper's degrees of freedom are which fields to include, which studies and requirements count as evidence, which regulations to map, and whether retrospective AR mapping is accepted as methodology; these are logged as axioms and invented entities.

assumptions (5)
  • domain assumption SPDX is the correct base standard for representing AI supply chains
    The entire effort extends SPDX rather than comparatively evaluating CycloneDX or a new format; §2.2 notes alternatives but provides no selection justification.
  • ad hoc to paper The 46 atomic requirements extracted from eight studies are a complete and valid benchmark
    §5.2 Step 3: extraction by the third author from studies that include the authors' own prior work [76]; no inter-rater reliability or external benchmark was used.
  • domain assumption Retrospective mapping to the Action Research cycle is valid evidence of a disciplined process
    §6 states 'we did not initially conceive this project as AR', yet the canonical AR cycle is used as a 'replicable blueprint' for future standardization.
  • domain assumption Practitioner interview findings from n=10 participants generalize to the broader practitioner population
    §5.3: participants were recruited via direct email to known experts; small, convenience-sampled group with no saturation analysis.
  • ad hoc to paper The industrial case study is accurately represented by the authors
    §5.4 and the acknowledgements relay results from external practitioners secondhand; no raw checklists, model cards, or organizational artifacts are provided to verify the claims.
invented entities (2)
  • AIBOM specification (SPDX 3.0 AI and Dataset profiles) independent evidence
    purpose: Machine-readable metadata for AI datasets, models, training, and risks within software supply chains.
    Public SPDX 3.0 model repository and Linux Foundation whitepaper give implementers a handle; the four validations are mostly self-generated, but the schema itself is externally checkable.
  • FMwareBOM (planned evolution)
    purpose: Capture agents, grounding, guardrails, and prompts for foundation-model-powered software.
    §7.2 is a roadmap only; no schema or artifact is presented in this paper, so there is no falsifiable handle.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Building an Open AIBOM Standard in the Wild." pith.science (2026). https://pith.science/paper/BUHNY3XY

@misc{pith2026251007070,
  author       = {Pith},
  title        = {Pith review of: Building an Open AIBOM Standard in the Wild},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BUHNY3XY}},
  note         = {Machine review of arXiv:2510.07070}
}
read the original abstract

Modern software engineering increasingly relies on open, community-driven standards, yet how such standards are created in fast-evolving domains like AI-powered systems remains underexplored. This paper presents a detailed experience report on the development of the AI Bill of Materials AIBOM specification, an extension of the ISO/IEC 5962:2021 Software Package Data Exchange (SPDX) software bill of materials (SBOM) standard, which captures AI components such as datasets and iterative training artifacts. Framed through the lens of Action Research (AR), we document a global, multi-stakeholder effort involving over 90 contributors and structured AR cycles. The resulting specification was validated through four complementary approaches: alignment with major regulations and ethical standards (e.g., EU AI Act and IEEE 7000 standards), systematic mapping to six industry use cases, semi-structured practitioner interviews, and an industrial case study. Beyond delivering a validated artefact, our paper documents the process of building the AIBOM specification in the wild, and reflects on how it aligns with the AR cycle, and distills lessons that can inform future standardization efforts in the software engineering community.

Figures

Figures reproduced from arXiv: 2510.07070 by the authors.

Figure 1
Figure 1. Overview of AIBOM standard creation process and [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overview of SPDX profiles and their extensions for [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. When Model Release Meets Model Reuse: Producer-Consumer Misalignment in Hugging Face

    cs.SE 2026-07 conditional novelty 7.0 of 10

    Producers and consumers of pre-trained models rely on the same documentation but systematically disagree on where metadata belongs, why lineage is traced, and which governance mechanisms help.

  2. On AI Safety and Security Technical Debt in Engineering AI-Enabled Systems

    cs.SE 2026-07 conditional novelty 5.0 of 10

    The authors synthesize 31 AI technical debt types from 60 studies, map them to safety/security concerns, and propose 34 mitigation guidelines in the AITD-MAP framework.

Reference graph

Works this paper leans on

104 extracted references · 13 canonical work pages · cited by 2 Pith papers

  1. [76]

    Gopi Krishnan Rajbahadur, Erika Tuck, Li Zi, Dayi Lin, Boyuan Chen, Zhen Ming, Daniel M German, et al. 2021. Can I use this publicly available dataset to build commercial AI software?–A Case Study on Publicly Available Image Datasets.arXiv preprint arXiv:2111.02374(2021)

    arXiv 2021

  2. [78]

    Elyas Rashno. 2025. AIBOM_SPDX_Mapping_To_UseCases. https://doi.org/10. 6084/m9.figshare.30234535.v1. https://doi.org/10.6084/m9.figshare.30234535.v1 Dataset

    work page doi:10.6084/m9.figshare.30234535.v1 2025

  3. [15]

    2024.Implementing AI Bill of Materials (AI BOM) with SPDX 3.0

    Karen Bennet, Gopi Krishnan Rajbahadur, Arthit Suriyawongkul, and Kate Stew- art. 2024.Implementing AI Bill of Materials (AI BOM) with SPDX 3.0. Technical Report. The Linux Foundation. https://doi.org/10.70828/RNED4427

    work page doi:10.70828/rned4427 2024

  4. [1]

    Hugging Face Model Cards

    2022. Hugging Face Model Cards. https://huggingface.co/docs/hub/en/model- cards

    2022

  5. [2]

    EU AI ACT

    2023. EU AI ACT. https://github.com/stanford-crfm/EUAIActJune15/blob/main/ requirements.md

    2023

  6. [3]

    Identifying and Eliminating CSAM in Generative ML Training Data and Models

    2023. Identifying and Eliminating CSAM in Generative ML Training Data and Models. https://purl.stanford.edu/kh752sm9123?ref=404media.co

    2023

  7. [4]

    Machine Learning Bill of Materials (ML-BOM)

    2024. Machine Learning Bill of Materials (ML-BOM). https://cyclonedx.org/ capabilities/mlbom/

    2024

  8. [5]

    AI Factsheets

    2025. AI Factsheets. https://www.ibm.com/docs/en/software-hub/5.1.x?topic= services-ai-factsheets

    2025

Show all 104 references
  1. [6]

    AI SBOM Tiger Team

    2025. AI SBOM Tiger Team. https://github.com/aibom-squad

    2025

  2. [7]

    SPDX Specification Releases

    2025. SPDX Specification Releases. https://github.com/spdx/spdx-spec/releases. Accessed: 2025-09-30

    2025

  3. [8]

    NIST AI. 2023. Artificial intelligence risk management framework (AI RMF 1.0). URL: https://nvlpubs. nist. gov/nistpubs/ai/nist. ai(2023), 100–1

    2023

  4. [9]

    Abdullah Alqahtani, Shadi Banitaan, and Sawsan Banitaan. 2017. A systematic literature review of software risk management for global software development. In2017 IEEE/ACS 14th International Conference on Computer Systems and Appli- cations (AICCSA). IEEE, 1310–1317. https://do...

    2017 doi

  5. [10]

    David Avison, Richard Baskerville, and Michael Myers. 1999. Action research. Commun. ACM42, 1 (1999), 94–97

    1999

  6. [11]

    Iain Barclay, Alun Preece, Ian Taylor, Swapna Krishnakumar Radha, and Jarek Nabrzyski. 2023. Providing assurance and scrutability on shared data and ma- chine learning models with verifiable credentials.Concurrency and Computation: Practice and Experience35, 18 (2023), e6997

    2023

  7. [12]

    Iain Barclay, Alun Preece, Ian Taylor, and Dinesh Verma. 2019. Towards trace- ability in data ecosystems using a bill of materials model.arXiv preprint arXiv:1904.04253(2019)

    2019 arXiv

  8. [13]

    Baskerville

    Richard L. Baskerville. 1999. Investigating Information Systems with Action Research.Communications of the Association for Information Systems2 (1999). https://doi.org/10.17705/1cais.00219

    1999 doi

  9. [14]

    Carlo Benedetti, Francesco Cofano, et al. 2024. The Impact of SBOM Generators on Vulnerability Assessment in Python: A Comparison and a Novel Approach. InInternational Conference on Software Engineering and Security. Springer. https: //link.springer.com/chapter/10.1007/978-3-0...

    2024 doi

  10. [16]

    2019.The Relationship Between Open Source Software and Standard Setting

    Knut Blind and Margarete Böhm. 2019.The Relationship Between Open Source Software and Standard Setting. Technical Report JRC116106. Joint Research Centre (JRC), European Commission. https://publications.jrc.ec.europa.eu/ repository/handle/JRC116106

    2019

  11. [17]

    Center for Devices and Radiological Health. 2025. Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions

    2025

  12. [18]

    Joint Research Centre

    European Commission. Joint Research Centre. 2019.The relationship between open source software and standard setting.Publications Office, LU. https: //doi.org/10.2760/163594

    2019 doi

  13. [19]

    Coalition for Secure AI. 2024. SAIF Risk Assessment: A new tool to help secure AI systems across industry. https://www.coalitionforsecureai.org/google- saif-risk-assessment/. https://www.coalitionforsecureai.org/google-saif-risk- assessment/ Describes Google’s tool for assessi...

    2024

  14. [20]

    SPDX contributors. 2024. SPDX Meeting Notes. https://github.com/spdx/ meetings/tree/main/ai. [Accessed 09-08-2024]

    2024

  15. [21]

    Shane Coughlan. 2022. OpenChain Work Groups – New and Improved Struc- ture. https://openchainproject.org/news/2022/10/12/wg-structure. https: //openchainproject.org/news/2022/10/12/wg-structure OpenChain Project news announcement

    2022

  16. [22]

    Cybersecurity and Infrastructure Security Agency. 2025. 2025 Mini- mum Elements for a Software Bill of Materials (SBOM) Public Com- ment Draft. https://www.cisa.gov/resources-tools/resources/2025-minimum- elements-software-bill-materials-sbom

    2025

  17. [23]

    2023.Software Bill of Materials (SBOM) Sharing and Use: A Guide for Organizations

    Cybersecurity and Infrastructure Security Agency (CISA). 2023.Software Bill of Materials (SBOM) Sharing and Use: A Guide for Organizations. Technical Report. U.S. Department of Homeland Security. https://www.cisa.gov/resources- ICSE-SEIP 2026, April 12–18, 2026, Rio De Janeiro...

    2023

  18. [24]

    Cybersecurity and Infrastructure Security Agency (CISA). 2025. CISA SBOM-a- rama. https://www.cisa.gov/resources-tools/resources/cisa-sbom-rama. https: //www.cisa.gov/resources-tools/resources/cisa-sbom-rama Recordings and resources from the CISA SBOM-a-rama event series

    2025

  19. [25]

    Alan M. Davis. 1993. The software requirements specification: A roadmap. Journal of Systems and Software21, 2 (1993), 179–188. https://doi.org/10.1016/ 0164-1212(93)90040-T

    1993

  20. [26]

    Valeria de Castro, María Luz Martín-Peña, Esperanza Marcos Martínez, and Maricela Salgado. 2025. Combining Action Research With Design Science as a Qualitative Research Methodology. An Application to Service (Operations) Management Research.International Journal of Qualitative...

    2025 doi

  21. [27]

    2024.Action Research with Industrial Software Engineering: An Educational Perspective

    Yvonne Dittrich, Johan Bolmsten, and Cathrine Seidelin. 2024.Action Research with Industrial Software Engineering: An Educational Perspective. Springer, 413–

    2024

  22. [28]

    Ecma International. 2024. CycloneDX Bill of Materials Specification. https: //ecma-international.org/publications-and-standards/standards/ecma-424/

    2024

  23. [29]

    Chisholm

    Max Elden and Rupert F. Chisholm. 1993. Emerging Varieties of Action Research: Introduction to the Special Issue.Human Relations46, 2 (Feb. 1993), 121–142. https://doi.org/10.1177/001872679304600201

    1993 doi

  24. [30]

    Arnold et al. 2019. FactSheets: Increasing trust in AI services through supplier’s declarations of conformity.IBM Journal of Research and Development63, 4/5 (July 2019), 6:1–6:13. https://doi.org/10.1147/jrd.2019.2942288

    2019

  25. [31]

    Akhtar et al. 2024. Croissant: A Metadata Format for ML-Ready Datasets. In Proc. 8th Workshop on Data Management for End-to-End ML (DEEM)

    2024

  26. [32]

    European Parliament and Council of the European Union. 2017. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on Medical Devices, Amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and Repealing Cou...

    2017

  27. [33]

    European Parliament and Council of the European Union. 2024. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 Laying down Harmonised Rules on Artificial Intelligence and Amending Regulations (EC) No 300/2008, (EU) No 167/2013, (EU) No 168...

    2024

  28. [34]

    Norman E Fenton and Martin Neil. 2002. A strategy for improving safety related software engineering standards.IEEE transactions on software engineering24, 11 (2002), 1002–1013

    2002

  29. [35]

    social good

    Maria Angela Ferrario, Will Simm, Peter Newman, Stephen Forshaw, and Jon Whittle. 2014. Software engineering for “social good”: integrating ac- tion research, participatory design, and agile development. InCompanion Proc. of the Int’l Conf. on Software Engineering (ICSE ’14). ...

    2014

  30. [36]

    The Linux Foundation. 2024. SPDX 3.0 Revolutionizes Software Management in Systems with Enhanced Functionality and Streamlined Use Cases — linux- foundation.org. https://www.linuxfoundation.org/press/spdx-3-revolutionizes- software-management-in-systems-with-enhanced-functiona...

    2024

  31. [37]

    The Linux Foundation. 2025. SPDX Specification. https://spdx.dev/ specifications/. Accessed: 4 September 2025

    2025

  32. [38]

    Timnit Gebru, Jamie Morgenstern, Briana Vecchione, Jennifer Wortman Vaughan, Hanna Wallach, Hal Daumé Iii, and Kate Crawford. 2021. Datasheets for datasets.Commun. ACM64, 12 (2021), 86–92

    2021

  33. [39]

    Pan- dit, Sven Schade, Declan O’Sullivan, and Dave Lewis

    Delaram Golpayegani, Isabelle Hupont, Cecilia Panigutti, Harshvardhan J. Pan- dit, Sven Schade, Declan O’Sullivan, and Dave Lewis. 2024. AI Cards: Towards an Applied Framework for Machine-Readable AI and Risk Documentation In- spired by the EU AI Act. InPrivacy Technologies an...

    2024 doi

  34. [40]

    Ahmed E Hassan, Dayi Lin, Gopi Krishnan Rajbahadur, Keheliya Gallaba, Fil- ipe Roseiro Cogo, Boyuan Chen, Haoxiang Zhang, Kishanthan Thangarajah, Gustavo Oliva, Jiahuei Lin, et al. 2024. Rethinking software engineering in the era of foundation models: A curated catalogue of ch...

    2024

  35. [41]

    Rashina Hoda, James Noble, and Stuart Marshall. 2017. The impact of inadequate customer collaboration on self-organizing Agile teams.Information and Software Technology88 (2017), 20–30. https://doi.org/10.1016/j.infsof.2017.03.004

    2017 doi

  36. [42]

    Hugging Face. 2025. Hugging Face Hub API Endpoints. https://huggingface. co/docs/hub/en/api [Accessed 12-01-2025]

    2025

  37. [43]

    IEEE 802.11 Working Group. 2023. IEEE 802.11 Standards Development Process. https://www.ieee802.org/11/

    2023

  38. [44]

    2024.IEEE Draft Recommended Practice for Ethical Considerations of Emulated Empathy in Partner-based General-Purpose Artificial Intelligence Systems

    IEEE P7014.1 Working Group (EEEPG). 2024.IEEE Draft Recommended Practice for Ethical Considerations of Emulated Empathy in Partner-based General-Purpose Artificial Intelligence Systems. Technical Report. IEEE Standards Association. https://standards.ieee.org/ieee/7014.1/11609/...

    2024

  39. [45]

    IEEE Standards Association. 2023. IEEE-SA Standards Development Lifecycle. https://standards.ieee.org/develop/

    2023

  40. [46]

    International Organization for Standardization. 2023. ISO/IEC Directives, Part 1: Procedures for the technical work. https://www.iso.org/sites/directives/current/ consolidated/index.html

    2023

  41. [47]

    International Organization for Standardization and International Electrotech- nical Commission. 2021. ISO/IEC 5962:2021 Information Technology — SPDX Specification V2.2.1

    2021

  42. [48]

    Jim Isaak. 2005. POSIX – Inside: A Case Study. InProceedings of the IEEE International Symposium on Technology and Society (ISTAS). 1–6. https://doi. org/10.1109/ISTAS.2005.1451989

    2005 arXiv

  43. [49]

    ISO/IEC. 2015. ISO/IEC 19770-2:2015 Information technology — Software asset management — Software identification tag (SWID tag). https://www.iso.org/ standard/65666.html. Accessed: 4 September 2025

    2015

  44. [50]

    Hal Jespersen. 1995. POSIX Retrospective.StandardView3, 1 (March 1995), 2–10. https://doi.org/10.1145/210308.210313

    1995

  45. [51]

    Wenxin Jiang, Jerin Yasmin, Jason Jones, Nicholas Synovic, Jiashen Kuo, Nathaniel Bielanski, Yuan Tian, George K Thiruvathukal, and James C Davis

  46. [52]

    Jianxin Jiao, Mitchell M Tseng, Qinhai Ma, and Yi Zou. 2000. Generic bill-of- materials-and-operations for high-variety production management.Concurrent Engineering8, 4 (2000), 297–321

    2000

  47. [53]

    Andrew Josey. 2012. Committee Maintenance Procedures for the Approved Standard

    2012

  48. [54]

    Omer F Keskin, Kevin Matthe Caramancion, Irem Tatar, Owais Raza, and Unal Tatar. 2021. Cyber third-party risk management: A comparison of non-intrusive risk scoring reports.Electronics10, 10 (2021), 1168

    2021

  49. [55]

    Yue Liu, Dawen Zhang, Boming Xia, Julia Anticev, Tunde Adebayo, Zhenchang Xing, and Moses Machao. 2024. Blockchain-Enabled Accountability in Data Supply Chain: A Data Bill of Materials Approach. InInt’l Conf. on Blockchain (Blockchain). IEEE, 557–562

    2024

  50. [56]

    Shayne Longpre, Robert Mahari, Anthony Chen, Naana Obeng-Marnu, Damien Sileo, William Brannon, Niklas Muennighoff, Nathan Khazam, Jad Kabbara, Kartik Perisetla, et al. 2023. The data provenance initiative: A large scale audit of dataset licensing & attribution in ai. (2023)

    2023

  51. [57]

    Qinghua Lu, Liming Zhu, Xiwei Xu, Jon Whittle, and Zhenchang Xing. 2022. Towards a roadmap on software engineering for responsible AI. InProceedings of the 1st Int’l Conf. on AI Engineering: software Engineering for AI. 101–112

    2022

  52. [58]

    2023.Improving Transparency, Trust, and Automation in the Software Supply Chain

    Daniele Martini. 2023.Improving Transparency, Trust, and Automation in the Software Supply Chain. Ph. D. Dissertation. University of Camerino. https: //tesidottorato.depositolegale.it/handle/20.500.14242/193708

    2023

  53. [59]

    Mihai Maruseac, Kate Stewart, Hasan Yasar, and David A. Wheeler. 2025. Panel Discussion: Strengthening Software Supply Chains: Harmonizing SLSA Prove- nance and SPDX SBOM for Better Adoption. InOpen Source Summit North America 2025. https://ossna2025.linuxfoundation.org Panel ...

    2025

  54. [60]

    Microsoft. 2022. Microsoft Responsible AI Standard, v2 General Requirements

    2022

  55. [61]

    Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasser- man, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, and Timnit Ge- bru. 2019. Model Cards for Model Reporting. InProceedings of the Confer- ence on Fairness, Accountability, and Transparency (FAT...

    2019

  56. [62]

    Éamonn Ó Muirí. 2019. Framing software component transparency: Establishing a common software bill of material (sbom).NTIA, Nov12 (2019)

    2019

  57. [63]

    National Telecommunications and Information Administration (NTIA). 2021. The Minimum Elements for a Software Bill of Materials (SBOM). Technical Report. U.S. Department of Commerce. https://www.ntia.gov/report/2021/minimum- elements-software-bill-materials-sbom The NTIA SBOM i...

    2021

  58. [64]

    NquiringMinds LTD. 2025. TAIBOM. https://taibom.nqminds.com/

    2025

  59. [65]

    2023.A Comparative Analysis of SBOM Standards: SPDX, Cy- cloneDX, and SWID

    OASIS Open. 2023.A Comparative Analysis of SBOM Standards: SPDX, Cy- cloneDX, and SWID. Technical Report. OASIS Open Technical Commit- tee. https://www.oasis-open.org/resources/open-reports/sbom-standards- comparison Provides a detailed comparison of SPDX, CycloneDX, and SWID,...

    2023

  60. [66]

    The United States Department of Commerce. 2021. The Minimum Elements for a Software Bill of Materials (SBOM). https://www.ntia.gov/report/2021/minimum- elements-software-bill-materials-sbom. Building an Open AIBOM Standard in the Wild ICSE-SEIP 2026, April 12–18, 2026, Rio De ...

    2021

  61. [67]

    Open Source Security Foundation (OpenSSF). 2025. OpenSSF AI/ML Se- curity Working Group. https://openssf.org/groups/ai-ml-security/. https: //openssf.org/groups/ai-ml-security/ Working group on security for AI/ML, exploring risks such as data poisoning, prompt injection, adver...

    2025

  62. [68]

    OpenChain Project / The Linux Foundation. 2025. OpenChain – Building Trust In The Supply Chain. https://openchainproject.org/. https://openchainproject.org/ Open source supply chain standards and reference materials

    2025

  63. [69]

    OpenSSF / SLSA Project. 2025. SLSA: Safeguarding Artifact Integrity Across the Software Supply Chain. https://slsa.dev/. https://slsa.dev/ Security framework and community for software supply chain integrity

    2025

  64. [70]

    Ernesto Lang Oreamuno, Rohan Faiyaz Khan, Abdul Ali Bangash, Catherine Stinson, and Bram Adams. 2024. The state of documentation practices of third- party machine learning models and datasets.IEEE Software41, 5 (2024), 52–59

    2024

  65. [71]

    OWASP. 2025. CycloneDX Specification. https://github.com/CycloneDX/ specification/. Accessed: 4 September 2025

    2025

  66. [72]

    Kai Petersen, Cigdem Gencel, Hamed Asghari, Dejan Baca, and Stefanie Betz

  67. [73]

    Shari Lawrence Pfleeger, Norman Fenton, and Stella Page. 2002. Evaluating software engineering standards.Computer27, 9 (2002), 71–79

    2002

  68. [74]

    Erik Nordström Qvarfordt. 2024. Exploring the Dynamics of Software Bill of Materials (SBOMs) and Security Integration in Open Source Projects. https: //www.diva-portal.org/smash/record.jsf?pid=diva2%3A1844757

    2024

  69. [75]

    Gopi Krishnan Rajbahadur, Gustavo A Oliva, Dayi Lin, and Ahmed E Hassan

  70. [77]

    Paul Ralph. 2016. The role of power in requirements engineering.Requirements Engineering21, 3 (2016), 297–313. https://doi.org/10.1007/s00766-014-0207-5

    2016 doi

  71. [79]

    From Cool Demos to Production-Ready FMware: Core Challenges and a Technology Roadmap.arXiv preprint arXiv:2410.20791(2024)

    2024 arXiv

  72. [80]

    Marius Schlegel and Kai-Uwe Sattler. 2023. Management of machine learning lifecycle artifacts: A survey.ACM SIGMOD Record51, 4 (2023), 18–35

    2023

  73. [81]

    2000.Implementing the IEEE software engineering standards

    Michael E Schmidt. 2000.Implementing the IEEE software engineering standards. Sams

    2000

  74. [82]

    David Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Diet- mar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, and Dan Dennison. 2015. Hidden technical debt in machine learning systems.Advances in neural information processing systems28 (2015)

    2015

  75. [83]

    SBOM for AI Tiger Team. 2025. SBOM for AI (AIBOM) Tiger Team Work- ing Group Document. https://docs.google.com/document/d/1IpXG7XBOJnPl_ hwFf3JZkDaFb0k2CnI0/edit?rtpof=true#heading=h.gjdgxs. Accessed: 2025-09- 30

    2025

  76. [84]

    SPDX Project / Linux Foundation. 2025. SPDX Implementers Mailing List. https: //lists.spdx.org/g/spdx-implementers. Mailing list for developers implementing SPDX-interoperable tools

    2025

  77. [85]

    SPDX Working Group. 2025. SPDX 3 Model - Milestone 3.1. https://github. com/spdx/spdx-3-model/milestone/3. https://github.com/spdx/spdx-3-model/ milestone/3 Milestone 3.1 in the development of the SPDX 3 model on GitHub

    2025

  78. [86]

    SPDX Working Group. 2025. SPDX 3.0 Proposal: Adaptation Events, Fine- tuning Lineage, and Downstream Modifications. https://github.com/spdx/spdx- 3-model/pull/1100. Accessed: 2025-09-28

    2025

  79. [87]

    Dag I. K. Sjøberg, Tore Dyba, and Magne Jorgensen. 2007. The Future of Empirical Methods in Software Engineering Research. InFuture of Software Engineering (FOSE ’07). IEEE, 358–378. https://doi.org/10.1109/fose.2007.30

    2007 doi

  80. [88]

    SPDX Working Group. 2025. SPDX 3.0 Proposal: Provenance Links for Dataset Generation Prompts and Retrieval Contexts. https://github.com/spdx/spdx-3- model/pull/892. Accessed: 2025-09-28

    2025

  81. [89]

    Sarah Spiekermann. 2017. IEEE P7000—The First Global Standard Process for Addressing Ethical Concerns in System Design.Proceedings1, 3 (2017), 159. https://doi.org/10.3390/IS4SI-2017-04084

    2017 doi

  82. [90]

    Trevor Stalnaker, Nathan Wintersgill, Oscar Chaparro, Massimiliano Di Penta, Daniel M German, and Denys Poshyvanyk. 2024. BOMs Away! Inside the Minds of Stakeholders: A Comprehensive Study of Bills of Materials for Software Systems. InInt’l Conf. on Software Engineering (ICSE ...

    2024

  83. [91]

    SPDX Working Group. 2025. SPDX 3.0 Proposal: Agent Identity and Capabilities Fields. https://github.com/spdx/spdx-3-model/pull/1091. Accessed: 2025-09-28

    2025

  84. [92]

    2020.Action Research in Software Engineering: Theory and Applications

    Miroslaw Staron. 2020.Action Research in Software Engineering: Theory and Applications. Springer International Publishing. https://doi.org/10.1007/978-3- 030-32610-4

    2020 doi

  85. [93]

    Miroslaw Staron. 2025. Guidelines for Conducting Action Research Studies in Software Engineering.e-Informatica Software Engineering Journal19, 1 (2025), 250105. https://doi.org/10.37190/e-Inf250105

    2025 doi

  86. [94]

    Stuart Sutherland. 2002. Verilog, the Next Generation: Accellera’s SystemVerilog. InProceedings of the HDL Conference

    2002

  87. [95]

    Trevor Stalnaker, Nathan Wintersgill, Oscar Chaparro, Laura A Heymann, Mas- similiano Di Penta, Daniel M German, and Denys Poshyvanyk. 2025. The ML supply chain in the era of software 2.0: Lessons learned from Hugging Face. arXiv preprint arXiv:2502.04484(2025)

    2025

  88. [96]

    2022.Essentials of software engineering

    Frank Tsui, Orlando Karam, and Barbara Bernal. 2022.Essentials of software engineering. Jones & Bartlett Learning

    2022

  89. [97]

    Ohlsson, Björn Regnell, and Anders Wesslén

    Claes Wohlin, Per Runeson, Martin Höst, Magnus C. Ohlsson, Björn Regnell, and Anders Wesslén. 2012.Experimentation in Software Engineering. Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-29044-2

    2012 doi

  90. [98]

    Boming Xia, Tingting Bi, Zhenchang Xing, Qinghua Lu, and Liming Zhu. 2023. An Empirical Study on Software Bill of Materials: Where We Stand and the Road Ahead. InInt’l Conf. on Software Engineering (ICSE). IEEE. https://doi.org/ 10.1109/icse48619.2023.00219

    2023

  91. [99]

    The Open Group. 2022. The Austin Group: POSIX Standardization. https: //www.opengroup.org/austin

    2022

  92. [100]

    Boming Xia, Dawen Zhang, Yue Liu, Qinghua Lu, Zhenchang Xing, and Liming Zhu. 2024. Trust in software supply chains: Blockchain-enabled sbom and the aibom future. InInt’l Workshop on Engineering and Cybersecurity of Critical Systems (EnCyCriS) and 2nd Int’l Workshop on Softwar...

    2024

  93. [103]

    Boming Xia, Tingting Bi, Zhenchang Xing, Qinghua Lu, and Liming Zhu. 2023. An empirical study on software bill of materials: Where we stand and the road ahead. InInt’l Conf. on Software Engineering (ICSE). IEEE, 2630–2642

    2023

  94. [461]

    https://doi.org/10.1007/978-3-031-71769-7_15

    doi

  95. [2014]

    Action research as a model for industry-academia collaboration in the software engineering context. InProc. of the Int’l Conf. on Software Engineering (ICSE) Companion. ACM, 43–46

  96. [2024]

    InProceedings of the 21st International Conference on Mining Software Repositories

    Peatmoss: A dataset and initial analysis of pre-trained models in open- source software. InProceedings of the 21st International Conference on Mining Software Repositories. 431–443

Pith tools

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