DDF CORE: Unexpected behavior for missing InstanceType

[eljanssens]

This issue has been noted by Mike Rippin from Capgemini (see attached email)

DDF CORE_Unhandled CORE Errors - UPDATE.pdf

Any entity defined that is missing the "InstanceType" attribute causes CORE to generate and unhandled exception.
It will be much better if the CORE engine catches such issues and reports them as part of the Conformance Report, and preferably identifies the element hierarchy that led to the error so a user knows where to find it in the source file.

Summary of the issue:

• The check is performed correctly in the CORE engine.
• However, the way that it is picked up and reported is depending on a certain attribute in the data (the instanceType). That helps in identifying where the problem is located in the USDM.

If that attribute instanceType is missing then nothing is reported now, while it is a problem that it is missing and it is intended to be reported.

@OGarcia11: can this be assigned to @gerrycampion or @SFJohnson24 ?

[pendingintent]

@gerrycampion , @SFJohnson24 are you able to take this issue?

[SFJohnson24]

@pendingintent @eljanssens I was outside the DDF project scope so I am not the most familiar with USDM and how it operates within engine. I dont want to put more on @gerrycampion plate but I believe he would be much better suited than me to address this issue expeditiously. I am happy to take it but I will need a bit of time getting up to speed on USDM

[pendingintent]

Latest Suggestion:

It looks like the problem is that – although the schema validation does identify the problems with the referenceSubstance – the error messages are not associated with a “dataset”/entity (because instanceType is missing) so they’re not reported. I think the schema checking logic should be updated to assign the “dataset”/entity from the class/entity derived from the schema if it’s not available from the data.

[pendingintent]

Link to the "dirty" file: https://github.com/cdisc-org/cdisc-jsonata-rules/blob/main/testdata/CDISC_Pilot_Study_v4_Dirty.json
Link to the "fixed" file: https://github.com/cdisc-org/cdisc-jsonata-rules/blob/main/testdata/CDISC_Pilot_Study_v4_FIXED.json

[pendingintent]

./core validate -s USDM -v 4.0 -d ../core_files/dirty

CORE-Report-2026-01-26T09-15-51.xlsx

[pendingintent]

./core validate -s USDM -v 4.0 -d ../core_files/fixed

CORE-Report-2026-01-26T09-17-15.xlsx

[pendingintent]

I am running the executable on Mac since I do not have access to a Windows instance.

I am not able to reproduce the exception when executing CORE on the DIRTY file when it is hte only file in the directory but when I copy both the dirty file and the fixed file into the same directory, an exception is thrown:

dmoreland@Mac core % ./core validate -s USDM -v 4.0 -d ../core_files/dirty
[------------------------------------] 0%
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "multiprocessing/pool.py", line 125, in worker
File "scripts/run_validation.py", line 98, in validate_single_rule
File "cdisc_rules_engine/rules_engine.py", line 148, in validate_single_rule
AttributeError: 'NoneType' object has no attribute 'get'
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "core.py", line 875, in
File "click/core.py", line 1157, in call
File "click/core.py", line 1078, in main
File "click/core.py", line 1688, in invoke
File "click/core.py", line 1434, in invoke
File "click/core.py", line 783, in invoke
File "click/decorators.py", line 33, in new_func
File "core.py", line 466, in validate
File "scripts/run_validation.py", line 192, in run_validation
File "cdisc_rules_engine/utilities/progress_displayers.py", line 62, in _bar_progress_displayer
File "multiprocessing/pool.py", line 873, in next
AttributeError: 'NoneType' object has no attribute 'get'
[PYI-24478:ERROR] Failed to execute script 'core' due to unhandled exception!

[pendingintent]

multiprocessing/pool.py:121-171

core.py:875
cli.add_command(list_rule_sets)

cdisc_rules_engine/utilities/progress_displayers.py:47-65

[pendingintent]

The error is occurring at rules_engine.py:148 where it's trying to call .get() on rule["domains"], but rule["domains"] is None

code checks if "domains" exists as a key in the rule dictionary, but it doesn't verify that rule["domains"] isn't None. When the rule has "domains": None, the check passes but then line 148 fails trying to call .get() on None

The code is checking if domains key exists but does not check if not None.

Edit to make safe:
./cdisc_rules_engine/rules_engine.py:147-150
if dataset_metadata.unsplit_name in results and "domains" in rule:
include_split = rule.get("domains", {}).get("include_split_datasets", False)
if not include_split:
continue # handling split datasets

[ASL-rmarshall]

@pendingintent In your comment above, I noticed that you're using the -d argument to run the CLI. For validation of single JSON files that contains multiple "datasets", we usually use the -dp argument and point directly to the file (not the directory/folder):

./core validate -s USDM -v 4.0 -dp ../core_files/dirty/CDISC_Pilot_Study_v4_Dirty.json

[pendingintent]

I have used @ASL-rmarshall suggestion and tested only a single file:
dmoreland@Mac core % ./core validate -s USDM -v 4.0 -dp ../core_files/1546/dirty/CDISC_Pilot_Study_v4_Dirty.json
[████████████████████████████████████] 100%
[DEBUG 2026-01-26 10:33:38,137 - excel_report.py:90] - Report written to: CORE-Report-2026-01-26T10-33-29.xlsx
Output: CORE-Report-2026-01-26T10-33-29

dmoreland@Mac core % ./core validate -s USDM -v 4.0 -dp ../core_files/1546/dirty/CDISC_Pilot_Study_v4_FIXED.json
[████████████████████████████████████] 100%
[DEBUG 2026-01-26 10:34:45,101 - excel_report.py:90] - Report written to: CORE-Report-2026-01-26T10-34-36.xlsx
Output: CORE-Report-2026-01-26T10-34-36

The file(s) does not report any issues when tested alone. If using the -d flag and testing more than one JSON file in the directory, the exception is generated. If best practice is to use -dp, we ned to make this clear.

[pendingintent]

Some additional feedback:

I think there are two aspects to this issue:

1. Lack of an instanceType value may cause CORE to throw an unhandled error. I agree that the code should be updated so that the exception is not thrown.

2. The lack of instanceType prevents the correct reporting of schema validation issues (if these issues had been reported correctly, Mike would have been able to identify and correct the errors that resulted in the exception being thrown). The code that creates a dataset of schema validation issues (cdisc_rules_engine\dataset_builders\json_schema_check_dataset_builder.py) needs to be updated to assign the “dataset” value to be the schema class name when instanceType is not available in the data (currently at L113).