How it compares

Rules catch what you predicted. Receipts catch what changed.

Q: How is Tamper Signal different from Great Expectations, Pandera, or dbt tests?

Great Expectations, Pandera, and dbt tests check data against rules you write, so they catch the failures you predicted. Tamper Signal records a signed receipt at every pipeline stage (a fingerprint of the input, the code, and the output, plus control totals) and proves the dashboard's data descends unchanged from the source export. It catches changes nobody wrote a rule for, but it cannot tell you a rule was broken. The two are complementary.

Q: Is Tamper Signal a data lineage tool like OpenLineage?

No. OpenLineage is a standard for recording which jobs read and wrote which datasets, as metadata sent to a lineage backend. Tamper Signal fingerprints and signs the data itself at each stage, as plain files next to your pipeline, so it can show that a value changed and at which link. It needs no server, catalog, or warehouse.

Great Expectations, Pandera, and dbt tests check your data against rules you write. Tamper Signal signs a receipt at every pipeline stage and proves the numbers on your dashboard descend unchanged from the source export. Most pipelines that last long enough want both: rules for the failures you can picture, receipts for the ones you can't.

The one claim we make

It can't tell you the data is right, but it can prove nobody changed it.

Side by side

Tool	Question it answers	What it needs	Misses by design
Tamper Signal	Does the data the dashboard reads descend, unchanged, from the source export? If not, at which link, and how much moved?	`pip` or `npm install`. Signed receipts are plain files next to your pipeline.	Whether the source is right, and whether a wrapped step's logic is right. It records what each step did; it doesn't judge it.
Great Expectations	Does this data meet the expectations I declared?	A Python environment and an expectation suite per dataset; runs against pandas, Spark, or SQL.	Failures nobody wrote an expectation for, and changes between steps that still pass every expectation.
Pandera	Does this DataFrame match its schema and checks?	A Python library and a schema per frame.	The same as any rule checker: a hand edit that keeps the schema valid passes.
dbt tests	Do these models satisfy the tests I wrote (unique, not null, relationships, custom SQL)?	A dbt project on a SQL database or warehouse.	Anything outside the warehouse, like the spreadsheet export before it and the dashboard file after it.
OpenLineage	Which jobs read and wrote which datasets?	Integrations that emit lineage events, and a backend (such as Marquez) to collect them.	It records metadata about runs, not a signed fingerprint of the rows, so it isn't built to show that a value changed.
in-toto / SLSA	Was this software artifact built by the expected steps, from the expected inputs?	Signed attestations from each step of a build or supply chain.	Tabular meaning. File hashes change when the same rows are re-saved in another format, and there are no control totals to say how much moved.
Sigstore	Who signed this, and when did it exist?	Keyless signing and a public transparency log.	Nothing to compare: it's infrastructure. Tamper Signal can anchor a chain in Sigstore's log (`tamper-signal anchor`).

The other tools get one-line summaries here; their own docs have the specifics. If something is out of date, open an issue and we'll fix it.

When to use which

Use Tamper Signal when

The pipeline is small and file-based: an export, a few Python or JavaScript transforms, a dashboard. No warehouse, no orchestrator, no catalog.
An AI assistant wrote the transforms, so there are behaviors nobody pictured and nobody wrote a rule for.
Someone downstream (a client, a boss, an auditor) needs to check that the numbers weren't changed along the way, by running one command or by looking at a light on the dashboard.

Use a rule checker (Great Expectations, Pandera, dbt tests) when

You know the rules the data must satisfy: no nulls here, unique keys there, values within a range.
You want the pipeline to stop on bad data, not just record what happened.

Use OpenLineage when

You run many jobs on an orchestrator or warehouse and need a map of which job touched which dataset, across teams.

Use in-toto and SLSA when

The thing you're protecting is software: builds, packages, container images.

Using them together

They don't overlap much, so they stack. A Pandera schema inside a wrapped step still raises on bad data, and the step's receipt still records what went in and what came out. The receipt chain covers the parts a warehouse tool can't see: the spreadsheet export before the pipeline, and the file the dashboard actually reads after it. tamper-signal verify --data dashboard.csv checks that last file against the final receipt.

What Tamper Signal can't catch

A wrong source. If the export was wrong when it was signed, the chain verifies green. Continuity, not correctness.
Wrong logic in a wrapped step. A step that drops rows is signed like any other. Its receipt records the row counts and totals in and out, so the drop is visible, and --warn-drift turns any totals movement into a yellow caveat. What turns the light red is data that changed between signed steps, or after the last one.
Stages you don't wrap. An unwrapped stage isn't attested. The next wrapped stage refuses input that doesn't descend from the chain tail, and verify --data checks the file the dashboard reads against the final receipt; skip both and nothing links the dashboard to the export.
Whoever holds the key. The key holder can re-sign a fresh chain. Anchoring in the Sigstore transparency log proves a chain existed at a point in time.

Questions

How is Tamper Signal different from Great Expectations, Pandera, or dbt tests?

Those check data against rules you write, so they catch the failures you predicted. Tamper Signal records a signed receipt at every stage (a fingerprint of the input, the code, and the output, plus control totals) and proves the dashboard's data descends unchanged from the source export. It catches changes nobody wrote a rule for, but it can't tell you a rule was broken.

Is Tamper Signal a data lineage tool like OpenLineage?

No. OpenLineage records which jobs read and wrote which datasets, as metadata sent to a lineage backend. Tamper Signal fingerprints and signs the data itself at each stage, as plain files next to your pipeline, so it can show that a value changed and at which link. It needs no server, catalog, or warehouse.

Is Tamper Signal in-toto for data?

Close in spirit. in-toto signs metadata for each step of a software supply chain, hashing the files each step consumed and produced. Tamper Signal applies the idea to tabular data, with a format-agnostic semantic hash (an xlsx ingest verifies against a CSV copy of the same rows) and human-legible control totals, so a broken link reports how much moved, not only that bytes differ.

Is it a blockchain?

No. It's a hash chain: signed files on disk, linked because each stage's input fingerprint must match the previous stage's output. No consensus, no network, no tokens. More in the FAQ.

Try it

See every surface running on a real receipt chain in your browser, no install: the live demo. Or pip install tamper-signal, then tamper-signal demo. Next: the quickstart, or the source on GitHub.

Last updated September 26, 2026.