Skip to main content
Current limitation:After you save a check, you can edit its name and description, or delete it. Tracked models, rules, predicates, and trigger mode stay frozen. For different behaviour, create a new check.
Use this page for Validation Check authoring and execution.
Checks are executable validation definitions tied to tracked models. They run against versions in the data format introduced in 2026.9; see Data Validation.
Checks can be defined and run against models in a project. Editing an existing check is limited to name and description until model scope, rules, and trigger mode become editable.Feedback welcome on expected versioning behavior for checks (for example: mutable checks vs immutable versions or forks).

​
Run a first check

Use Run check from the project sidebar when you want to test rule logic on real project data.
1

Load preview model

Empty first screen until a preview model loads. Load preview to unlock starters and pick model/version context first.
2

Draft and preview rules

Define WHERE / CHECK; preview (Run Preview or Ctrl+Enter / Cmd+Enter) to validate logic before save.
3

Review first output

First preview yields one aggregate plus one row per rule.
4

Refine before save

Preview is ephemeral, so tune scope before save. Edited rules prompt a rerun so displayed numbers stay trusted.
5

Handle large-model behavior

Large models may skip the 3D pane; assertions still evaluate when preview is unloaded.
6

Confirm persistence

Done when Checks shows the new card, which confirms persistence.
Rules display as short sentences, for example category is Doors. Select a sentence to edit it.

​
Import rules from IDS, COBie, or Speckle

On an empty check, select Import IDS, Import COBie, or Import Speckle to turn an existing requirements file into rules. You can also drop an IDS or COBie file onto the check assistant to adapt it to the model. Always rerun preview on a representative version after import, then tune predicates if needed.
  • IDS — IFC-aligned facets map to rules. Most facets map to Exists, Equals, In list, or Between. IDS xs:pattern values often land as Contains rather than full regex, so verify naming rules after import. Advanced applicability or property mappings may need manual fixes.
  • COBie — worksheet fields map to rules. Typical outcomes are sheet-scoped Exists checks and pick-list In list assertions. Optional fields often arrive as info severity so they do not drive the overall score. Unusual columns or macro-heavy sheets can lose fidelity, so verify property paths, severities, and messages.
  • Speckle — JSON, TSV, or CSV exports from dashboards and related tooling. Supported dashboard predicates map to Data Validation operators; unsupported negations (not exists, not in list, does not contain) are skipped, and dashboard warning severity becomes info.

​
Build a check with many rules

One topical check can own many rules (e.g. fire ratings on walls/doors/windows) so failures stay rule-level inspectable—use Add rule, one requirement per rule, per-rule Run, duplicate when scopes match.

​
Operate checks over time

Saving locks rules to tracked models—later versions rerun the same predicates without redoing ad-hoc spreadsheets. Manual vs auto trigger matches how tightly you gate runs. Charts need repeated runs—the first save is often your baseline-only pass. Expanded rule rows expose WHERE → CHECK counts when a filter swallowed your elements prematurely. Layouts: What you see on the page. Ordering: Practical review flow. Save the check after scope is final, then read combined scores on Viewing Results. First visit to results can lag when many rules, models, or deep history enqueue work.

​
Rule structure in checks

Each rule is filters plus one assertion.

​
Default scope

A new check starts with an empty global scope. The version already contains user-facing objects only, so no starting filter is needed. Narrow with category, type, or parameter filters in WHERE when you need a tighter rule. Add condition adds a scope filter above the check; it does not turn the existing check into a filter. An unsaved draft from before 2026.9 that still carries the earlier default filter loses it when you reopen the draft. Saved checks keep it; see the warning below.
One terminal CHECK per rule—extra assertions belong in extra rules.
A check saved before your project used the 2026.9 data format can return no objects: preview shows empty counts and an empty object table. The stored rule still uses the earlier object filter, which the editor does not show, so you cannot clear it in place. Create a new check, run preview, then save.

​
Thresholds and status

Rates map through thresholds. You set a global pass (and optional warn) threshold when saving, and you can override thresholds per rule in authoring. Statuses: PASS (≥ pass), WARN (between thresholds when warn is set), FAIL (under thresholds), PENDING (evaluation not finished). Only error severity rules contribute to the overall check score. info rules still evaluate and appear in results, but they do not change the aggregate pass rate. Interpret outcomes on Viewing Results.

​
Predicates and matching

The operator dropdown lists every authorable predicate. The UI does not grey operators by property type—pick a value shape that matches the property you are testing (text, number, or boolean). Booleans compare as Equals with true or false.

​
Operator catalog

​
Matching details

