Skip to content

Validations Drive Filter Design

What you want to validate determines what your filter must return.

Not the other way around. Not "I already have a filter, let's validate something on it."

If the validation needs data that the filter did not extract, the rule is structurally wrong — even if it runs without errors.

The causal chain

Requirement
    ↓
Validation logic — how to check
    ↓
Required data fields
    ↓
Filter design

Design from top to bottom. Never from the bottom up.

Making this concrete

Example 1 — simple value check

Requirement: Assembly Code must be filled in.

Validation logic: check if value exists and is not empty.

Implication for filter: the filter must return assemblyCode from the correct object — which is the FamilySymbol, not the instance.

If your filter only returns id, type, name — validation is impossible. The field simply does not exist in the output.

Example 2 — value in list

Requirement: Fire rating must be one of the allowed NLRS values.

Validation logic: read the fire rating value, compare against a static list of allowed values.

Implication for filter: the filter must return the fire rating parameter with its raw value, from the correct object (instance or symbol — you must decide and be explicit).

You cannot "fix this later" in the validation step.

Example 3 — collection of validations

Requirement: Door types must have correct wall opening dimensions.

Validation logic: - Parameter exists - Correct data type - Value is within allowed range

Implication for filter: the filter must return all fields needed by all three validations. For collections, this almost always means joining instance and symbol data and extracting multiple parameters up front.

The common anti-pattern

❌ "We'll add the parameter later in the validation."

Why this fails:

  • Validation only sees what the filter returned
  • Missing fields become silent nulls
  • Silent nulls become false negatives
  • False negatives destroy trust in reports

If a value is not in the filter output, it does not exist as far as the validator is concerned.

Checklist before writing a filter

  1. What am I checking?
  2. How do I decide pass vs fail?
  3. Which exact values do I need?
  4. Where do those values live in Revit?
  5. Only now: write the filter.

If step 4 is unclear, stop. The filter will be wrong.

A filter is not reusable by default. A filter that works for one validation may be incorrect for another. Filters are meant to be copied and adapted — not reused blindly across different rules.