Skip to content

Validation UI — Name

validation_name

This name shows up in the DAQS Assist like this: validation_name

What this field is

Name is the human-readable identifier of the validation.

  • It is shown in DAQS Assist inside Revit
  • It appears in:

  • Validation results

  • Issue lists
  • Reports
  • It is not used for logic
  • It does not affect rule execution

Think of it as the headline of the rule violation.


What the Name should communicate

This is important: The Name answers only one question for the user:

“What is wrong with this element?”

Not:

  • how to fix it
  • why it failed
  • under which standard it falls

That comes later.

Good example

The instance must have a Mark parameter.

Why this works:

  • Short
  • Concrete
  • Binary expectation
  • Mentally scannable in a list

This is exactly the right level.


What the Name should not be

Be explicit in the docs here — people mess this up a lot.

❌ Bad patterns:

  • Long explanations

“The instance must have a Mark parameter according to BIM Basis ILS section 4.2.3” * Instructions

“Add a Mark parameter to this element” * Technical logic

“Validate shared parameter existence using GUID …” * Multiple checks

“Mark exists and is filled and unique”

If it doesn’t fit on one line in the Revit panel, it’s too long.


How this maps to the validation checklist

This field corresponds to one specific decision in the checklist:

Checklist step it represents

“What is wrong if this validation fails?”

More precisely:

  • It assumes you already decided:

  • missing parameter → fail

  • The Name is the externalised consequence of that decision

The Name is the verdict, not the reasoning.


Single vs Collection impact (important to explain)

Single validation

  • One Name
  • One failure meaning
  • Clean reporting

Collection of validations

  • Each validation has its own Name
  • Each Name should describe only its own failure

Example (collection):

  • “Door width parameter is missing”
  • “Door width has incorrect datatype”
  • “Door width value is outside allowed range”

Not:

  • “Door width is incorrect”

That defeats the entire purpose of collections.


Authoring rule of thumb

Add this as a callout in your docs:

✅ If a user sees only the Name, they should already know:

  • what is wrong
  • where to look

❌ If they still need to open the rule to understand the issue, the Name is too vague.


Why this matters in practice (real DAQS value)

In Revit:

  • Users scan, they don’t read
  • They triage issues, they don’t analyse rules
  • Clear Names = faster fixes = less resistance to rules

A sloppy Name turns a good validation into “noise”.