Skip to content

nav: title: Minimal Valid Filter order: 1

Minimal valid filters — selecting the right data

A filter defines which objects a DAQS rule applies to and- what data is passed to the validation step. This page explains the minimal valid filter - and the mandatory fields every filter must return. It builds directly on the filter concepts introduced in the core concepts section.

Why this matters

DAQS validations operate only on the data returned by the filter.

If required fields are missing from the filter output:

  • results cannot be linked back to Revit elements
  • errors may not appear in DAQS Assist
  • users cannot understand or resolve issues

A filter that does not return the required fields produces an unusable rule, regardless of how correct the validation logic is.

Minimal working example

The smallest valid DAQS filter looks like this:

(
  $[type = "FamilyInstance"].{
    "id": id,
    "type": type,
    "name": name
  }
)

This filter:

  • selects objects by type
  • returns the required fields
  • produces output DAQS Assist can process and display

Every valid DAQS rule starts from this pattern.

Required fields

Every filter *must- return the following fields:

  • id
  • type
  • name

These fields form the minimum data contract between the filter, DAQS Assist, and the end user.

Why these fields are mandatory

id — object identity

The id field uniquely identifies a Revit element.

It is used to:

  • link validation results to the correct element
  • avoid duplicate or ambiguous results

Without id, DAQS cannot indicate *which element- is incorrect.

type — object classification

The type field identifies what kind of object is being validated (for example: FamilyInstance, Room, or Level).

It is used to:

  • apply the correct handling logic in DAQS Assist
  • display results consistently

Without type, DAQS cannot determine *what kind of object- it is dealing with.

name — human-readable identification

The name field provides a readable identifier for users.

It is used to:

  • make validation results understandable
  • avoid anonymous or ID-only error messages

Without name, users see technical identifiers only, which is not usable in practice.

The filter as a data contract

A filter defines a *data contract- between:

  • the DAQS rule engine
  • DAQS Assist
  • the end user

At minimum, that contract must allow DAQS Assist to answer:

  • Which element is this?
  • What kind of object is it?
  • What is it called?

That contract requires the following structure:

{
  "id": "...",
  "type": "...",
  "name": "..."
}

All additional fields are optional and rule-specific.

Expanding the filter safely

Once the required fields are present, additional data may be added only if needed for validation.

Example:

(
  $[type = "FamilyInstance"].{
    "id": id,
    "type": type,
    "name": name,
    "brandwerendEis": values."p_36ddc047-2c5f-4365-9bda-14ccea06b50f"
  }
)

Rules:

  • Never remove id, type, or name
  • Only include fields required for validation
  • Keep filter output as small as possible

Common beginner mistake

This filter looks correct, but is invalid:

$[type = "FamilyInstance"].values

Reason:

  • id is missing
  • type is missing
  • name is missing

The filter output can no longer be traced back to Revit elements, making the rule unusable.

Rule of thumb

If a validation fails, DAQS Assist must be able to answer: Which element? What is it? What is it called?

That information must come from the filter output.

Always include:

  • id
  • type
  • name