Revit Object Hierarchy
Almost every beginner mistake in DAQS rules traces back to one thing: not knowing which object type carries the data you need.
This page explains the four core object types and what data lives on each one.
The four object types
Family
The Family is the definition of a loadable element — the .rfa file.
It tells you:
- whether the family is editable (isEditable)
- what placement type it uses
- whether it is an in-place family
In DAQS JSON:
{
"id": 617348,
"type": "Family",
"name": "Door wooden",
"parent": null,
"values": {
"isEditable": true,
"isInPlace": false,
"familyPlacementType": "OneLevelBasedHosted"
}
}
Rules that use Family: "only check editable families", "exclude in-place families".
FamilySymbol (Type)
The FamilySymbol is a type within a family — what Revit calls a "Type" in the Type Properties dialog.
It carries data that is shared by all instances of this type:
- Category
- Assembly Code
- Fire Rating
- Type Mark
- Shared parameters bound to types
In DAQS JSON:
{
"id": 617464,
"type": "FamilySymbol",
"name": "1018x2387",
"parent": { "id": 617348, "type": "Family" },
"values": {
"assemblyCode": "32.31",
"category": { "name": "Doors", "label": "OST_Doors" },
"fireRating": null,
"typeMark": "67"
}
}
Rules that use FamilySymbol: "all door types must have an Assembly Code", "fire rating must be filled".
FamilyInstance
The FamilyInstance is a placed element in the project — one specific door, beam, or luminaire in the model.
It carries data that is specific to this placement:
- Mark
- Level
- Host
- Comments (instance)
- Shared parameters bound to instances
In DAQS JSON:
{
"id": 616521,
"type": "FamilyInstance",
"name": "1018x2387",
"parent": { "id": 617464, "type": "FamilySymbol" },
"values": {
"mark": "D-01",
"levelId": 311,
"comments": null
}
}
Rules that use FamilyInstance: "every placed door must have a Mark", "no instance may be on a demolished phase".
Parameter
The Parameter object is the definition of a shared or project parameter — its name, GUID, and data type.
It does not hold a value. Values appear on the objects that the parameter is bound to.
In DAQS JSON:
{
"id": 317596,
"type": "Parameter",
"name": "NLRS_C_brandwerendheid",
"parent": null,
"values": {
"guid": "8fe8f5ce-4979-4679-b5e0-ccfb362b9059",
"name": "NLRS_C_brandwerendheid",
"spec": "Text",
"isProjectParameter": true
}
}
Rules that use Parameter: look up a parameter GUID by name to access it on instances or types.
The hierarchy at a glance
Family
└── FamilySymbol (one or more types)
└── FamilyInstance (one or more placed elements)
Parameter (separate — defines shared/project parameters)
In DAQS JSON, this hierarchy is expressed through parent references — not nesting.
Summary table
| Object | Revit name | Carries | Typical rule use |
|---|---|---|---|
Family |
Family | editability, placement type | scope to loadable families |
FamilySymbol |
Type | category, Assembly Code, type parameters | validate type-level data |
FamilyInstance |
Instance | mark, level, instance parameters | validate per-element data |
Parameter |
Shared / project parameter | name, GUID, data type | look up parameter definitions |
The rule you must remember
You cannot validate data at a level where it does not exist.
assemblyCode lives on FamilySymbol. If you filter FamilyInstance and try to read values.assemblyCode, you will get null — not because the value is missing, but because you are looking at the wrong object.
This is explained further in Where Data Lives.