Matches (wildcard): * and % match any character run; ? matches one character. Matching is case-sensitive. Matches (regex): turn on the .* toggle to use a regular expression. You can enter a plain pattern, or a /pattern/i literal for case-insensitive matching. Lookahead, lookbehind, and backreferences are not supported. Regex mode requires a full-string match. The pattern must account for the entire value, not only the prefix you are asserting. ^(Wall|Door) matches only the exact strings “Wall” and “Door”. Use ^(Wall|Door).* to match values that start with those prefixes, or use wildcard mode (Wall*) instead. See Regex mode for more pattern examples. Equals template: bind {{token}} placeholders to other property paths. Use exact mode to require the concatenated value, or regex mode (same .* toggle and the same full-string match) when the template is a pattern. Contains is substring search only. Prefer Matches when you need wildcards or regex.

​
Numeric tolerance

Optional per-condition Tolerance sets decimal places N (ε = 10^-N). It applies to numeric Equals, Equals property, At least, At most, and Between. It does not apply to Greater than, Less than, Not equals, list/text operators, or Exists.

​
Property paths

Pick paths from the path picker after a preview model loads so value suggestions come from real data. Typical Revit parameters sit under properties.Parameters, for example type Width under properties.Parameters.Type Parameters.Dimensions.Width. Common shapes:
  • category
  • name
  • properties.Parameters.Type Parameters.Dimensions.Width
Paths such as parameters.Width.value and baseline.length come from the data format used before 2026.9 and may not exist on your version. Use the path picker for the paths your model has.

​
Match a property wherever it sits

A Fire Rating parameter is not always on the same path. Click the path-matching control next to the path to cycle modes:
  • Exact (=) — the full path from the picker
  • Suffix (*.x) — every property whose path ends with that segment, for example Fire Rating. Every matching value must pass
  • Regex (.*) — a regular expression over the full path
That covers instance and type placements without a separate rule for each path. Path matching is not available on Equals property or Equals template. Those operators compare two specific paths.

​
Short examples

  • Fire rating present: WHERE category Equals Walls, CHECK fire-rating path Exists (or Equals a required rating string).
  • Width band: CHECK the Width path Between 100 and 300, with tolerance if units are noisy.
  • Naming convention: CHECK name Matches W-*. In regex mode use ^W-.* so characters after the prefix still match.
  • Consistency: CHECK one path Equals property against another path on the same object.
A rule can check an object against something it is related to — a door against the wall that hosts it, or a wall against the rooms it bounds — because those relationships are in the published version. Use Add related object on the rule. The editor adds a binding row. The name on the left (@host, @room, @connected) is how later conditions address that object. Pick a relationship from the list the version actually carries. Friendly labels include Host element, Sub-elements, Room, Bounded room, Assembly, and Connected element. Then choose a property on that related object from the path picker. Related paths show as @host · Fire Rating in the sentence pills.
Add related object is disabled when the preview version has no relationship data. The tooltip reads This model has no relationship data — re-publish with a current connector to use related-object rules.

​
Direction, all versus any, and narrowing

The arrow on the binding follows the relation forward (for example a door toward its host wall) or backward (a wall toward the elements hosted on it). Click the arrow to reverse it. all (default) means every related object must satisfy the check. any means one related object is enough. That setting applies to the check only. A scope filter on a related path still keeps a subject when at least one related object matches, regardless of all or any. Open where and select Narrow related objects to keep only some related objects, for example hosts whose category is Walls. Those filters run on the related object. They do not use @ prefixes. A subject with no related object fails a check that reads that binding. If a door with no host should be not applicable instead of a fail, add a scope condition that the related path exists (for example @host is present) before the check. Examples you can author:
  • A door’s fire rating must match the wall that hosts it
  • If the host wall is fire-rated, the door must be rated. Unrated walls are not applicable, not a fail (scope on the host rating, then check the door)
  • Every door must be hosted on a wall
  • Every wall that bounds a room carries a rating (all), or at least one of them does (any)
  • A door can be checked against a room reached through the host wall: add a second related object, set of to @host instead of this element, and pick Bounded room or Room
You cannot remove a binding while a condition still uses @name, or while a later binding chains from it. Update those references first.

​
Map labels before you compare

When a check compares two properties (Equals property), you can map each side’s raw labels onto shared values before the comparison. This is how 60 MIN and 1 HR become the same rating, and how a 2 HR wall can require a door of at least 90 MIN. Select Equals property, pick the other path, then open the comparison control beside it. The control shows = until you add a mapping or change the comparison. Set Compare to = equals, ≥ at least, or ≤ at most. Under This value maps and Other value maps, select Add mapping, pick a raw value from the list, and set what it maps to. Unmapped values stay as they are. Map both sides to the same numbers when the labels should count as equal. Map the other side to a required minimum and use ≥ at least when one side must be stricter than the other. The same mapping works when the other path is on a related object, such as a host wall.
If preview already lists known values, Seed N known values on that mapping list fills it so you do not type every label. Seed one side at a time. The control is hidden when the list is empty or too large to seed in one step.

