Improve FAIR ST standards score

[jbreue16]

This meta issue tracks the FAIR ST principles score of cadet-core, as per Towards a quality indicator for research data publications and research software publications – a vision from the Helmholtz Association

F — Findable (4 items)

1. Open Publication Repository

FAIR-ST Principles for Research Software

---

F — Findable (4 items)

1. Open Publication Repository

• (0) No information available on where to find the software
• (1) Software is contained in an online repository
• (2) Repository includes a description (e.g. README)
• (3) Structured metadata (e.g. DataCite) is provided
• (4) Repository is listed in an overarching meta-repository (e.g. RSD) , fullfilled by Helmholtz Research Software Directory
• (5) Meta-repository performs quality checks (e.g. re3data) , fulfilled as per Helmholtz Research Software Directory

2. Versioning

• (0) No versioning applied
• (1) Some form of versioning exists
• (2) Structured versioning (e.g. semantic versioning) is used
• (3) Versioning scheme is documented
• (4) Release cycles are documented

3. Persistent Identifier (PID)

• (0) No PID provided
• (1) Handle/URL provided
• (2) Handle/URL includes metadata scheme
• (3) Persistent identifier (PID) provided, fulfilled as per Zenodo
• (4) PID allows automated metadata harvesting, fulfilled as per Zenodo, GitHub repo
• (5) PID follows an established community standard, fulfilled as per Zenodo

4. Rich Metadata

• (0) No metadata
• (1) Some metadata provided
• (2) Fully compliant with a metadata scheme, fullfilled as per GitHub std info_ Authors.md, README.md, citation.bib datacite, CRAN
• (3) Metadata curation reflects updates (fulfilled e.g. release checklist)
• (4) Metadata can be automatically harvested (what is even that, isnt this always fulfilled)

---

A — Accessible (3 items)

1. Access Conditions (Organizational)

• (0) Not specified
• (1) Contact provided for access inquiries
• (2) License describing usage rights
• (3) Open license (e.g. OSI-approved)

2. Access Options (Process)

• (0) Only one or no access option
• (1) Source code or executable provided
• (2) Documentation for installation/use included
• (3) Test cases provided
• (4) Checks ensure correct operation

3. Technical Accessibility (Run/Start)

• (0) No information
• (1) Installation instructions provided
• (2) Installation scripts available
• (3) (Semi-)automated installation (e.g. Makefile)
• (4) Compatible with package managers/build tools
• (5) Complete executable package (e.g. docker container, pip/conda-forge)

---

I — Interoperable (2 items)

1. Input/Output Formats

• (0) Not specified
• (1) Described formats
• (2) Uses standard formats (h5 files)
• (3) Additional options for varying input/output formats provided
• (4) Uses community standards

2. Adaptability / Flexibility of Use

• (0) No information
• (1) Works with one fixed input
• (2) Configurable parameters
• (3) Execution logging available
• (4) Documented APIs available

---

R — Reusable (1 item)

Support

• some kind of human contact options (email)
• static docs, readme, faq etc
• sme minimal support, issue tracker and a research group as contact is provided
• there exists a publicly available exchange platform

Reusability Conditions

• (0) Not clear
• (1) Custom reuse license
• (2) FOSS/OSI license (dependencies manually checked)
• (3) Appropriate licensing per file type (e.g. REUSE spec), we have that only in cpp and hpp files
  • cc-by-sa for documentation, beispiele nicht-kommerziell
• (5) Fully automated dependency/license control Establish fully automated dependency/license control #639

---

S — Scientific Basis (3 items)

1. Community Standards what are our standards even in chrom?

• (0) No information
• (1) References to known standards
• (2) Follows community standards
• (3) Complies with scientific standards
• (4) Plans for evolving standards
• (5) Feedback loop for continuous standard adoption

2. Team Expertise

• (0) No information
• (1) Expertise in one domain
• (2) Access to multiple domains
• (3) Access to expertise across all relevant domains: numerical mathematics, process engineering, chromatography modeling
• (4) Fixed Established interdisciplinary team fixed nicht wirklich, da befristete anstellungen standard

3. Scientific Embedding

• (0) No information
• (1) One documented use case
• (2) Broader scientific context with examples
• (3) At least loosely connected to scientific initiative: DFG, NIIMBL, Inno4Vac
• (4) Part of larger scientific initiative https://github.com/cadet/CADET-project-Management/issues/63

---

T — Technical Basis (6 items)

1. Project Management

• (0) No information
• (1) Some version control
• (2) Version control system used
• (3) Platform with ticket system (e.g. GitHub/GitLab)
• (4) Transparent processes (reviews, tickets, merges)
• (5) Structured release process with testing and changelogs

2. Repository Structure

• (0) No information
• (1) Files present but unstructured
• (2) Some structure, inconsistent organization
• (3) Defined structure for the repo + onboarding + contribution guide
• (4) Standardized template for the repo structure + some kind of identification of deviations

3. Code Structure

• (1) No coding standards
• (2) Recommendations only
• (3) Enforced coding standards including meaningful naming of functions, variables Add auto formatting and pre-commit #404
• (4) Style checks during review Add auto formatting and pre-commit #404
• (5) Automated enforcement (e.g. manual review, pipelines, auto-formatters) Add auto formatting and pre-commit #404

4. Reproducibility (Code)

• (0) No tests / duplicated code
• (1) Modular structure
• (2) clear documented system requirements (cmake minmax version)
• (3) Dependency pinning + testing via package manager
• (4) Measured test coverage
• (5) Automated testing + on different systems + coverage requirements + provisioning of containerized packages is done Add coverage to CI #638

5. Code Change Process

• (0) No information
• (1) Internal 4-eye principle
• (2) Transparent PR/merge process
• (3) PR approval with 4-eye principle
• (4) Restricted integration permissions via specifically named persons

6. Security

• (0) No security measures, nothing relevant?
• (1) Occasional updates/dependency checks: The project is actively maintained, deployment, build pipelines
• (3) Systematic dependency assessment: structured builds (CMake, CI, packaging), but no dedicated vulnerability scanning tools or dependency audit workflow schreiben dass wir das nicht machen
• (4) dependabot aber in c++ welt schwierig, vllt für cmake aufsetzbar
• (5) there are regular and updated security monitoring wir sind kein web service mit user daten..