Libero LabsLimen
Menu

Use case · CI/CD for Data

Catch breaking changes before they hit production.

Limen tests every proposed change against the rules your data must meet. A change that breaks one is blocked, and the failure names the team that owns the data.

A proposed change adds fulfilled_at at the Cleaned step. Producer guarantees hold at Raw data and are carried through Cleaned. At Combined, fulfilled_at is 22.8% empty where the rule allows 1%, so the consumer requirement at Report would not be met. The change is blocked and sent to the orders team.Producer guaranteesConsumer requirementsPROPOSED CHANGEadd fulfilled_atfulfilled_at 22.8% empty, rule allows 1%Change blockedowner: orders team
The change is stopped before it merges, and the owner knows why.

What goes wrong today

Four problems that ship by default.

  • Schema changes.A column type changes upstream, and every model built on it refreshes with the wrong shape.
  • Null spikes.A field that was 99.7% filled for two years drops to 78% overnight.
  • Broken joins.A key starts producing records with no match on the other side of a join.
  • Missed deadlines.A table arrives late, and the reports that depend on it go out on old data.

How it works

The build fails, not the Monday report.

  1. 01

    State the rules.

    Schema, freshness, null limits, keys, and business rules, kept in code next to the table.

  2. 02

    Run them on every change.

    Proposed changes, scheduled jobs, and deploys all run the same checks.

  3. 03

    Block at the boundary.

    A failing rule blocks the merge or the deploy before anyone downstream sees it.

  4. 04

    Name the owner.

    The failing check names the team that owns the table and the exact rule that broke.

A small first step

One schema. Your recent changes.

We connect to one schema, write starting rules with your team, and replay your recent changes against them. You see which ones would have been stopped.

Book a demo