In wbui2025, we’re currently saving the constraint violations of each snak in a Map that stores constraint violations of each snak hash. This means we’re assuming that the same snak will always have the same violations. However, this is not true: constraint checks are highly contextual, and the same snak can have very different constraint check results based on where it occurs (on which entity; as a main snak, qualifier, or reference) and which other snaks are “next” to it (other statements on the same entity, qualifiers on the same statement, or snaks in the same reference).

In the following example, the snak “property with single value constraint – value A” is fine in the first reference, but problematic in the second reference:

We need to fix the data structure, and the way in which WikibaseQualityConstraints sends the indicator contents to Wikibase, so that each snak is identified completely uniquely. (Historical note: the wbcheckconstraints response originally didn’t include enough information to completely identify each snak either, which is why we ended up overhauling the response structure as part of rolling out constraint checks on qualifiers and references: see T174544: Document, announce, and use new wbcheckconstraints API format on Wikidata.)

Acceptance criteria for the spike (timebox 8 h):

• We have a general idea of how to implement this, including the necessary changes in (probably) both Wikibase and WikibaseQualityConstraints
• If the implementation is straightforward enough, it may happen directly in this spike, otherwise one or more follow-up tasks with details have been created