The most expensive place to find a pipeline bug is production. The second most expensive is a shared development cluster at the end of a long job. Emolysis is designed so that the first place a pipeline runs is a golden test on your machine, and so that a pipeline cannot deploy until those tests are green.
What a golden test is
A golden test runs a pipeline on a fixed input and compares its output with a stored expected output, row for row. If anything differs, the test fails. The idea is old and simple. What makes it useful is the choice of inputs.
Each Emolysis template will ship with fixtures designed around its shape's hard cases. The Ingest (batch) test loads three files, one of them malformed. The Incremental append test runs twice with overlapping input. The CDC merge test mixes inserts, updates and deletes, including several changes to one key in one batch. The SCD Type 2 test changes an attribute across three runs. The Backfill test starts with a gap in the middle of the range. The Late-arriving test delivers a fact two days late. The Aggregation / gold test uses input with known totals. The Reverse ETL test pushes the same batch twice and expects nothing to change the second time.
Where they run
On DuckDB, on your machine. A golden test takes seconds and needs no cluster, so it can run on every save rather than once before a release. Platform lint rules will run on every edit, a dry run on every save, and the full golden tests before a deploy. When a test fails, the agent will go back to the template fill, fix it and run the tests again. You will see each attempt.
The same tests will run on pull requests. The planned GitHub App, or a reusable workflow in your own CI, will run lint and golden tests on every change, with the fixtures committed in your repository, and add a cost estimate for your platform. Make those checks required, and green checks will become your deploy gate. The GitHub checks docs describe the planned setup.
Why DuckDB is the judge
A test needs one judge that is fast, deterministic and the same for everyone. DuckDB is all three. The expected outputs are checked against it, and the same transformation will then be translated into your platform's dialect at deploy time. That way the logic will be proven once and carried to each platform, instead of being rewritten and re-proven by hand.
What golden tests do not prove
We want to be clear about the limits. A golden test proves the logic on the cases in its fixtures. It does not prove that your account has permission to write the target table, that the job is fast enough on a billion rows, or that the platform behaves exactly like DuckDB in every corner.
We will handle those in other ways. Each platform profile lists that platform's known traps, such as Unity Catalog permissions or Snowflake's uppercase identifiers, and lint rules will check for them before anything runs. Before we call a template ready on a platform, its cases will also run on that platform. In our own tracking, a template that passes on DuckDB only is yellow, and green means it also passed on the real platform.
Your own tests
The library templates will come with their fixtures. For your pipelines, Emolysis will add fixtures to the project's tests/ folder, and you will be able to add your own cases, such as the row that broke production last quarter. Keep them synthetic: they will live in your repository and run in CI. The tutorial preview walks through a first golden test.
The rule
Red will go back to the template. Green will be able to deploy. Nothing else will reach your platform. It is a simple rule, and the point of building Emolysis around templates and a fast local loop is to make it a rule that nobody needs to bend.
Emolysis is in private development. Nothing described here is released yet.