To support verifiable, reproducible, and auditable compliance claims in complyr, we propose defining a formal framework that enumerates the degrees of freedom (DoF) necessary to uniquely and deterministically specify a compliance scenario.
This conceptual framework will underpin provenance tracking, reproducibility guarantees, and long-term traceability of claims across packages, versions, and test infrastructures.
Objectives
- Define a canonical specification of a compliance scenario as a composable, versioned tuple of inputs and conditions.
- Support deterministic reproduction of any compliance evaluation, including historic and cross-version scenarios.
- Provide a theoretical basis for compliance caching, reporting, comparison, and ledgering.
Conceptual Elements
A reproducible compliance scenario in complyr should minimally be defined by the following core components:
-
Subject under test: Package name and version, target function or object, declared compliance claim(s) (e.g., via @comply),
-
Auditor definition: auditor package name and version and specific test function(s) executed
-
Execution environment: R version, platform and architecture, system dependencies, locales, and test helper versions (if applicable)
-
Evaluation context: timestamp of execution, CI/CD metadata or local session UUID, Git commit SHA (for method and/or auditor)
Towards a Compliance Signature
We propose the introduction of a compliance signature, defined as a hashable data structure that captures all relevant DoF for a single test evaluation. This structure would support:
- Reproducibility: Ensuring that the same inputs yield identical results
- Comparability: Supporting diff-based regression and progress analysis
- Provenance tracking: Enabling transparent audit trails over time
Example row (conceptual):
| method_pkg |
version |
auditor_pkg |
version |
test_fn |
R_version |
platform |
result |
timestamp |
| mypkg |
1.2.0 |
auditorABC |
0.3.1 |
test_conformX |
4.3.2 |
x86_64 |
pass |
2025-05-24T14:03:00Z |
To support verifiable, reproducible, and auditable compliance claims in complyr, we propose defining a formal framework that enumerates the degrees of freedom (DoF) necessary to uniquely and deterministically specify a compliance scenario.
This conceptual framework will underpin provenance tracking, reproducibility guarantees, and long-term traceability of claims across packages, versions, and test infrastructures.
Objectives
Conceptual Elements
A reproducible compliance scenario in complyr should minimally be defined by the following core components:
Subject under test: Package name and version, target function or object, declared compliance claim(s) (e.g., via @comply),
Auditor definition: auditor package name and version and specific test function(s) executed
Execution environment: R version, platform and architecture, system dependencies, locales, and test helper versions (if applicable)
Evaluation context: timestamp of execution, CI/CD metadata or local session UUID, Git commit SHA (for method and/or auditor)
Towards a Compliance Signature
We propose the introduction of a compliance signature, defined as a hashable data structure that captures all relevant DoF for a single test evaluation. This structure would support:
Example row (conceptual):