Schema compatibility
Field names and physical types are unchanged.
occurred_at: timestamp
Stasrift checks whether declared data meaning changed across versions, even when the schema still passes.
Local CLI · No server · No accounts · Human-reviewed
$ stasrift diff --old v1.yaml --new v2.yaml
INCOMPATIBLE
occurred_at.time_axis
{event_time} → {processing_time}
Reason
Same timestamp shape. Different declared meaning.
Field names and physical types are unchanged.
occurred_at: timestamp
The type stayed the same, but the declared time axis changed.
event_time → processing_time
Read local SQL, contracts, dbt refs, and documentation.
Produce deterministic suggestions, questions, or conflicts.
A human confirms, edits, or skips. Suggestions never write automatically.
Return UNCHANGED, NARROWED, WIDENED, or INCOMPATIBLE.
Install v1.0.0, compare two tiny contracts, then try your own repository. Follow the five-minute guide for environment setup, sample files, and expected results.
$ python -m pip install ./stasrift-1.0.0-py3-none-any.whl
$ stasrift --version
stasrift 1.0.0
Requires Python 3.10 or newer. Download the v1.0.0 wheel from GitHub, then run the install command from your download folder. Stasrift is not yet published to PyPI.
Working with dbt, SQL, ETL, data contracts, or event pipelines? Try Stasrift and tell us whether installation worked, what tooling you use, whether it found anything useful, what it flagged incorrectly or missed, and whether you would run it in CI.
Failed installs and reports of no useful findings are welcome. Share a small sanitized example; GitHub Issues are public.
Stasrift grew from the Jameson Zero Condition: the idea that “unchanged” only has meaning relative to what is being observed and compared.
The software does not claim new science. It turns that discipline into a practical question for data systems: unchanged according to what?