Runnable examples

Start with the fulfillment example from the homepage, or choose investment reporting below. Each download includes source data, complete models, SQL, expected answers and verification notes. The other examples explore specific modeling and execution behaviors.

The bundles contain data and definitions, not binaries. Request evaluation access for a matching development engine and Crossfield extension before running them. Crossfield will ship in an upcoming Haybarn release; see release details and build requirements. These local examples need no source checkout, Python package or API account.

Run a bundle

For the fulfillment example, download fulfillment.zip, extract it and start a fresh CLI from the extracted fulfillment directory. Replace both build paths:

unzip fulfillment.zip
cd fulfillment
/path/to/matched/haybarn -unsigned -init /dev/null :memory: \
  -cmd "LOAD '/absolute/path/to/crossfield.duckdb_extension';" \
  < session.sql

For an interactive session, omit the input redirection and run:

.bail on
.read setup.sql
.read run.sql
.read explain.sql

For another bundle, substitute its archive and extracted directory and use the CLI from its recorded build; earlier binaries may be named duckdb. Relative paths resolve from the extracted directory. Run setup once per fresh connection. Applications can execute the SQL in setup and run files; .read and .bail are CLI commands.

Complete orders, delivered on time

Download fulfillment.zip · walkthrough · setup · verification

Four eligible orders show why on-time shipments and on-time complete orders are different measures. Incomplete orders remain in the denominator; canceled orders and other due dates are excluded. Source preparation creates one stored fact per order.

The current and revised models read the same source facts. The source cutoff is fixed; this fixture does not automatically refresh order facts.

Portfolio exposure and execution price

Download finance.zip · walkthrough · setup · verification

Synthetic USD cash equities demonstrate gross versus net exposure, quantity-weighted execution price, issuer limits, and a proposed change to the included trading books. The source rows include an older valuation date and a void fill to check the population rules.

The fulfillment and trading bundles use the newer shared-engine pin recorded in their verification files. The four bundles below retain their separately recorded build evidence.

Retail reporting

Download retail.zip · setup · queries · README

The fictional shop has 525 orders, 834 receipt lines and two stores. The bundle includes all five frozen CSVs, their license/notices, source model files and two revision packages. Meet the tables before reading the model.

This is a small fixed customer panel, not the entire upstream Jaffle dataset. Preserve its notices when redistributing it. Read the captured expanded SQL for the store report alongside the retail walkthrough.

Ossie dataset metrics

Download ossie.zip · model · queries

Orders and returns each define a local metric named revenue. The orders model’s logical amount doubles the physical amount; returns uses its own amount directly.

SELECT orders.revenue AS sales, returns.revenue AS refunds
FROM SEMANTIC local_metrics.scoped_sales;
-- 84 | 7

The answer follows 2 × (10 + 20 + 5 + 7) = 84 and 3 + 4 = 7; the NULL order amount is ignored by SUM. The full regression model also contains explicitly Crossfield-specific definitions. Read the Ossie boundary before treating it as a portable model.

Measurement intervals

Download measurements.zip · model · queries

Four rows demonstrate two locations, a midnight boundary and unequal measurement durations. ICU is required. Expected rainfall is A/January 1: 5 mm, A/January 2: 7 mm, B/January 1: 11 mm. A’s January 2 duration-weighted flux is 40 W/m².

Run reject.sql separately after setup to see an interval mean rejected without its approved reduction. The measurement guide explains why this is different from grouping timestamp labels. This local fixture does not use or qualify a live weather worker.

Model-owned pipeline

Download pipelines.zip · model · queries

One canonical model exposes a direct input and an approved driver/stage pipeline. The direct call arithmetic.numbers(5) and equivalent named stop => 5 return count 5, sum 10. The alternative seed => 4 executes the model-owned dependency and returns count 3, sum 6.

The retrieval guide explains those stages and distinguishes this native pipeline from worker-internal API traversal.

Discovery and repair

The AI agent guide uses the retail model. Its metadata queries discover the attached revisions, metric meanings and compatible dimensions before querying. In strict mode, SUM(subtotal) against warehouse.orders is rejected; the approved before-tax revenue is 6355.00. The tax-inclusive order_total is 6730.75 and answers a different question.

The native discovery and repair capture includes the actual structured rejection and approved results. It is an engine session, not a claim about a particular AI agent framework.

What the evidence establishes

Expected answers are specified from the fixture values independently of generated SQL. Native execution of the extracted downloads is checked on the maintained EC2 build with the optimizer enabled and disabled. Build and verification details distinguish fresh execution from earlier integration evidence.

The bundles record their source files and hashes. Passing these bounded cases does not establish arbitrary connector compatibility, a current source snapshot, or the correctness of a new business definition. Add numerical and rejection cases for your workload.