Compared to how you build data products today
Nothing on this list is wrong, and PYX replaces almost none of it. Each one holds a single link of a chain nobody holds end to end: the sentence someone wrote, the model that encoded it, the control that checked it, the number on the page. The lifecycle is that chain, made into one artifact.
| What you have | What it does | What the lifecycle does instead |
|---|---|---|
| The spec document + modelling workshop | Meaning reconstructed from memory in a room, written down once, and out of date by the time code exists. | The requirement stays the artifact, grilled into typed claims and blocking questions that gate progress until they are answered. |
| Hand-built data products | One to two quarters each, because meaning is re-derived by hand at every hand-off and retyped in a different notation. | One reviewed model generates the tables, pipelines, controls, metric and dashboard together. |
| AI copilots writing SQL (Genie, agent notebooks…) | Answers fast, from a prompt, producing output nobody can review at the rate it arrives. | AI drafts one level up: a typed, diffable model a person rules on, and the code is deterministic from what was approved. |
| dbt / transformation frameworks | Excellent at running the transformation you already decided on. Silent on how it was decided, or whether it still answers the question. | Sits upstream of it: the decisions are the artifact, and your transformation layer is one of the things generated from them. |
| Unity Catalog metric views | A shared definition that still names physical tables. | Concepts bind late, so meaning survives the table moving. UC Metrics is a deployment target, not a competitor. |
| Catalogue / governance suites (Collibra, Alation, Atlan) | Describes assets, owners and glossary terms. Documentation about the estate. | Holds the executable chain: requirement → concept → control → verdict → evidence. |
| Data observability (Monte Carlo, Anomalo…) | Detects that something changed, statistically, after it changed. | Rules on whether a stated requirement still holds, and gates release on the answer. |
| Consulting migration assurance | A reconciliation pack, correct on the day it was signed and decaying from that afternoon. | The same rigour, generated from the model, versioned with it and re-runnable every night afterwards. |
PYX is not a replacement for your warehouse, your transformation layer, your catalogue or your orchestrator. It sits upstream of them and holds the decisions they all assume somebody already made.
What we refuse to do
We do not guess and call it a binding
An inference without a human review is a rule nobody agreed to, gating publication. Drafts, confidence and a reason, always.
We do not hide an engine gap
If a dialect cannot execute something, generate says so and writes it into the execution README. A silent gap is worse than a missing feature.
We do not turn a limitation into a blocker
Only unanswered blocking questions refuse a build. Make honest documentation the thing that stops work, and people stop documenting.
We do not cry wolf
A lost inner join blocks. A lost left join degrades. A tool that calls everything critical gets switched off in a fortnight.
We do not let an agent write the number
AI drafts the model, because a model is small enough to review honestly. It does not get a free hand on the SQL behind a regulated figure.
We do not sell speed as a trade against control
The model that compresses the build is the model the controls bind to. If the acceleration cost you the gate, it was not worth having.
The fastest way to test the claim is on a requirement you already have
Tell us what you're trying to build or improve. We can talk through whether PYX is a fit.