Difference skipped vs success between CLI and rule editor? - ref CORE-000711 / published rule

[mhungria]

I am finding a difference on the execution of a rule between the CLI (linux) and rule editor for a date comparison. Please refer to CORE-000711. Note I posted a Q for rule CORE-000711 in the corresponding Jira ticket (https://jira.cdisc.org/browse/CORERULES-9311). However, that Q is not relevant here.

Source file tested:
unit-test-coreid-CG0555-positive.xlsx - it is the same file tested with the rule editor included in the zip file below)

Difference in rule execution
In the CLI, engine v0.14.2, executing on linux, I get the rule as skipped.

Note the rule logic is for a date comparison.

CLI command, same result with or without define.xml:
python3 core.py validate -s SDTMIG -v 3.4 -dv 2.1 -dxp .../tempv/data/define.xml -vx y -dp .../tempv/data/unittestcoreidCG0555positive.xlsx --filetype json -o .../tempv/data/val_reports/bash_core_val_None_admintempval_2026-02-09 --output-format JSON --output-format XLSX -l info -p verbose_output

Please note that the CLI still processed the .xlsx file even when I had indicated --filetype json (I'll report that separately as soon as I have a chance).

Execution on the rule editor:
The rule editor indicates success.

Rule (22).zip

[eljanssens]

According to further investigation, the reason this rule is skipping is because the standards command in in caps SDTMIG iso sdtmig. When sdtmig is used, the correct standard and thus class is recognized. When SDTMIG, it goes to the logic of assigning class based on tpoic variable. But for special purpose, there is no topic variable defined. So no class is recognized for this rule when typing SDTMIG iso sdtmig. @SFJohnson24 will take this into account in the engine to work case insensitive.

[mhungria]

I added a recommendation to #1607.

I tested with a variation of CORE-000711, adjusting scope as indicated below and it appears to work fine reporting SUCCESS. What is the difference in the engine when processing the two cases? What is the conceptual difference as DM is a standard dataset that can be retrieved directly from the IG (and the model)?

Scope:
Classes:
Include:
- ALL
#- SPECIAL PURPOSE
Domains:
Include:
- DM
Sensitivity: Record

[eljanssens]

@mhungria the difference is that when you type 'sdtmig' in the CLI, the correct standard is recognized with all the domains and their corresponding classes. When you type SDTMIG, the standard is not recognized and the following logic is followed to assign domains to classes: --trt variable = interventions, --term variable = events, --testcd variable = Findings,... but for special purpose, there is no 'logic' of a common topic variable. Thus DM is not recognized as belonging to special purpose and thus this rule is skipped. @SFJohnson24 has changed the engine to also recognize a standard in caps in the command as a valid standard.

[mhungria]

@eljanssens , perhaps my Q was not clear enough. I suggest we f/u on this ticket during the meeting next Tuesday.

[eljanssens]

@mhungria : difference in processing between 'ALL' and 'SPECIAL PURPOSE' in the engine is a question for @SFJohnson24 to answer but I guess 'ALL' means that there is no logic and rule runs for everything. For Special Purpose, it checks standard and applicable domains and only runs if dataset is in that scope.

[SFJohnson24]

@mhungria @eljanssens when ALL is scoped, it doesnt check the library metadata for class. It just immediately returns that the rule is applicable which is why it was a success