Skip to main content
Standards are project-scoped today, so they are useful when teams need reusable rule sets inside one project before workspace- or org-wide catalogs are available.

What standards are for

Standards become useful once several checks need the same rule contract and you want one source to clone from. They reduce repeated authoring and keep naming, severity, and predicate intent consistent across checks.
Standards compile to Speckle WHERE / CHECK definitions when spawning checks—they are not a separate DSL from Data Validation authoring.

Create first standard

This flow is for rules you plan to reuse across checks. Steps mirror checks: optionally load preview, pick model/version, author or import (WHERE / CHECK—see Rule structure in checks), preview, rerun after edits. Skip heavy 3D when needed—the editor still validates. Finished when Standards lists the artifact for check creation/import pickers.

Save or import outcome

Saved authoring → Save standard. IDS / COBie / Speckle imports land straight under Project standards once complete.

Build standard with many rules

Group related clauses in one standard so downstream checks duplicate less—Add rule, one mandate per rule, per-rule preview, duplicate shared filters.

Import formats

IDS: IFC-aligned facets import into standard rules, then open in the same editor for preview and adjustment. Some advanced applicability/property mappings may need manual fixes before use in checks. COBie: Worksheet fields map into rules and are saved under project standards after import. Unusual columns or macro-heavy sheets can lose fidelity, so verify property paths, severities, and messages before spawning checks. Speckle: JSON/tab exports from dashboards, Automate, or related tooling import directly as standards entries. Rows with widget-specific semantics may still need rewrite into explicit WHERE / CHECK logic. New rows appear instantly in Project standards—no extra publish step. Regardless of vendor, rerun preview on a representative revision to catch importer blind spots.

Standards to checks flow

1

Create or import your standard

Same authoring loop as checks, or ingest IDS / COBie / Speckle—see Rule structure in checks.
2

Refine rule logic

Lock scope, predicates, severities, and copy before clones ship.
3

Create checks from standard

Spawn checks with per-check models and triggers. Read runs on Viewing Results. Standard-card Run check jumps into Checks authoring.
Editing an existing standard does not auto-mutate already-saved checks—fork or recreate checks when breaking logic shifts.

Best practices

Use one naming convention such as Topic-Scope-v2 (FireRating-Walls-v2) so owners can identify intent and revision quickly. Create a new standard when predicates, thresholds, or scope change behaviour; update the same record only for non-behavioural metadata edits. Existing checks do not auto-update after standard changes because they keep the cloned logic from creation time.
Last modified on May 11, 2026