Skip to main content

​
Understanding Rule Structure

Each rule consists of one or more conditions that work together to validate model elements. Rules use a structured logic system:
ComponentDescription
LogicHow conditions combine: WHERE (filter), AND (additional filter), CHECK (final validation)
Property NameThe object property to check (e.g., category, width, baseline.length)
PredicateThe comparison (UI labels such as Equals and Exists; TSV files use phrases like equal to and exists)
ValueThe reference value for comparison
MessageDescription shown in validation results (auto-generated but can be overwritten)
Report SeverityDefines the importance: ERROR, WARNING, or INFO
Important Rule Structure: Every rule must follow this pattern:
  • Start with a WHERE condition to filter objects
  • Add AND conditions to further refine the filter (optional)
  • End with a CHECK condition that performs the validation
Each rule should only have one CHECK condition at the end. If you need multiple checks, create separate rules.

​
Creating Your First Rule

​
Example: Checking Wall Thickness

Let’s create a rule that checks if walls are at least 200 units thick:
  1. WHERE condition: Filter for walls
    • Property: Category
    • Predicate: Equals (in TSV: equal to)
    • Value: Walls
  2. CHECK condition: Validate thickness
    • Property: Width
    • Predicate: Less than (in TSV: less than)
    • Value: 200
    • Severity: ERROR
    • Message: “Wall thickness must be at least 200” (auto-generated, but can be customized)
This rule will flag any wall thinner than 200 units as an error.

​
Adding Multiple Conditions

You can add multiple AND conditions between WHERE and CHECK to create more complex filters: Example: Check steel beams that are too long
  • WHERE Category = Beams
  • AND Material = Steel
  • CHECK Length > 5000

​
Predicates in the UI

Property Checker, Model Validation, and dashboard filters share the same predicate picker. Labels match what you see in the dropdown; they depend on property type (text, number, or boolean). For text properties, predicates are grouped as Existence, Comparison, and Text:
GroupUI labelMeaning
ExistenceExistsThe property is present
ExistenceDoes not existThe property is not present
ExistenceHas valueThe property is present and not empty
ComparisonEqualsExact match (one value)
ComparisonDoes not equalNot equal to one value
ComparisonIs one ofMatches any of the chosen values
ComparisonIs not one ofMatches none of the chosen values
TextMatches patternWildcards or regex (case-insensitive)
TextContainsSubstring match
TextDoes not containExcludes substring
For number properties, predicates are grouped as Existence, Comparison, and Range:
GroupUI labels
ExistenceExists, Does not exist, Has value
ComparisonEquals, Does not equal, Is one of, Is not one of, Is equal to, Is not equal to, Is greater than, Is less than
RangeIs between
See Filters — Numeric properties for descriptions and a screenshot of the menu. For boolean properties, use Is true and Is false. See Filters — Operators and data types for pattern syntax (Matches pattern / wildcards and regex) and filtering behaviour.

​
TSV predicate strings

Legacy TSV rulesets use a fixed Predicate column. The strings in the table match what appears in that column and map to the UI labels above.
TSV is an older interchange format for rulesets. Prefer defining and editing rules in Intelligence. Keep this table when you still import, export, or maintain existing TSV files.
TSV Predicate valueTypical UI label
existsExists
not existsDoes not exist
has valueHas value
equal toEquals or Is equal to
not equal toDoes not equal or Is not equal to
in listIs one of
not in listIs not one of
is likeMatches pattern
containsContains
does not containDoes not contain
greater thanIs greater than
less thanIs less than
in rangeIs between (min and max)
is trueIs true
is falseIs false
Some imported files may use identical to; it is treated like equal to when loading rules.

​
Rule Types

​
Property Existence

Check whether specific properties exist on model elements. Useful for ensuring required data is present. Example: CHECK that acoustic rating uses Exists (TSV predicate exists).

​
Pattern Matching

Validate that property values match specific patterns or formats. For example, ensure element names follow a naming convention. Matches pattern in the UI (TSV predicate is like) supports two modes: Wildcard mode (default):
  • % — matches any sequence of characters (including none)
  • _ — matches a single character (when supported)
Regex mode:
  • Wrap your pattern in forward slashes: /pattern/
  • Supports full regular expression syntax (character classes, anchors, alternation, quantifiers, etc.)
Matching is case-insensitive in both modes. Use Matches pattern / is like with wildcards for simple pattern matching, or use /regex/ for complex validation. For substring matching without patterns, use Contains / contains.

​
Numeric Comparisons

Compare numeric property values against thresholds or ranges. Check that dimensions, areas, or other measurements meet requirements. In the UI, use Is greater than, Is less than, or Is between. In legacy TSV, the same checks use greater than, less than, and in range.

​
Value Validation

Verify that properties contain expected values or fall within acceptable ranges. Examples (UI → TSV):
  • Equals → equal to
  • Is one of → in list (comma-separated values in the TSV Value column)
  • Does not equal → not equal to

​
Rule Messages

