---
title: "Understanding data quality checks in LUSID"
slug: "understanding-data-quality-checks-in-lusid"
updated: 2026-07-30T09:34:20Z
published: 2026-07-30T09:34:20Z
canonical: "support.lusid.com/understanding-data-quality-checks-in-lusid"
---

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

# Understanding data quality checks in LUSID

This article explains how data quality (DQ) checks work in LUSID, including the key components to configure a check, and the types of results you can expect from a run.

## Configuring a check definition

Each DQ check in LUSID consists of the following key components:

### Check definition

A check definition is a LUSID entity identified by a unique scope and code. It specifies:

- The type of data the check applies to
- One or more rulesets containing rules that define your validation logic

### Ruleset

A ruleset is a collection of rules with a filter that allows you to segregate the data being checked.

Each ruleset contains:

- One or more rules
- Optionally, a [filter](/v1/docs/filtering-information-retrieved-from-lusid) to specify which items the ruleset applies to

For example, to apply a set of rules only to equity instruments, you could set the following filter:

```json
"ruleSetFilter": "instrumentDefinition.instrumentType eq 'Equity'"
```

For custom entities, rules and filters can also reference native fields on the entity type directly, using `fields[fieldName]` syntax.

### Rule

A rule is a formula that LUSID checks entities against. Each rule contains:

- A formula that uses [derived property syntax](/v1/docs/derivation-formulas-part-1-operations-and-allowed-values) to determine a value of `true` or `false` for the data check
- A numeric severity level indicating the importance of the rule

For example, to check an entity is decorated with the `Instrument/industry/nace` property, you could set the following formula:

```json
"ruleFormula": "Properties[Instrument/industry/nace] exists"
```

## Running a DQ check

Once defined, you can run checks via workers in the [Workflow Service](/v1/docs/workflow-service), or via API. When running a check, you must provide:

- The check definition scope and code
- Details of the data to be checked, for example:

> [!NOTE]
> Note
> 
> You must also provide a `scope` for instrument and portfolio checks.
  - An `asAtModifiedSince` date, so LUSID only checks entities that have been modified since a particular date (such as the previous check run)
  - A selector attribute and value to use as an explicit “check me“ tag, such as a telemetry property added during an integration run
  - A preferred identifier to return for instruments that breach rules
- A limit for the number of breaches per rule to prevent the inefficency of checking every entity for a widespread issue, for example if a property is missing from the latest integration run for every instrument

> [!NOTE]
> Note
> 
> Above the limit, further breaches are grouped into a single result.

**Worker in the Workflow Service**

LUSID provides a pre-built DQ check [worker](/v1/docs/how-do-i-create-a-task-definition) that you can use in your task definitions and map the results to exception tasks for further investigation.

**API**

[Follow our tutorials on running a simple DQ check using the CheckDefinitions API.](/v1/docs/how-do-i-create-and-run-a-data-quality-check) Note that running checks via the API is only recommended for testing a DQ check before including it in your workflow.

**Web app**

*Coming soon.*

## Understanding DQ check results

DQ checks return four types of results:

| Result type | Description | LUSID returns… | Example |
| --- | --- | --- | --- |
| **Ruleset invalid** | Returned if LUSID could not evaluate a ruleset. | One result per invalid ruleset | A property key referenced in the filter string was deleted. |
| **Rule invalid** | Returned if LUSID could not evaluate an individual rule within a valid ruleset. | One result per invalid rule | A property key referenced in the rule formula was deleted. |
| **Rule breached** | This is the primary expected result for a breach (that is, the rule formula evaluates to false). | One result per item in the dataset that breaches a rule | An instrument does not have a property required by the check. |
| **Rule breaches over limit** | Returned if the number of breaches for any rule exceeds the limit specified in the run request. | One summary result for all breaches exceeding the limit | A property required by the check is missing for more than 100 instruments. |

Units of functionality in the Workflow Service which can access LUSID data. Called by tasks, workers take input parameters mapped from the fields of a task, and return results which can be mapped to a task definition. Worker status can be used to trigger a parent task automatically.