Skip to content

Core Concepts

Before writing filters or validations, you need to understand how DAQS sees Revit data.

Most mistakes in DAQS rules do not come from JSONata syntax errors. They come from incorrect assumptions about where data lives in the Revit model. This chapter fixes that.

What you will learn

By the end of this chapter, you will be able to:

  • Describe the Revit object hierarchy (Family → FamilySymbol → FamilyInstance)
  • Explain where parameters are stored and why they are not always where you expect
  • Understand how DAQS represents Revit data as flat JSON
  • Distinguish between an object's identity and its values
  • Explain why filters and validations serve different purposes and must never be mixed
  • Understand why many rules require two filter steps
  • Choose between category.name, category.label, and category.type for filtering
  • Recognise which categories cause false positives and how to exclude them

How this chapter is structured

Revit Object Hierarchy

The fundamental building blocks of every Revit model: Family, FamilySymbol, and FamilyInstance. Understanding this hierarchy explains why rules are often multi-step.

Where Data Lives

Not all data is stored where users expect. Category, Assembly Code, and type parameters live on the FamilySymbol — not the instance. This section explains why instance filters often miss data.

The DAQS Data Model

DAQS does not mirror the Revit UI. It exports a flat, relational JSON structure where objects refer to each other by id. This makes rules safer and more predictable.

Identity vs Value

The difference between what an object is (its type, category, name) and what it has (its parameter values). Filters work on identity. Validations work on values.

Filtering vs Validation

Filters and validations serve different purposes and must never be mixed. A filter that hides bad data is worse than no filter at all.

Two-Step Filtering

Why many DAQS rules filter FamilySymbols first, then FamilyInstances. This is not a workaround — it is a direct result of how Revit stores data.

Defensive Rules

Real-world models are messy. This section introduces principles for writing rules that do not break when data is missing or bindings are incorrect.

category.name vs category.label

The category field contains both a display name and a stable internal identifier. Only the internal label (OST_Doors) is safe to use in filter conditions — name is localised and changes between Revit language installations.

category.type

Revit classifies every category as Model, Annotation, Internal, or Invalid. Most rules should restrict to category.type = "Model" to avoid including view-only and internal content.

Detail Items and False Positives

Detail Items (OST_DetailComponents) have category.type = "Model" but carry no model parameters. Including them in rules causes false positives. This section explains how and why to exclude them.

Data Structure Reference

A compact reference for the JSON structure that DAQS exports. Use this when writing or debugging filters.

Prerequisites

Complete Getting Started first. You should already understand the basic structure of a DAQS rule.

Where to go next

Once these concepts are clear, continue with:

👉 Filters