Skip to content

Reading domain data from filters

Once a filter returns the mandatory fields (id, type, name), it can be extended with additional data needed for validation.

This page explains how to read *domain-specific data- from the DAQS Assist JSON and include it safely in the filter output.

Why this matters

Validations can only evaluate data that is present in the filter output.

If a value is not returned by the filter:

  • it cannot be validated
  • it cannot be reported
  • it is effectively invisible to DAQS

Filters prepare data.
Validations evaluate data.

Understanding where domain data lives — and how to expose it — is essential.

Minimal working example

Starting from the minimal valid filter, we add one additional field: assemblyCode.

(
  $[type = "FamilySymbol"].{
    "id": id,
    "type": type,
    "name": name,
    "assemblyCode": values.assemblyCode
  }
)

This filter now returns all required fields *plus- one domain-specific value.

What changed compared to the minimal filter

Filtering a different object type

$[type = "FamilySymbol"]

This selects family types, not placed instances.

This is intentional: Assembly Code is defined at the type level, not the instance level.

Reading data from values

"assemblyCode": values.assemblyCode

Most Revit properties exposed by DAQS Assist live inside the values object.

This line:

  • reads the Assembly Code from the source data
  • copies it into the filter output
  • makes it available for validation

No transformation is applied.

Why we add domain data to the filter

Filters do not validate data. They only prepare data.

By adding:

"assemblyCode": values.assemblyCode

You are explicitly stating:

“This rule needs Assembly Code for validation.”

If a value is not present in the filter output, it cannot be validated later.

What the filter output looks like

For each FamilySymbol, the filter returns:

{
  "id": 617464,
  "type": "FamilySymbol",
  "name": "1018x2387 - kader 40mm HPL - rechtsdraaiend 2",
  "assemblyCode": "32.31"
}

This dataset is now:

  • identifiable (id)
  • understandable (name)
  • complete for validation (assemblyCode)

Missing values are not filter errors

Not every FamilySymbol has an Assembly Code.

If:

values.assemblyCode

returns null, this is:

  • valid JSON
  • valid JSONata
  • often a validation case, not a filter problem

Do *not- fix missing values in the filter.

Why we do not validate inside the filter

This filter is incorrect:

$[type = "FamilySymbol" and values.assemblyCode != null]

Reason:

  • elements with missing data are silently excluded
  • DAQS will never report the issue
  • users receive a false sense of correctness

Filters select data. Validations judge data.

Keep those responsibilities separate.

Rule of thumb

If you need a value for validation, add it to the filter output exactly as it exists.

Do not:

  • clean it
  • transform it
  • exclude missing values

That belongs in the validation step.