Breaking changes MUST be reported and explained

A version section that contains a breaking change is not complete until it answers, explicitly and in this changelog:

• What exactly changed between the two versions — the artifact, the element, the old and the new constraint (not just "profile X was revised").
• What it means for existing data: does data that conformed to the previous version still validate against the new one? If not, which resources and elements are affected, and how does the failure show up?
• What implementers should do: the authors' recommendation for migrating existing data to the new version — transformation steps, default values, re-coding guidance — or an explicit statement that no migration path is provided and why.

What counts as breaking — treat a change as breaking if it does any of the following, even when it looks small: tightens a cardinality (0..* → 1..1), raises a binding strength (example → required), removes codes from a required value set, removes or renames an element or a slice, narrows a type, adds an invariant or a must-support obligation, or changes a canonical URL. When in doubt, report it as breaking.

Breaking for whom: state both perspectives — stored data (instances valid against the old version) and implementations (clients and servers built against it; a removed search parameter breaks implementations while every stored instance stays valid).

The version number will not warn anyone. The KDS calendar versioning scheme (YYYY.n.n) carries no major-version signal the way SemVer does — this changelog section is the only warning a reader gets.

Link the technical delta. From the second formal publication on, enable the IG Publisher's version comparison (version-comparison in sushi-config.yaml — see the Versioning page for the setup and its prerequisites); it publishes a machine-generated comparison at comparison-v<previous>/index.html. Link it from the version section, so the prose explanation and the technical diff sit side by side.

Mark such entries clearly (for example, prefix them with BREAKING:) so a reader scanning the section cannot miss them.