Mental Model

Before writing a single line of JSONata, you need one picture in your head.

This picture will explain why rules are structured the way they are, why filters and validations are separate, and why some data seems hard to reach.

The big picture

Revit model
    ↓
DAQS Assist extracts data
    ↓
Flat JSON array (all elements, types, parameters)
    ↓
JSONata filter → selects and shapes relevant objects
    ↓
Validator → checks a specific field in the output
    ↓
Failures → error message shown in Revit plugin

Every DAQS rule follows this exact path.

The JSON is flat, not a tree

In Revit, the UI shows a hierarchy: a Family contains Types, and each Type is placed as Instances.

DAQS does not export a nested tree. It exports a flat array of objects.

Each object has the same shape:

{
  "id": 616521,
  "type": "FamilyInstance",
  "name": "1018x2387 - kader 40mm HPL - rechtsdraaiend 2",
  "parent": {
    "id": 617464,
    "type": "FamilySymbol"
  },
  "values": {
    "mark": "61",
    "levelId": 311,
    ...
  }
}

The relationship to its parent type (FamilySymbol) is expressed by parent.id — not by nesting.

This means:

A FamilyInstance does not contain its type's data directly
To reach type-level data (like assemblyCode), you must look up the FamilySymbol separately
That is why many rules require two filter steps

Two things a rule always does

Every DAQS rule has exactly two parts:

1. The filter — select and shape

The filter answers: which objects does this rule apply to, and what data do I need?

$[type = "FamilyInstance"].{
  "id": id,
  "type": type,
  "name": name,
  "mark": values.mark
}

This selects all FamilyInstances and extracts mark from their values. The output is a shaped object — a data contract for the validator.

2. The validator — judge

The validator answers: is this specific value correct?

valueToValidate: mark
validator: propertyShouldExist = true

The validator never touches the full model. It only sees what the filter returned.

The filter is a contract

The filter output defines what the validator can check.

If mark is not in the filter output, the validator cannot check it. If assemblyCode is not in the filter output, it cannot be validated.

This is why the filter must be designed with the validation in mind.

What happens when a rule fails

When an element fails validation, DAQS constructs an error message using the filter output.

Any field you included in the filter output can be used in the message:

Element {{name}} (id: {{id}}) is missing a Mark value.

The user sees this in the Revit plugin and knows exactly which element to fix.

This is why the filter must always include id, type, and name — without them, the error cannot identify the failing element.

The one rule to remember

Filters select. Validators judge. The output shape connects them.

If this is clear, every other concept in this course will feel logical.