Filtering by Assembly Code — data-driven selection

Until now, filters were mainly based on structure:

• Object type
• Category
• Family hierarchy

This filter introduces data-driven filtering using the Assembly Code.

(
  /* AssemblyCode inclusion */
  $assemblyCodes := ["32.31", "32.32"];

  /* Filter FamilySymbols */
  $familySymbols := $[
    type = "FamilySymbol"
    and values.assemblyCode in $assemblyCodes
  ].id;

  /* Filter FamilyInstances */
  $[
    type = "FamilyInstance"
    and parent.id in $familySymbols
  ].{
    "id": id,
    "type": type,
    "name": name,
    "parent": parent.id
  }
)

---

What this filter does (plain language)

“Select all placed elements whose family type has an Assembly Code of 32.31 or 32.32.”

The rule scope is now defined by classification data, not category.

---

Step 1 — define allowed Assembly Codes

$assemblyCodes := ["32.31", "32.32"];

This list defines:

• Which Assembly Codes are in scope
• The classification boundary of the rule

Best practices:

• Treat Assembly Codes as strings
• Match the exact formatting used in Revit
• Keep this list explicit and readable

---

Step 2 — filter FamilySymbols by Assembly Code

$familySymbols := $[
  type = "FamilySymbol"
  and values.assemblyCode in $assemblyCodes
].id;

Key points:

• Assembly Code is a type property
• Therefore, filtering happens on FamilySymbol
• Missing or incorrect values are not fixed here
• They are either included or excluded based on presence

This step answers:

“Which family types belong to these Assembly Codes?”

---

Step 3 — select instances of those types

$[
  type = "FamilyInstance"
  and parent.id in $familySymbols
]

This links:

• Instance → Symbol
• Symbol → Assembly Code

The result is a clean list of placed elements with the required classification.

---

Why this pattern matters

Assembly Code–based filtering is used for:

• Scope definition per discipline
• QTO rules
• IFC mapping checks
• Downstream BIM uses

Doing this at the type level ensures:

• No duplicate instance logic
• No silent assumptions
• Correct ownership of classification data

---

Common mistakes to avoid

Filtering Assembly Code on instances

values.assemblyCode

❌ Wrong — this lives on the type.

---

Excluding missing Assembly Codes in the filter

values.assemblyCode != null

❌ This hides the problem instead of reporting it.

Missing values should be handled in validation, not filtering.

---

Treating Assembly Codes as numbers

["32.31", 32.32]

❌ Inconsistent types lead to unpredictable results.

Always use strings.

---

Important limitation

This filter only selects elements that already have one of the listed Assembly Codes.

It does not:

• Detect missing Assembly Codes
• Detect incorrect Assembly Codes outside the list

That is the job of the validation step, which comes next.

---

Key takeaway

Use Assembly Codes to define scope, not to enforce correctness inside the filter.

Filters select. Validations judge.

---