Skip to content

DAQS Rule Writing Instructions

When generating rule documentation for DAQS rules, always follow the structure and conventions below.

The goal is to ensure consistent documentation, consistent error messages, and clear explanation for users of the DAQS Assist plugin.

  1. Rule Description (Markdown)

The rule description must always follow this structure.

Use clear technical language and avoid marketing or vague explanations.

What does this rule do?

Explain in one short paragraph what the rule checks.

Mention: - what type of element is analyzed (Family Instance, Family Type, System element, etc.) - what parameter, property, or geometry is checked - if relevant: standards such as BIM Basis ILS or NLRS.

What the rule checks

Describe precisely what the rule evaluates.

Explain: - which elements are filtered - which parameters or values are compared - if lookup tables or parameter relationships are involved.

Use bullet points when possible.

Scope of the check

Describe which elements are included or excluded.

Examples:

  • only editable loadable families
  • only Family Types
  • specific categories
  • specific Assembly Codes
  • elements containing geometry

Why this rule exists

Explain why the rule matters.

Typical reasons:

  • data consistency
  • correct classification
  • BIM data reliability
  • quantity take-offs
  • downstream analysis
  • compliance with BIM Basis ILS
  • Error Message Structure (MANDATORY)

All DAQS error messages must follow the fixed structure below.

Never change the section titles.

The placeholders between {{ }} come directly from the filter output.

Anything returned by the filter can be used in the error message.

Example:

{{name}} {{paramName}} {{ActualValue}}

The double curly brackets are mandatory.

Error Message Template

Issue

Explain clearly what is wrong with the element.

Include: - element name - parameter name - incorrect value - expected value if applicable

Example:

The element {{name}} contains an invalid value for parameter {{parameterName}}.

The current value is {{ActualValue}}, but this value is not allowed.

Solution

Explain exactly how the user should fix the issue.

Example:

Open the element in Revit and update the parameter {{parameterName}} so that it contains a valid value according to the project standard.

Explanation

Provide additional context.

Explain:

  • why the value is required
  • how the value is used in BIM workflows
  • what problems occur when the value is incorrect.
  • Collection Error Message

A collection error message is shown when multiple elements fail the same rule.

The message should summarize the issue without listing every element individually.

Collection Error Message Template

Issue

Multiple elements contain invalid or missing values for {{parameterName}}.

These elements do not comply with the required project standard.

Solution

Review the affected elements and update the parameter {{parameterName}} so that it contains a valid value.

Explanation

Correct parameter values ensure consistent BIM data and allow reliable use of the model for scheduling, analysis, and data exchange. 4. Notion Rule Explanation Format

When explaining a rule in Notion, use the following format.

This format is used for internal rule documentation and rule definition.

Rule name

Explain briefly what the rule checks.

This rule verifies that specific elements comply with a required parameter value, classification, or relationship.

What this rule checks

Describe the technical behavior of the rule.

Examples:

  • checks if a parameter exists
  • checks if a parameter value is empty
  • checks if a value exists in a lookup table
  • checks if two parameters correspond to each other

Scope of the check

Explain which elements are included.

Examples:

  • Family Instances
  • Family Types
  • elements with Assembly Code 28.11
  • elements belonging to specific categories.

Expected behavior

Explain what should happen.

If the parameter does not exist

The element should be flagged because the required parameter is missing.

If the parameter is empty

The element should be flagged because the value is required.

Valid and invalid values

Explain what values are considered correct.

Examples:

Valid value:

28.11

Invalid values:

(empty) incorrect classification value not in lookup table

Explanation

Explain why the rule exists and what the project wants to achieve with it. 5. Key Principles

Always follow these principles when generating rule documentation.

Consistency

Use the same wording style across rules.

Clarity

Users should immediately understand:

what is wrong

how to fix it.

Traceability

Use placeholders from the filter output to show exact values.

Technical accuracy

Always clearly distinguish between:

Family Instance

Family Type (FamilySymbol)

System elements

Geometry checks

Parameter checks.