SoFAIR Workflow: Repository-Centric Software Lifecycle
- SoFAIR Workflow is a repository-centered, machine-assisted process that transforms software mentions into validated bibliographic records.
- It integrates tools like GROBID and Softcite to extract and validate software mentions from manuscripts, ensuring accurate linkage to archival repositories.
- The workflow enhances FAIR principles by assigning persistent identifiers and enabling discoverability, attribution, and long-term reusability of research software.
Searching arXiv for the core SoFAIR workflow papers and adjacent FAIR-workflow literature. SoFAIR Workflow is a machine-assisted, repository-centered workflow for the research software lifecycle in which software that is often hidden inside research manuscripts is identified, validated, registered with persistent identifiers, archived, and disseminated so that it can function as a first-class bibliographic record. Developed in the SoFAIR project (2024–2025), the workflow extends infrastructures including CORE, Software Heritage, HAL, and GROBID, and organizes a sequence from software-mention extraction in full text to author validation, archival, and PID-backed exposure in repository metadata (Knoth et al., 8 Jan 2025, Cancellieri et al., 4 Aug 2025).
1. Concept and problem setting
The SoFAIR Workflow addresses a specific failure mode in scholarly communication: research software is frequently mentioned only in the text of manuscripts, often as a name, URL, or informal mention, and is therefore not a first-class bibliographic object. The consequences described in the literature are poor discoverability, weak attribution, limited reusability, lack of persistent identifiers, and weak alignment with the FAIR principles. In this setting, software is not absent from research practice; rather, it is obscured within narrative publication structures and is only weakly connected to repository, archival, and citation infrastructures (Knoth et al., 8 Jan 2025).
The workflow treats this as a cross-system process rather than as a single metadata-cleaning step. The relevant actors are authors, institutional repositories, an aggregator and detection layer centered on CORE, validation by authors or managers, archival and PID assignment by Software Heritage, and interoperable dissemination through COAR Notify. This architecture shifts software recognition from ad hoc citation practice to a managed lifecycle of extraction, validation, registration, archival, and dissemination (Cancellieri et al., 4 Aug 2025).
Within the broader FAIR-workflow literature, computational workflows are treated as research assets with identifiers, metadata, provenance, and qualified references. A plausible implication is that SoFAIR narrows that general agenda to one especially persistent object: the software asset that is introduced by, or used in, a manuscript but is not yet represented as a durable, machine-actionable scholarly object (Wilkinson et al., 2024).
2. End-to-end workflow logic
The workflow begins when an author deposits a piece of research software in a code repository and submits a manuscript containing an explicit or implicit reference to that software. The manuscript is harvested by CORE, and software mentions are extracted from full text using machine-learning tools. Through the CORE Repository Dashboard, the detected mentions become validation requests available to the repository. With repository-manager authorization, the request is routed to the author, typically by email or an internal notification. Once validated, the repository sends an asset registration request to Software Heritage, which archives the software asset permanently, assigns a persistent identifier, and sends it back to the repository. The validated software mention is then announced and disseminated to interested subscribers (Cancellieri et al., 4 Aug 2025).
The same workflow is described in the project paper as a software asset lifecycle: software exists in a code repository, a software mention in a research manuscript is observed, that mention is extracted, enriched, validated, registered, archived in Software Heritage, and then linked back to the paper in repository metadata. This formulation emphasizes that the workflow is intended to operate both on pre-existing content already in repositories and on newly deposited content going forward (Knoth et al., 8 Jan 2025).
In compressed form, the operational chain is:
| Stage | Main operation | Result |
|---|---|---|
| Deposit | Software and manuscript are deposited | Candidate software asset enters repository ecosystem |
| Detection | CORE harvests paper and extracts mentions | Machine-readable software mention |
| Validation | Repository and author review the mention | Confirmed or corrected relationship |
| Registration | Repository requests archival from Software Heritage | Archived software with PID |
| Dissemination | Validated mention is announced | Reusable and discoverable software record |
This workflow makes the software mention itself into a managed relation between manuscript, software asset, repository record, and archival identifier. That relation, rather than the manuscript mention alone, is the core unit of curation.
3. Core infrastructure and division of roles
The SoFAIR Workflow is intentionally repository-centric. CORE acts as aggregator and workflow hub: it harvests papers, identifies and extracts software mentions at scale, de-duplicates across multiple institutional repositories, manages software mentions through the CORE Repository Dashboard, and supports repository managers in checking compliance and validating metadata quality. Repository systems host the manuscript and/or software record, receive and process validation notifications, and may send registration requests to Software Heritage. Software Heritage receives asset registration requests, archives the software permanently, assigns a persistent identifier, and returns that identifier to the repository. HAL is cited as a platform already integrated with a COAR-Notify Inbox and serves as an example of repository infrastructure into which SoFAIR can plug (Cancellieri et al., 4 Aug 2025).
The project paper describes CORE as the scaling layer for the open repository network. It runs the extended GROBID software as part of its ingestion pipeline, applies the workflow to both pre-existing and new open access content, routes newly identified but not yet validated software assets to repository managers via the CORE Repository Dashboard, and adapts ingestion so that repositories can expose explicit links between research outputs and software using metadata and linking protocols such as OpenAIRE, Rioxx, and Signposting (Knoth et al., 8 Jan 2025).
| Component | Role | Functions explicitly described |
|---|---|---|
| Author | Depositor and validator | Deposits software, submits manuscript, validates or corrects mentions |
| Repository / OA repository | Host and routing layer | Hosts records, receives notifications, may send registration requests |
| CORE | Aggregator and workflow hub | Harvests papers, extracts mentions, de-duplicates, manages dashboard |
| COAR Notify Inbox | Inter-system notification endpoint | Receives messages and routes them to approving actors |
| Software Heritage | Archival and PID layer | Archives software permanently and assigns persistent identifiers |
The separation of roles is essential to the workflow’s design. Discovery is delegated to an aggregation and extraction layer; authority over correctness is retained by repositories and authors; durability is delegated to an archival PID service; and dissemination is implemented through a notification protocol rather than through a single centralized platform.
4. Machine-learning extraction and validation mechanics
Software-mention extraction is enabled by full-text processing and machine learning. The principal tools named are GROBID and Softcite. GROBID is described as an open-source machine learning library for extracting, parsing, and restructuring raw PDFs into structured XML/TEI, while Softcite is the software-mention recognizer currently used and extended for multidisciplinary identification, disambiguation, enrichment, and entity matching or alignment. The project targets greater than 80% F1 in a multidisciplinary setting, and the literature notes that prior recognizers can drop by about 20 F-score points in a new scientific domain (Knoth et al., 8 Jan 2025).
The workflow does not treat extraction as sufficient evidence. Detected mentions are surfaced in the CORE Repository Dashboard, whose dedicated Software Mention tab supports viewing detected mentions, filtering by status such as ready for validation, sent, responded to, and cancelled, showing title, authors, status, confidence, software mention context, and software repository link, downloading CSV, approving and sending notifications, and canceling notifications. The system can show a confidence score from the AI tool, and repository managers may choose to notify all authors or only notify when confidence exceeds a threshold (Cancellieri et al., 4 Aug 2025).
Validation is required because detecting a mention does not guarantee its accuracy or validity. The literature explicitly frames the necessary sequence as extraction plus validation plus registration plus dissemination. Validation may be performed by the paper’s author or a designated research manager. The human-facing message contains the paper title, software name, mention context, software repository link, mention type, confidence threshold, institution-specific explanation, and options to Approve, Edit, or Ignore. The user can reject if the software was incorrectly discovered, edit to add more details and improve the software description, or validate, storing the mention in the research graph (Cancellieri et al., 4 Aug 2025).
5. COAR Notify as the interoperability layer
COAR Notify provides the inter-system messaging layer that turns the SoFAIR Workflow into an interoperable distributed process. It is described as a protocol that establishes profiles, constraints, and conventions for using W3C Linked Data Notifications, integrates repository systems with related services, and supports a distributed, resilient, web-native architecture. The reasons given for adopting it are that it is a reusable standard already well known in the repository community, that it already has implementations in major repository software like DSpace, and that it is already integrated in platforms like HAL (Cancellieri et al., 4 Aug 2025).
In the SoFAIR Workflow, when a validation request is triggered, a COAR Notify message is sent to the repository inbox; the repository processes the message and converts it into an action for the approving actor, typically as an email notification or internal notification-system message. The protocol therefore handles inter-system interoperability, while the repository remains responsible for the human-facing channel and authorization logic (Cancellieri et al., 4 Aug 2025).
The software-mention notification pattern is explicitly modeled on a three-stage sequence: offer the relationship between a research paper and a software asset to validate, accept or tentatively accept or reject the relationship, and announce the validated relationship. The message schemas formalize this with payload fields including actor, object, id, sorg:citation, mentionConfidence, mentionType, mentionContext, origin, target, and, in the announcement phase, inReplyTo. sorg:citation is defined as a software description following the CodeMeta standard. This field-level schema turns a software mention into a typed relationship action with traceable state transitions rather than a free-text claim in a manuscript (Cancellieri et al., 4 Aug 2025).
Interoperability in the broader workflow also depends on standards beyond COAR Notify. The project text names OpenAIRE Guidelines v4.0, RIOXX v3, CodeMeta, Signposting, and OAI-PMH as part of the standards basis for exposing software asset metadata, relationships between software and manuscripts, repository-to-aggregator communication, and machine-actionable links (Knoth et al., 8 Jan 2025).
6. Archival, identifiers, and dissemination
A defining property of the SoFAIR Workflow is that validation is followed by registration and permanent archiving. Once a software mention is validated, the repository issues an asset registration request to Software Heritage. Software Heritage archives the source code permanently, assigns a persistent identifier, and returns it to the repository. The project paper explicitly mentions a Software Heritage persistent identifier, or SWH-ID, and presents PID plus archival as the mechanism by which software becomes findable, citable, machine-actionable, and durably linked to the manuscript context (Knoth et al., 8 Jan 2025).
The dissemination stage extends beyond the local repository. In the COAR Notify integration, the validated software mention is announced and disseminated to interested subscribers. This makes the outcome not merely an internal repository correction but a reusable event in a wider repository and service ecosystem (Cancellieri et al., 4 Aug 2025).
This architecture reflects a specific interpretation of FAIR for software. Findability is supported by machine extraction, indexing, and stable identifiers. Accessibility is supported by archival and explicit repository links, while remaining compatible with repository governance. Interoperability is achieved through CodeMeta, COAR Notify, OAI-PMH, and related protocols. Reusability is strengthened by validated links between paper and software, richer metadata, and preservation of the software asset in a dedicated archive (Knoth et al., 8 Jan 2025).
7. Broader significance, boundaries, and limitations
The SoFAIR Workflow belongs to a larger body of work that treats workflows as first-class scholarly digital objects. In that literature, a workflow is the formal specification of the data flow and execution control between executable components, and the expected datasets and parameter files, while workflow runs, components, versions, and provenance are all treated as FAIR-relevant entities. SoFAIR specializes that general perspective by centering a particular relation that had previously remained obscure: the software mention embedded in a manuscript (Wilkinson et al., 2024).
Its significance lies in turning that relation into a managed lifecycle. The workflow does not merely improve software citation style; it reconstructs software as a repository object that can be discovered, validated, archived, and disseminated across interoperable services. This suggests that SoFAIR is best understood as a repository-mediated FAIRification workflow for software assets rather than only as an extraction pipeline.
The literature is also explicit about its limits. Software-mention extraction is not perfect, which is why human validation remains mandatory. The workflow depends on repository authorization and cooperation; author notification may fail or require fallback channels; integration details may vary by repository implementation; and the papers focus on the workflow and protocol pattern rather than fully specifying all implementation internals of each repository. The 2025 COAR Notify paper also presents the system as an evolving implementation, referring to the first full workflow and to use of project partners’ infrastructure, including HAL, its existing COAR-Notify Inbox, and Software Heritage as the announcement and archiving target (Cancellieri et al., 4 Aug 2025).
A broader caution from FAIR-workflow studies is that many workflows are findable while still lacking accessibility, interoperability, or reusability in practice. From that perspective, the SoFAIR Workflow can be read as an attempt to prevent software assets from remaining merely findable mentions by embedding them in validation, provenance, identifier, and archival infrastructures that are actionable across systems (Wilkinson et al., 2022).