Collection Validation
A collection of validations applies multiple checks to the same filtered elements.
"Does this element comply with rule X, Y, and Z?"
Characteristics:
- Same filter for all validations
- Multiple validators, each with its own name
- Each validation can fail independently
- Multiple error messages per element are possible
When to use a collection
Use a collection only when all validations:
- belong to the same standard clause or requirement
- target the same responsibility
- should be read together in a report
Correct grouping example
NLRS Door Type — required parameters: - Door width parameter exists - Door width has a valid data type - Door width value is within allowed range
That is one conceptual requirement expressed as three checks. A collection is correct here.
When NOT to use a collection
The most common mistake is grouping unrelated checks because "they apply to the same elements".
❌ Bad grouping:
- Naming convention + fire rating + IFC export flag
- Geometry check + parameter check + classification check
- Type-level rule mixed with instance-level rule
This produces:
- unclear ownership ("who fixes this?")
- unclear error messages ("which part is wrong?")
- collections that grow without discipline and become impossible to maintain
The rule
One validation = one contractual requirement
If you break that rule, the collection is wrong — not the elements.
Collection validation names
Each validation in a collection must have its own name that describes only its own failure:
✅ Correct: - "Door width parameter is missing" - "Door width has incorrect data type" - "Door width value is outside allowed range"
❌ Incorrect: - "Door width is incorrect" (on all three) — defeats the purpose of a collection
If a user sees only the name, they should know exactly what to fix.
Collections almost always need richer filters
Because all validations share the same filter, the filter must expose all fields needed by all validators.
If one validator needs assemblyCode and another needs fireRating, both must be in the filter output. Plan the filter after listing all validations — not before.