Validation UI — Value to validate

What this field is

Value to validate defines what exact data the validator will receive.

Not:

• which element is checked
• not which rule runs

But very precisely:

Which value (or values) from the filter output are handed to the validation logic.

This is the bridge between:

• the filter (data preparation)
• and the validator (decision making)

---

Why “Query” is used in ~99% of rules

“The value I want to validate already exists in the filter output, and I want to reference it directly.”

That means:

• No additional data access
• No hidden lookups
• No Revit querying at validation time

The validation only sees:

• what the filter returned
• under the keys you defined

This is by design, not a limitation.

---

What the Query field actually contains

In your example:

brandwerendEis

This means:

• brandwerendEis must be a key in the filter output
• The validator will receive exactly that value
• If the key does not exist → the value is null

The filter of this rule is:

(
  $[type = "FamilyInstance"].{
    "id": id,
    "type": type,
    "name": name,
    "levelId": values.levelId,
    "brandwerendEis": values."p_36ddc047-2c5f-4365-9bda-14ccea06b50f"
  }
)

The json that this filter returns look like this:

  {
    "id": 320674,
    "type": "FamilyInstance",
    "name": "fout_fout_fout_fout_bijna__",
    "levelId": 311,
    "brandwerendEis": {
      "id": 336553,
      "value": "",
      "hasValue": false,
      "ref": "Parameter",
      "valueAsString": null
    }
  }

and the query brandwerendEis resolves to the entire parameter object:

{
      "id": 336553,
      "value": "",
      "hasValue": false,
      "ref": "Parameter",
      "valueAsString": null
}

This means the validator does not receive a primitive value, but a structured parameter object containing:

• hasValue — whether the parameter is set
• value — the raw value (may be empty)
• valueAsString — formatted representation (may be null)

Important consequence (this ties back to your checklist):

If the key is missing, the validator does not know why. It only sees “no value”.

---

Mapping this UI control to the awareness checklist

This field directly touches three checklist questions.

---

1️⃣ What if the parameter does not exist?

This is decided here, not later.

• If the filter did not output brandwerendEis
• Then the Query resolves to null

• The validator must now decide:

• fail

• skip
• or accidentally pass

👉 If you didn’t plan for this, you already lost control of the rule.

---

2️⃣ Is the value empty?

Again: determined before the validator runs.

• Empty string
• Empty list
• null

All of these look different to a validator.

The Query does not normalize values. It passes them through as-is.

---

3️⃣ What is the datatype?

The Query determines this implicitly.

• Text stays text
• Numbers stay numbers
• Booleans stay tri-state (Yes / No / Unset)

The validator will assume the datatype matches its intent.

If it doesn’t, the rule is wrong — not the data.

---

What this field does not do

Be very explicit in the docs:

❌ The Query field does not:

• Fetch missing parameters
• Convert datatypes
• Fall back to symbol if instance is empty
• “Fix” bad filters
• Query Revit again

It only reads what the filter already prepared.

This reinforces your earlier principle:

If it’s not in the filter output, it does not exist.

---

Why this UI choice enforces good rule design

This is worth calling out explicitly, because it’s a strength of DAQS.

By forcing users to:

• explicitly choose a value
• explicitly reference a filter key

DAQS prevents:

• hidden logic
• magical defaults
• “it worked in my model” rules

Every rule becomes:

• inspectable
• explainable
• auditable

---

Authoring rule of thumb

✅ If you struggle to write the Query expression, your filter is not ready yet.

People often try to solve filter problems here. That’s the wrong place.

---