Rule messages are auto-generated to help validate the logic you are testing for. The auto-generated message describes what the rule is checking, making it easier to understand the validation logic. You can overwrite the auto-generated message with a custom message if you want to provide more specific guidance or context.
Auto-generated messages help ensure your rules are clear and understandable. Consider customizing them when you need to provide specific instructions or context for your team.

​
Best Practices

​
Use Specific Property Paths

Use exact property paths for accurate validation. Rules apply to properties in Speckle objects regardless of schema:
  • Direct properties: category, name, id
  • Nested properties: baseline.length, parameters.WIDTH.value
  • Revit parameters: Use parameter names like Mark, Width, Assembly Code
If a property like Length exists in multiple locations within an object’s properties, specifying baseline.length ensures the correct value is checked.

​
Set Appropriate Severity Levels

  • ERROR: Critical issues that must be fixed (e.g., “Wall thickness must be at least 200”)
  • WARNING: Moderate concerns that should be reviewed (e.g., “Height should be no more than 3000”)
  • INFO: Informational notifications (e.g., “Material is Concrete”)

​
Write Clear Messages

When customizing messages, make them actionable and specific. Avoid vague terms like “Wall thickness check” and instead say “Wall thickness must be at least 200mm.”

​
Examples of Good vs. Bad Messages

Rule ConditionBad Message ❌Better Message ✅
Width less than 200 and ERROR”Wall thickness check""Wall thickness must be at least 200”
Height greater than 3000 and WARNING”Height check""Height should be no more than 3000”
Material equal to "Concrete" and INFO”Material info""Material is Concrete”

​
Common Rule Patterns

​
Filter by Category

WHERE Category = Walls
CHECK [validation condition]

​
Multiple Filters

WHERE Category = Beams
AND Material = Steel
CHECK Length > 5000

​
Property Existence Check

WHERE Category = Windows
CHECK acoustic rating exists

​
Value Range Check

WHERE Category = Walls
CHECK Width in range 200,400

​
Door Naming Convention

Using wildcards: 
WHERE Category = Doors
CHECK name is like D%
This matches door names that start with “D” (e.g. “D001”, “D123”, “Door-01”). Using regex: 
WHERE Category = Doors
CHECK name is like /^D\d{3}$/
This strictly matches “D” followed by exactly three digits (e.g. “D001”, “D123”, but not “Door-01” or “D12”).

​
Structural Column Height Range

WHERE Category = Columns
AND is_structural is true
CHECK height not in range 2400,4000
This rule checks that structural columns have heights between 2400 and 4000 units.

​
Exporting and Importing Rulesets

​
Exporting

Rulesets can be exported as files for backup or sharing:
  1. Open your project’s rulesets
  2. Select the ruleset you want to export
  3. Use the export option to download the ruleset
Exported files use the TSV (Tab-Separated Values) format. TSV files can be imported back into your project or shared with other projects or teams.

​
Importing Rules

If you have existing rules in a file, you can import them:
  1. Open your project’s rulesets
  2. Click Import
  3. Provide a name and description for the imported ruleset
  4. Upload your file
Imported files should use the TSV (Tab-Separated Values) format. The file should have the following columns:

​
File Format

The file format should have the following columns:
  • Rule Number - Groups conditions into a single rule
  • Logic - WHERE, AND, or CHECK
  • Property Name - The object property to check
  • Predicate - The comparison operation
  • Value - The reference value for comparison
  • Report Severity - ERROR, WARNING, or INFO
  • Message - Description shown in validation results

​
Example File

Rule Number	Logic	Property Name	Predicate	Value	Report Severity	Message
1	WHERE	Category	equal to	Walls		
1	CHECK	Width	less than	200	ERROR	Wall thickness must be at least 200
2	WHERE	Category	equal to	Beams		
2	AND	Material	equal to	Steel		
2	CHECK	Length	greater than	5000	WARNING	Steel beams should not exceed 5000 in length

​
Managing Multiple Rulesets

You can create multiple rulesets for a single project. This is useful for organizing different types of validation checks:
  • Building Code Compliance - Rules for code requirements
  • Naming Conventions - Rules for element naming standards
  • Material Standards - Rules for material specifications
  • Dimensional Checks - Rules for size and dimension validation
Each ruleset can be used independently for different validation purposes.

​
FAQ

Yes, the auto-generated messages are designed to be clear and helpful. You can use them as-is or customize them to provide more specific guidance for your team.
You can add multiple AND conditions between WHERE and CHECK to filter by multiple properties. However, the CHECK condition should validate a single property. If you need to check multiple properties, create separate rules.
Use the exact property path as it appears in your model data. If you’re unsure, explore your model’s properties in the 3D viewer or use the property search in the validation interface to find the correct path.
Yes, exported files can be shared with other teams or imported into other projects. This makes it easy to standardize validation rules across projects.
IDS (Information Delivery Specification) is designed for IFC model checking, but IDS rules can be applied to all Speckle models regardless of their source format. There are important differences:
  • IDS checks for rules that relate to assembly membership - IDS can validate relationships between elements and their assemblies
  • Property- and Model Validation focus on data within an element - They validate properties and data within individual elements, not relationships between elements
Future updates will include support for importing IDS and COBie for the definition of rulesets.
Last modified on April 13, 2026