## 4 Discussion
### Strengths and Limitations  
According to CRAN, more than 18,000 packages are available [82], with many more being published every week. We have tried to cover all potentially relevant packages by combining different search strategies. However, we may have overlooked some, particularly as R packages are hard to review systematically on CRAN due to limited search functionalities. Our search hits, using the package pkgsearch, were based on the title and (short) description of the packages as provided by the package authors. Therefore, we additionally curated a list of relevant packages from the literature and other sources as outlined in the methods. Excluding packages for DQA in specific fields might potentially have led to excluding well-developed packages with additional functionalities. We classified packages into three broad groups according to their main features and description. This classification is straightforward for most packages. The packages that were developed following a DQ concept (i.e., MOQA, DQAstats, and dataquieR) are unequivocally in the category of packages focused on DQA (category 1 in Section 3.4). Similarly, packages based on assertion checks (e.g., testdat and assertr) can be trivially classified as rule-based (category 3 in Section 3.4). However, other packages that provide diverse features could fit multiple categories. A prominent example is pointblank because it is built as a rule-based package, but many of its functions and output are specifically designed for DQA. This also applies to validate, yet the packages were classified differently because of the DQ-specific reporting features provided by pointblank. The packages dlookr and DescTools incorporate various checks for DQ as well, but their scope is broader and extends to data exploration and statistical analyses (category 2 in Section 3.4). We decided the final categorization of packages in these uncertain cases based on their description and documentation. Nevertheless, we emphasize that this classification should be considered broadly and flexible. There was some ambiguity regarding the classification of package functionalities concerning the reference DQ framework. We resolved disagreements through extensive consensus processes. However, certain aspects may remain debatable. This issue becomes particularly evident with packages that perform rule-based checking, such as assertr or validate. With additional base R input, experienced users may effectively use these packages to address all framework indicators. However, this disagrees with the idea of having packages that facilitate DQA. Therefore, our classification focused on functionalities provided within packages, allowing only additional basic input, such as regular expressions, while excluding base R. Another example is in the \"disagreement of repeated measures\" domain. We expected the package to recognize and handle repeated measurements to assign a given functionality to this domain. However, any scatter plot or correlation trivially provides information about repeated measurements, and we could also have decided to qualify such functionalities as descriptors. Nevertheless, our rationale was to focus on features directly implemented by the package without relying on user customization to avoid these nuances. Furthermore, functionalities are implemented differently across packages, but their binary mapping against the reference DQ framework did not capture such heterogeneity. For example, regarding the indicator \"inadmissible standardized vocabulary\", DescTools handles a specific check for ISO 3166-1 country codes, while validate can import and contrast any SDMX code list from the web. We consider both implementations as standardized vocabulary because they are based on explicit ontologies, but their difference in breadth is evident. Another example is the varying quality of the graphical output across packages. Similarly, some packages provide very specific implementations.