Constraint without parent element (wrapper) causes incidents despite valid logic

🐛 Bug Report

Summary

A constraint using the variant “Within each , every must contain either A or B” works as expected. However, if the same logic is applied without a wrapper (i.e., without parent element), it leads to incidents — even though the constraint should logically work the same way.

Steps to Reproduce

Define a constraint using the variant: Within each , every Administrative Metadata must contain either a Link Resource or a Record Info Link. → This works as expected (see second constraint in screenshot).

Define the same constraint without a wrapper, e.g.: Every Administrative Metadata must contain either a Link Resource or a Record Info Link. → This version does not work and causes incidents (see first constraint in screenshot).

Execute the constraint.

Observe unexpected incidents for the second case.

What is the current bug behavior?

Constraints without a wrapper element — even when logically correct — do not work and cause incidents.

What is the expected correct behavior?

Constraints without a wrapper should behave the same as those with a wrapper if the logic and element relationships are otherwise valid. The absence of a parent element should not break functionality or cause false-positive incidents.

Relevant Logs, Screenshots, or Gifs

constrainify_report_35ea60eb-f297-4336-9303-1b4ac97aa590.csv

Possible Fix or Suggested Solution

Align validation behavior between with/without wrapper variants.

Additional Context

This issue affects users trying to apply constraints globally across elements like administrativeMetadata, which may occur in multiple contexts. The incident is not caused by data or logic error, but by the structure of the constrait.