Skip to content

Debugging Strategy

When a rule produces unexpected results — zero errors when you expect failures, errors on elements that should pass, or no output at all — the cause is almost always in the filter, not the validator.

This strategy works for any DAQS rule.

Step 1 — isolate the filter output

Before touching the validator, run the filter alone in the JSONata Exerciser and inspect what it returns.

Ask: - Does it return results at all? - Are the right elements included? - Are the right fields in the output? - Are values null where you expected data?

If the filter output is wrong, fixing the validator will not help.

Step 2 — check the object type

The most common cause of zero results is filtering the wrong object type.

/* Returns nothing if assemblyCode lives on FamilySymbol, not FamilyInstance */
$[type = "FamilyInstance"].{
  "assemblyCode": values.assemblyCode
}

Verify: does the data you need live on FamilyInstance, FamilySymbol, or Family? See Where Data Lives.

Step 3 — check the category condition

If the filter returns results but not the ones you expect, the category condition is often the issue.

Common mistakes: - Using category.name instead of category.label — breaks on non-English Revit - Filtering category on FamilyInstance instead of FamilySymbol - A typo in the OST_ label

Test the category condition in isolation:

$[type = "FamilySymbol"].{
  "name": name,
  "label": values.category.label,
  "type": values.category.type
}

Find the exact label for the elements you expect to see, then copy it into your rule.

Step 4 — check shared parameter keys

If a shared parameter field in the output is always null, the parameter key may be wrong.

Find the correct key:

$[type = "Parameter" and values.name = "NLRS_C_brandwerendheid"].values.guid

Then verify it appears on the element:

$[type = "FamilyInstance" and id = 616521].values

Look for the p_<guid> key in the output.

Step 5 — check the parent.id chain

If two-step filtering returns zero instances, the symbol IDs may not match.

Debug by printing both sides:

(
  $doorSymbolIds := $[type = "FamilySymbol" and values.category.label = "OST_Doors"].id;

  /* Check: does this return IDs? */
  $doorSymbolIds
)

Then check if any instance references those IDs:

$[type = "FamilyInstance" and parent.id in $doorSymbolIds].id

If the second step returns nothing, either the symbols or the instances are filtered too aggressively.

Step 6 — simplify until it works

If you cannot find the problem, strip the filter down to the minimum and add conditions back one by one.

/* Start with just the type filter */
$[type = "FamilySymbol"]

/* Add category */
$[type = "FamilySymbol" and values.category.label = "OST_Doors"]

/* Add assembly code */
$[type = "FamilySymbol" and values.category.label = "OST_Doors" and values.assemblyCode != null]

The condition that causes results to disappear is the one that is wrong.

When the filter is correct but the validator still fails

If the filter returns exactly what you expect but the validator produces wrong results:

  • Check that the valueToValidate query matches the field name in the filter output exactly (case-sensitive)
  • Check that the field contains the data type the validator expects — a string validator on a number field will not behave as expected
  • For shared parameters: check whether the validator is receiving the full parameter object ({ value, hasValue, ... }) or just the value