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

> ## Agent Instructions
> These docs contain multiple Speckle product experiences. For Speckle 2026.9, prefer /next/ pages for the topics and changes they cover. The navigation label Current does not override this version-specific precedence.
> Coverage under /next/ is incremental. Use Current documentation for unchanged topics and when a /next/ page says coverage is unavailable or explicitly refers you to Current. Do not infer a feature was removed from a missing page.
> Read the page-specific documentation status, applicability, affected guidance and replacement links in agent-only content. Impacted, changed and superseded apply only to the stated scope; they do not mean the entire feature is deprecated. Historical connector guides apply only to the legacy connector described.
> Match guidance to the customer's deployment version, model data format and connector. Respect plan, permission and compatibility restrictions. If an unknown version or data format changes the answer, ask a focused clarification; do not infer deployment version from the date alone.

# Data Validation in 2026.9

> What changes for Data Validation after models move to the 2026.9 data format, including related objects, value mapping, calculated values, and the removal of project standards.

Documentation set: Speckle 2026.9. Status: current. Authority: canonical for this version and the coverage on this page.

Applies to version 2026.9, from 2026-09; this is not a rollout date for every deployment.

Authoritative Speckle 2026.9 documentation for the topic covered here. For Speckle 2026.9, prefer this page over conflicting earlier guidance. Follow the linked pages in the other documentation version for unchanged topics and where this page says coverage is not yet available. Respect data-format, deployment, plan, permission, and compatibility limitations stated in the page.

<Note>
  This is 2026.9 documentation. Coverage here is incremental: a page exists only where 2026.9
  differs or is newly documented. For any other topic, switch to **Current** (2026.8 and earlier) in
  the version selector.
</Note>

Use this page when your project is on the 2026.9 data format. Authoring, saving, and result review
still work as in the current product. **Project standards** are not in 2026.9. For check and result
flows that did not change, see [Data Validation](/analytics/data-validation/overview).

This page covers only the differences that change how a check scopes objects, reads properties,
binds a related object (direction, all versus any, multi-hop), maps labels before a comparison,
and tests a calculated value, plus the Project standards change.

## What stays the same

Checks, thresholds, plan caps, BCF export, and result history follow the current guides:

* [Checks](/analytics/data-validation/checks)
* [Viewing Results](/analytics/data-validation/viewing-results)

Authoring still uses a scope and a check. In 2026.9 the editor shows those as short sentences.
A rule can also include a related object.

## Project standards

2026.9 does not include **Project standards**. The Data Validation sidebar shows **Run check** and
**Checks** only. You cannot create, import, or spawn checks from a project standard.

Reuse across the workspace is planned later as a rollup from Checks into workspace standards. That
flow is not available yet. Until it is, author and save checks.

<Warning>
  If your team spent time developing Project standards in the previous Data Validation flow, email
  [hello@speckle.systems](mailto:hello@speckle.systems).
</Warning>

## Default object scope

In the current product, a new check starts with a global filter that keeps connector BIM objects
and drops proxy and geometry noise. In 2026.9, a new check starts with an **empty** global
scope. The version already contains user-facing objects only, so that starting filter is not
needed.

Do not follow the current [Default scope](/analytics/data-validation/checks#default-scope)
guidance on a 2026.9 version. Leave the global scope empty, then narrow with category, type, or
parameter filters in `WHERE` when you need a tighter rule.

<Warning>
  An existing check can return no objects on a 2026.9 version. Preview shows empty counts and an
  empty object table. The stored rule still uses the previous-format object filter. That filter is
  not shown as a control in the 2026.9 check editor, so you cannot clear it in place. Rebuild the
  check: create a new check, run preview, then save.
</Warning>

Unsaved drafts that still carry the old default are cleared when you reopen the editor. Saved
checks keep their stored rules. After save, you can edit name and description only.

## Checks against related objects

In the current product, a rule looks at properties on one object. In 2026.9 you can also check
that object against something it is related to, 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 condition** adds a scope filter above the check. It does not turn the existing check into a
filter.

Rules display as short sentences, for example **category is Doors**. Select a sentence to edit
it.

<Note>
  **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.** Publish a new version after the project uses the 2026.9 data format.
</Note>

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

### When there is no related object

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**), 2026.9 can map each side's raw
labels onto shared values before it compares them. 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.

<Tip>
  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.
</Tip>

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

## 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`. In 2026.9 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.

