Data Structure Reference

This page is a reference for the JSON structure that DAQS Assist exports. Use it when writing or debugging filters and you need to know what fields are available.

For the conceptual explanation of why the data is structured this way, see The DAQS Data Model.

Global structure

The DAQS Assist output is a single JSON array:

[
  { "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.

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

Always start a rule with an explicit type filter:

$[type = "FamilyInstance"]

`id` — object identity

Each object has a unique numeric id.

IDs are used to:

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

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

`parent` — relationships

Some objects include a parent field that points to another object.

Common relationships:

Child	Parent
`FamilySymbol`	`Family`
`FamilyInstance`	`FamilySymbol`
`LinkInstance`	`LinkType`

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

`values` — where the data lives

Almost all data you validate lives inside the values object.

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

Key object types

Type	JSONata filter
`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"]`
`CadFile`	`$[type = "CadFile"]`
`Grid`	`$[type = "Grid"]`
`Workset`	`$[type = "Workset"]`
`View`	`$[type = "View"]`

Most validation rules focus on FamilySymbol, FamilyInstance, Room, and Material.

Shared and project parameters

Shared and project parameters appear inside values using a consistent pattern — keyed by p_ followed by the parameter GUID:

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

The parameter definition itself is a separate object in the array:

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

Spatial references

Many objects reference other objects by ID rather than embedding their data.

Field	References
`values.levelId`	A `Level` object
`values.roomId`	A `Room` object
`values.hostId`	The host wall or floor
`values.materialIds`	One or more `Material` objects

Example: to get the level name from an instance, look up the Level object whose id matches levelId.

How to explore the JSON

When writing or debugging a rule:

Filter on type first
Inspect one real object in the JSONata Exerciser
Identify the relevant fields in values, any p_<guid> keys, and parent relationships
Write the smallest possible filter expression
Expand only when necessary