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
Imports land under Project standards with no extra publish step. Always rerun preview on a representative revision after import, then tune predicates if needed—see Predicates and matching.IDS
IFC-aligned facets import into standard rules, then open in the same editor for preview and adjustment. Most facets map to Exists, Equals, In list, or Between. IDSxs:pattern values often land as Contains rather than full regex—verify naming rules
after import. Advanced applicability or property mappings may need manual fixes before you
spawn checks.
COBie
Worksheet fields map into rules under project standards after import. Typical outcomes are sheet-scoped Exists checks and pick-list In list assertions. Optional fields often arrive asinfo severity so they do not drive the overall score. Unusual columns or
macro-heavy sheets can lose fidelity—verify property paths, severities, and messages before
spawning checks.
Speckle
JSON, TSV, or CSV exports from dashboards and related tooling import as standards entries. Supported dashboards predicates map into Data Validation operators; unsupported negation conditions (for example not exists, not in list, does not contain) are skipped. Dashboard warning severity is coerced toinfo. Rows with widget-specific semantics may still
need rewrite into explicit WHERE / CHECK logic.
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.
Best practices
Use one naming convention such asTopic-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.