Skip to content

Data Structure

# DAQS Assist JSON — data structure and mental model

DAQS rules do not query Revit directly.  
They query the **JSON file generated by DAQS Assist**.

This page explains how that JSON is structured, how relationships are represented, and how to reason about the data before writing or modifying rules.

---

## Why this matters

Every DAQS rule operates on the same input: a single JSON dataset exported by DAQS Assist.

If you do not understand where information lives in this JSON, your rule will:

- return no results
- return incorrect results
- or fail silently

Understanding the data structure turns rule writing into a **data filtering exercise**, instead of trial-and-error.

---

## Mental model

Think of the DAQS Assist JSON as:

> **A flat list of Revit-related objects, each with a `type`, an `id`, a `values` object, and optionally a `parent`.**

There is **no hierarchy** like in Revit itself.

All relationships are expressed explicitly through:
- object IDs
- `parent` references
- references stored inside `values`

Most DAQS rules follow this pattern:

1. Filter objects by `type`
2. Narrow down based on data inside `values`
3. Optionally resolve relationships (symbol, level, parameter, material)

---

## Global structure

The DAQS Assist output is a **single JSON array**:

```json
[
  { "id": 544322, "type": "CadFile", ... },
  { "id": 617348, "type": "Family", ... },
  { "id": 617464, "type": "FamilySymbol", ... },
  { "id": 616521, "type": "FamilyInstance", ... }
]

Key characteristics:

  • There is no root object
  • Every element is a peer in the same array
  • Every rule starts by filtering this array

This is why almost all JSONata queries begin with:

$[type = "..."]

Core object fields

Every object in the DAQS Assist JSON follows the same basic structure.

type — object classification

The type field identifies what kind of object this is.

Example:

{
  "id": 616521,
  "type": "FamilyInstance",
  "values": { ... }
}

Typical rule entry point:

$[type = "FamilyInstance"]

You should always start a rule with an explicit type filter.

id — object identity

Each object has a unique numeric id.

IDs are used to:

  • link instances to symbols
  • link elements to levels
  • link parameters to their definitions
  • express parent–child relationships

Example:

{
  "id": 616521,
  "type": "FamilyInstance",
  "parent": {
    "id": 617464,
    "type": "FamilySymbol"
  }
}

This tells you:

  • Instance 616521
  • Is of FamilySymbol 617464

parent — relationships

Some objects include a parent field.

Common relationships:

  • FamilySymbol → parent Family
  • FamilyInstance → parent FamilySymbol
  • LinkInstance → parent LinkType

Example:

"parent": {
  "id": 617464,
  "type": "FamilySymbol"
}

This allows rules to:

  • find all instances of a given family
  • read symbol-level data while validating instances
  • traverse relationships explicitly

values — where the data lives

Almost all data you validate lives inside the values object.

Example (FamilyInstance):

"values": {
  "levelId": 311,
  "mark": "61",
  "exportedToIfc": "By Type",
  "ifcGuid": "2ziTjLSbz5HulRPb7oPoRS"
}

Typical validations:

  • read values from values
  • check presence or absence
  • compare against allowed values

Key object types

These are the most commonly used object types exposed by DAQS Assist (this list is not exhaustive):

Type JSONata filter
CadFile $[type = "CadFile"]
Family $[type = "Family"]
FamilySymbol $[type = "FamilySymbol"]
FamilyInstance $[type = "FamilyInstance"]
Parameter $[type = "Parameter"]
Level $[type = "Level"]
Material $[type = "Material"]
Room $[type = "Room"]
Space $[type = "Space"]
LinkType $[type = "LinkType"]
LinkInstance $[type = "LinkInstance"]
MechanicalSystem $[type = "MechanicalSystem"]
PipingSystem $[type = "PipingSystem"]
Grid $[type = "Grid"]
Workset $[type = "Workset"]
View $[type = "View"]

Most validation rules focus on:

  • FamilySymbol
  • FamilyInstance
  • Room
  • Material

Parameters in the JSON (important)

Shared and project parameters appear inside values using a consistent pattern.

Example:

"p_8fe8f5ce-4979-4679-b5e0-ccfb362b9059": {
  "id": 317596,
  "value": "30",
  "hasValue": true,
  "ref": "Parameter",
  "valueAsString": "30"
}

Key rules:

  • Parameter keys always start with p_
  • The suffix is the parameter GUID
  • id refers to an object of type = "Parameter"

The parameter definition itself appears elsewhere in the JSON:

{
  "id": 317596,
  "type": "Parameter",
  "values": {
    "guid": "8fe8f5ce-4979-4679-b5e0-ccfb362b9059",
    "name": "NLRS_C_brandwerendheid"
  }
}

This separation allows rules to independently validate:

  • parameter existence
  • parameter values
  • correct parameter usage context

Spatial context: levels, rooms, and spaces

Many objects reference a level using levelId:

"levelId": 311

Which corresponds to:

{
  "id": 311,
  "type": "Level",
  "values": {
    "name": "00 begane grond",
    "isBuildingStory": true
  }
}

Rooms and Spaces additionally expose:

  • area
  • volume
  • boundary data
  • level information

This enables rules such as:

  • “Only validate elements on building-story levels”
  • “Rooms must contain parameter X”

How to explore the JSON effectively

When writing or debugging a rule:

  1. Start by filtering on type
  2. Inspect one real object

  3. Identify:

  4. relevant fields inside values

  5. parameter GUIDs
  6. parent relationships
  7. Write the smallest possible JSONata filter
  8. Expand only when necessary

If you do not know where a value lives, inspect the JSON first.

Key takeaway

If you understand the DAQS Assist JSON, writing DAQS rules becomes a data filtering problem, not guesswork.