OpenLineage to Blindata quality

Producers that run tests or measure their data can say so in OpenLineage events. The connector brings this into Blindata’s data quality and data profiling modules:

In the events	In Blindata
dataQualityAssertions facet of an input dataset	A quality check per dataset, assertion and column, with a result per run.
test run facet	A quality check on the job entity, per test name, with a result per run.
dataQualityMetrics facet (input or dataset)	Profiling metric records: row count, bytes, file count, last update, and per column null count, distinct count, sum, count, min, max and quantiles.
inputStatistics and outputStatistics facets	Profiling metric records of the run: rows, bytes and files read or written.

This is on by default. quality.enabled turns off everything on this page, and quality.metricsEnabled turns off only the metric records.

Results come only from runs. JobEvents and DatasetEvents describe design time and carry no results: a repository that publishes only JobEvents should set quality.enabled to false. Results and records are published from completed runs; failed runs also publish assertion and test results (a failure is a result), and aborted runs publish nothing.

Checks

All checks of a job definition are in one quality suite, with the code openlineage:<job definition uuid> unless you set quality.suiteCode, on the OpenLineage System.

Assertions

Field	Value
Check	One per dataset, per assertion name (the assertion type when it has no name) and per column.
Code	ol:<dataset namespace>/<dataset name>:<assertion name or type>[:<column>]. Codes longer than 255 characters are cut and end with a hash.
Linked to	The entity of the dataset. The column is kept as the check property openLineageColumn.
Properties	openLineageKind (assertion), openLineageDataset, openLineageAssertionType, openLineageColumn.

An assertion on a dataset that is not catalogued makes no check, and the run reports TARGET_NOT_CATALOGUED.

Tests

A test run facet is a check on the job entity, one per test name, with the code ol:<job scope>:test:<test name>. A skipped test makes neither a check nor a result. A job without an entity (processLayer false) makes no test check.

Results

One result is written per check and run.

Event	Result
Assertion with success: true	Pass: 0 failures out of 1.
Assertion with success: false	Fail: 1 failure out of 1. With severity: warn the failure is a warning, not a failure.
Test that passed or failed	Pass or fail.

The description of the result carries the run id, and the expected and actual values and the content of the assertion when the producer sent them. Retrying the same run does not duplicate results: a run is published once per check, and a run enters the record of published runs only when all its results were accepted, so a partial upload is retried.

Metrics

Metric records are written on a profiling monitor per entity, named OpenLineage. The timestamp of a record is the captureDate of the facet when it has one, otherwise the event time of the run. A run whose records were already uploaded adds none.

Facet	Metric codes
dataQualityMetrics	rowCount, bytes, fileCount, lastUpdated; per column nullCount, distinctCount, sum, count, min, max and quantile_<q>.
inputStatistics	rowsRead, bytesRead, filesRead, and extra metrics of the producer (for example Iceberg scan reports) as inputExtra_<key>.
outputStatistics	rowsWritten, bytesWritten, filesWritten, and extra metrics (for example Iceberg commit reports) as outputExtra_<key>.

The facets are recognized by their schema URL, so a producer that publishes outputStatistics under another key (the Redshift Data provider uses stats) is read too.

Ownership and edits

The checks, the suite and the records of an OpenLineage job definition are managed by the agent. A check code that already belongs to a check of another suite is never overwritten: the agent reports a conflict for it. The agent also keeps, in the suite, disabled checks named ol-ledger:… that record which runs it already published: do not delete or enable them, or a retried run would publish its results again.

When a snapshot removes a job , the agent disables the checks of that job (they are few, and their history is kept). It never deletes quality checks or results.

Permissions

Quality results and profiling records are written by the user of the job’s BLINDATA connection (Who writes to Blindata ), which needs QUALITY_EDITOR and the permissions to upload profiling metric records.

Updated on 04 Nov 2026