​
Check a calculated value

Some rules test a number no single property holds, such as a beam’s span-to-depth ratio: its length divided by the depth parsed from a section name like 300x600. A rule’s scope or check can test a computed value calculated from each object’s properties. The usual comparisons apply, so the threshold stays a value you can edit. Describe the calculation to the assistant to create it.
1

Describe the calculation

In the check editor, select Generate rule, or ask Speckle Intelligence in Chat. Name the inputs, how to combine them, their units, and the threshold.
2

Review the value range

Before it offers the rule, the assistant states the range of values, the units, and how many objects have no value. Confirm the range fits what you asked for.
3

Save the rule

Accept the rule the assistant proposes, then save the check. The rule shows the computed value as Σ followed by its name.
An example ask:
If you already coloured a model by a calculated value in the 3D viewer, ask the viewer sparkle Make this a validation rule: the ratio must be at most 20 to reuse that calculation.
Select the Σ subject in the editor to see the description, the unit, and the SQL behind it. The comparison and threshold stay editable like any other condition.

​
Change the calculation

Select the Σ subject, then Edit with AI to describe the change to the assistant, or Edit SQL to change it yourself. When you edit by hand, you can change the description, the unit, and the SQL. Select Preview to run the edited SQL in its rule. The preview shows the range of values, how many objects it checked, and how many have no value. Apply stays disabled until the preview has run on exactly the current SQL, no object has more than one value, and you confirm the description and unit still match.
The preview checks the calculation runs and gives one value per object. It cannot tell whether the formula is right. Compare the range with what you expect before you apply.
When you open a failing rule in results, the object table adds a first column with each failing object’s value against the rule, for example 22.5, expected ≤ 20.

​
When there is no value or more than one

An object whose inputs are missing, or do not parse (a type name like Custom beam), has no value. A scope condition on the computed value drops it, and the check fails it. The object table shows no value, expected ≤ 20. To treat those objects as not applicable, ask the assistant to check only objects where the value can be calculated. The calculation must give one value per object. When it gives more than one for any object the rule checks, the rule shows ERROR with a message such as 3 objects have more than one computed value, instead of pass or fail. Ask the assistant to fix the calculation. Computed values work in a rule’s scope and check only, not in the global scope or on a related object. Each one reads the properties of the model the check runs on.

​
Run a check on every submission automatically

For the specific pattern of validating incoming consultant or subcontractor models against your standard at every milestone — author once, set auto trigger, and stop relying on someone to remember to run it — see Validate incoming models automatically.

​
Best practices

Tighten WHERE first so broad scopes do not flood triage. Write descriptive Message text so fix owners can act without extra clarification. Run preview before save so you catch false positives before history is recorded.

​
FAQ

Project standards are being retired, and the Data Validation sidebar no longer lists them. Author and save checks instead. See Project standards.
The check was saved before your project moved to the 2026.9 data format, and its stored rule still uses the earlier object filter. Saved checks cannot change rules in place. Create a new check, run preview, then save. See Default scope.
No. The object set is already the user-facing elements, so an empty global scope is the correct starting point. Narrow with category, type, or parameter filters in WHERE.
The calculation could not read one of the inputs, for example a type name like Custom beam that does not match the expected pattern. Fix the source data, or ask the assistant to handle that format. See When there is no value or more than one.
Noise usually means tighten WHERE, tune predicates, or downgrade severity to info.
Existing results stay in history because they store the evaluated model/version ids from run time. The deleted model no longer appears in live scope, so future runs exclude it.
Rule order follows how rules were authored and saved. Reordering is not supported yet, so duplicate or recreate is the fallback when order matters for review.
Preview runs against the current session model/version and is not persisted after you leave. Saving persists tracked models, trigger mode, thresholds, and result history.
First confirm the result used the model/version you expected, then inspect failing rules for missing or changed properties in the new version. If needed, create a narrower replacement check for debug, export BCF for issue handoff, then keep the replacement once root cause is clear.
Regex mode matches the entire value, not a prefix. ^(Wall|Door) matches only those exact strings, so values such as Wall_01 fail. Append .* (^(Wall|Door).*) or use wildcard mode (Wall*). See Predicates and matching.
Last modified on October 19, 2026