Severity

Every field change in a ModifiedChange has a severity of breaking, non-breaking, or cosmetic.

Breaking

Changes that break compatibility with code that consumes the DMN model programmatically (e.g., a rule engine that calls decisions by name, or code that reads outputs by name).

Examples:

• decision.@name — callers reference decisions by name
• outputClause.@name — output columns are accessed by name
• inputData.@name — data input variables are referenced by name
• itemDefinition.@typeRef / @isCollection — type contract changes
• functionDefinition.@kind — changes the expression executor (FEEL → Java → PMML)
• iterator.@iteratorVariable — renaming a loop variable breaks FEEL references

Non-breaking

Changes that affect behavior but do not break the structural contract. Consumers may need to re-test, but the interface is unchanged.

Examples:

• inputEntry.text — rule condition changed
• outputEntry.text — rule output changed
• decisionTable.@hitPolicy — evaluation semantics changed
• itemDefinition.allowedValues.text — validation constraint tightened/loosened
• informationRequirement — data flow changed

Cosmetic

Changes that are purely visual and do not affect execution or the programmatic interface.

Examples:

• *.@label — display label (distinct from @name)
• *.@description — documentation text
• textAnnotation.text — diagram annotation
• annotationEntry.text — rule annotation column
• group.@name — visual grouping label
• decisionTable.@preferredOrientation — diagram rendering hint