Skip to content

Core Concepts — how DAQS sees Revit data

Before writing advanced filters or validations, you need to understand how DAQS represents Revit data and where information actually lives.

Most mistakes in DAQS rules do not come from JSONata syntax. They come from incorrect assumptions about the Revit data model.

This chapter fixes that.

Why this chapter exists

If you skip this section, you will still be able to:

  • Copy example rules
  • Get “some” results
  • Produce output

But you will also:

  • Filter at the wrong level
  • Miss data that should be validated
  • Hide errors instead of reporting them
  • Write rules that break as soon as the model changes

The goal of this chapter is not to teach syntax.

The goal is to teach the correct mental model.

How to read this chapter

This section is conceptual, not procedural.

  • Read it top to bottom once
  • Come back to individual pages when something feels unclear
  • Use it as a reference when debugging rules that “look right but behave wrong”

You do not need to memorise everything. You do need to understand the principles.

Core concepts covered

Revit object hierarchy

Understand the fundamental Revit objects and their relationships:

  • Family
  • FamilySymbol (Type)
  • FamilyInstance
  • Parameter

This explains why rules are often multi-step.

→ revit_object_hierarchy.md

Where data lives (and where it does not)

Not all data is stored where users expect it to be.

This section explains:

  • Why category and Assembly Code live on the type
  • Why instance filters often fail
  • Why some parameters appear “missing”

→ where_data_lives.md

The DAQS data model

DAQS does not mirror the Revit UI.

This section explains:

  • Why DAQS uses a flat, relational JSON structure
  • How id and parent.id replace nesting
  • Why this makes rules safer and more scalable

→ daqs_data_model.md

Identity vs value

Learn the difference between:

  • What an object is (identity)
  • What an object has (values)

This distinction is critical for correct filtering and validation.

→ identity_vs_value.md

Filtering vs validation

Filters and validations serve different purposes and must never be mixed.

This section explains:

  • What filters are allowed to do
  • What validations must never do
  • Why hiding incorrect data is worse than reporting it

→ filtering_vs_validation.md

Why two-step filtering exists

Many DAQS rules filter:

  1. FamilySymbols
  2. FamilyInstances

This is not a workaround — it is a direct result of the Revit data model.

→ two_step_filtering.md

Defensive rule writing

Real-world models are messy.

This section introduces principles for writing rules that:

  • Do not break when data is missing
  • Do not assume correct bindings
  • Remain stable across projects

→ defensive_rules.md

When to move on

You are ready to continue when:

  • You know which object level to filter for a given rule
  • You can explain why a rule is split into multiple steps
  • You understand why some data must be validated, not filtered

Once these concepts are clear, the following chapters will feel logical instead of magical.

Next

Continue with:

→ Filtering Patterns
→ 03_filtering_patterns/index.md