Decide future contract for legacy applicability matrix
During the #906 (closed) coverage-assumption review, B084 accepted the current helper-level behavior of util_app_con_contradictions_redcap(): it combines a fixed concept applicability with the supplied datatype applicability vector and returns the current applicability scores.
This is only a characterization of legacy behavior. The applicability matrix originates from the dataquieR 1 era and is only partly aligned with the current dq_report2()/pipeline applicability logic.
Existing historical issues such as #46 (closed), #79 (closed), #91 (closed), and #204 (closed) are closed or cover narrower historical defects. We should keep a current follow-up that explicitly decides what should happen with this legacy surface.
Questions to settle:
- Is
pro_applicability_matrix()still part of the supported user-facing API, or should it be deprecated/soft-deprecated? - If it remains supported, should its scoring be aligned with current indicator-level applicability and
dq_report2()behavior? - Should helper functions such as
util_app_con_contradictions_redcap()keep their current score semantics or be replaced by condition/applicability classes used elsewhere? - How should old applicability levels be documented when datatype applicability and concept applicability are mixed?
Acceptance checklist:
- Decide supported/deprecated status of
pro_applicability_matrix(). - Document the intended relationship to
dq_report2()applicability. - Decide whether helper-level scores such as
"1"/"3"remain meaningful. - Update tests to distinguish legacy characterization from intended future contract.
- Update website/developer documentation accordingly.