> ## Documentation Index
> Fetch the complete documentation index at: https://docs.speckle.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# Standards

> Create reusable Standards for Data Validation and apply them across checks.

**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.

<Info>
  Standards compile to Speckle `WHERE` / `CHECK` definitions when spawning checks—they
  are not a separate DSL from Data Validation authoring.
</Info>

## 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](/analytics/data-validation/checks#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

<Steps>
  <Step title="Create or import your standard">
    Same authoring loop as checks, or ingest IDS / COBie / Speckle—see [Rule structure
    in checks](/analytics/data-validation/checks#rule-structure-in-checks).
  </Step>

  <Step title="Refine rule logic">
    Lock scope, predicates, severities, and copy before clones ship.
  </Step>

  <Step title="Create checks from standard">
    Spawn checks with per-check models and triggers. Read runs on [Viewing
    Results](/analytics/data-validation/viewing-results). Standard-card **Run check**
    jumps into [Checks](/analytics/data-validation/checks) authoring.
  </Step>
</Steps>

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.