Ring constraints on binary fact types are currently held as ad-hoc internal settings rather than as a proper, first-class part of the model. This makes them fragile to persist, harder to query, and inconsistent with how other constraints are stored.

Ring constraints should become a first-class model concept: each object-fact type can carry a ring constraint, and that constraint records its type (e.g. irreflexive, asymmetric, transitive, acyclic, etc.) together with the two roles it applies to. Promoting this to dedicated storage will make ring constraints reliable to save and load, available for reporting and export, and consistent with the rest of the constraint model.

Target release: 15.x