<Note>
  Computed values are created with Speckle Intelligence, available when your workspace plan includes
  it. On a self-hosted server, it is available only on Speckle Enterprise Server. For deployment
  setup, see [Enterprise license —
  Intelligence](/developers/server/deployment/enterprise-license#optional-intelligence).
</Note>

Describe the calculation to the assistant to create it.

<Steps>
  <Step title="Describe the calculation">
    In the check editor, select **Generate rule**, or ask [Speckle
    Intelligence](/next/analytics/intelligence) in **Chat**. Name the inputs, how to combine them,
    their units, and the threshold.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Save the rule">
    Accept the rule the assistant proposes, then save the check. The rule shows the computed value
    as **Σ** followed by its name.
  </Step>
</Steps>

An example ask:

```text theme={null}
Add a rule: for structural framing, the span-to-depth ratio must be at most 20. Divide Length by the
depth, which is the second number in the type name (300x600 is 300 mm wide and 600 mm deep).
Length is in metres.
```

<Tip>
  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.
</Tip>

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.

<Note>
  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.
</Note>

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.

## Property paths

Always pick property paths from the path picker after a preview model loads. Paths in the current
[Checks](/analytics/data-validation/checks#property-paths) examples, such as
`parameters.Width.value` and `baseline.length`, come from the previous data format and may not
exist on a 2026.9 version.

Typical Revit parameters now sit under `properties.Parameters` (for example type Width under
`properties.Parameters.Type Parameters.Dimensions.Width`). Use the picker for the paths that
exist on your model.

## Versions you can run against

Data Validation preview and saved-check runs need a version in the 2026.9 data format. If preview
does not load, publish a new version after the project has moved to 2026.9. See
[Speckle's data model is changing](/workspaces/data-model-migration).

## FAQ

<AccordionGroup>
  <Accordion title="Where did Project standards go?">
    They are not in 2026.9. Author and save checks instead. A later step is a rollup from Checks
    into workspace standards. That is not available yet. If you already built Project standards,
    email [hello@speckle.systems](mailto:hello@speckle.systems). See [Project
    standards](#project-standards).
  </Accordion>

  <Accordion title="Why does my existing check show 0 objects after the project moves to 2026.9?">
    The saved rule still uses the previous-format object filter. That filter is not shown in the
    2026.9 check editor, and saved checks cannot change rules in place. Create a new check, run
    preview, then save. See [Default object scope](#default-object-scope).
  </Accordion>

  <Accordion title="Should I still drop DataObject to widen scope?">
    No. That step is for the current product. In 2026.9 the object set is already the user-facing
    elements. An empty global scope is the correct starting point. Narrow with category, type, or
    parameter filters in `WHERE` when you need a tighter rule.
  </Accordion>

  <Accordion title="Why is Add related object disabled?">
    The preview version has no relationship data. The tooltip asks you to re-publish with a current
    connector. Publish a new version after the project uses the 2026.9 data format. See [Checks
    against related objects](#checks-against-related-objects).
  </Accordion>

  <Accordion title="Why does a door with no host fail the related-object check?">
    A subject with no related object fails a check that reads that binding. Add a scope condition
    that the related path exists if that case should be not applicable. See [When there is no
    related object](#when-there-is-no-related-object).
  </Accordion>

  <Accordion title="What is the difference between all and any?">
    **all** requires every related object to satisfy the check. **any** requires one. Scope filters
    on related paths still keep a subject when at least one related object matches. See [Direction,
    all versus any, and narrowing](#direction-all-versus-any-and-narrowing).
  </Accordion>

  <Accordion title="How do I check a door against the wall that hosts it?">
    On the door rule, select **Add related object**, choose **Host element**, then compare the
    door's fire rating to the host's fire rating with **Equals property**. Map labels if one side
    uses minutes and the other uses hours. See [Map labels before you
    compare](#map-labels-before-you-compare).
  </Accordion>

  <Accordion title="How do I treat 60 MIN and 1 HR as the same rating?">
    On an **Equals property** comparison, open the comparison control beside the other path. Under
    **This value maps** and **Other value maps**, add a mapping so both labels map to the same
    number, such as `60`. Unmapped values stay as they are. See [Map labels before you
    compare](#map-labels-before-you-compare).
  </Accordion>

  <Accordion title="How do I match Fire Rating on every path it appears?">
    Click the path-matching control until it shows **suffix** (`*.x`), and set the path to **Fire
    Rating**. Every matching value must pass. Click again for regex over the full path. Path
    matching is not available on **Equals property**. See [Match a property wherever it
    sits](#match-a-property-wherever-it-sits).
  </Accordion>

  <Accordion title="Why does an object that has every input still show no value?">
    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](#when-there-is-no-value-or-more-than-one).
  </Accordion>

  <Accordion title="Do I rewrite every property path in every check?">
    Only when a path no longer exists on the new version. Load preview, pick the replacement from
    the path picker, and save a new check. Saved checks cannot change rules in place.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.