Availability and limits

Crossfield will ship as part of Haybarn, Query Farm’s DuckDB distribution, with the matching engine support and extension. Until that release, these guides use development builds and recorded example results. Contact Query.Farm for evaluation access.

Match the engine and extension

The examples have separately recorded build qualifications:

• Trading and fulfillment examples: separately checked on Linux ARM64 against Query Farm’s shared engine revision 6d01968ba1ee4973483e3e67c9a1f58864a1ea9f, based on DuckDB’s 2.0 release-base revision d54cbbe3df17e8e5ce68312f483b4155836112aa. The CLI is named haybarn. The trading verification record identifies its engine and extension artifacts; the fulfillment record records its separate native SQL and CLI checks.
• Earlier retail, Ossie, measurement, and pipeline bundles: retain their recorded Linux ARM64 qualification against DuckDB’s pinned release base plus the eight-patch Crossfield series. Those bundles were not requalified by the trading or fulfillment checks.

Keep the CLI, shared engine library, Crossfield extension and crossfield-build.json manifest from the same build together. Matching a base DuckDB version string is insufficient: source, native interfaces, compiler ABI and platform must agree. Portable packages also declare the engine source contract they require.

The trading walkthrough and retail walkthrough load their matching extensions by path. Their downloads contain data and models, not binaries. Use the recorded development artifacts for these examples until the Crossfield-enabled Haybarn release is available.

Why Crossfield patches DuckDB

DuckDB’s grammar extensions supply the syntax mechanism. Crossfield also needs to preserve semantic intent across preparation and execution, validate the objects selected during binding, and reject disallowed operations before binding callbacks can run. A parser rewrite alone does not cover those boundaries.

The core patches provide generic extension hooks and binding fixes. Model intake, metric definitions, relationships, approval policy, semantic compilation, and repair guidance remain in Crossfield. DuckDB retains binding, optimization, execution, transactions, and storage.

The engine integration page explains the eight-patch series used for the earlier example profile, prepared-statement revalidation and possible uses by other extensions. The patch contract lists the exact series. Several hooks change native interfaces, so the engine, extension and other native modules must use compatible builds.

Semantic enforcement governs SQL through supported entry points. It is not a sandbox for untrusted native extensions; the host-control boundary is described below.

Implemented profiles

The wider implementation includes these capabilities within declared model contracts. Reference paths below are in the Crossfield checkout.

Capability	Scope and boundary	Checkout reference
Calendar, temporal and statistical metrics	Named calendars, historical relationships, exact percentiles and approved windows retain required grain, population and rollup rules.	docs/WINDOWS.md, docs/ALIGNED_PERIODS.md, docs/TEMPORAL_RELATIONSHIPS.md, docs/SUPPORTED_SQL.md
LIST, ARRAY and STRUCT data	Typed detail, approved member/index selection and model-owned expansion preserve declared grain; arbitrary caller row expansion remains outside governed SQL.	docs/MODEL_FORMAT.md
Typed model-owned pipelines	Callable scopes and approved retrieval/conversion stages retain input and provider contracts; native overloads dispatch on names and types.	docs/MODEL_FORMAT.md, docs/INVOCATION_DESIGN.md
Validation and versioned packages	Native authoring/binding diagnostics, a GitHub Action adapter and revision-aware packages. Binding validation is not numerical acceptance; a qualified local validator bundle is required until publication.	actions/validate-model/README.md, docs/CATALOG_INTEGRATION.md

Jaffle’s independent regression expectations cover aggregation, detail, reports, discovery, strict rejection, explanation and attachment replacement. This frozen fixture does not establish arbitrary SQL/connector compatibility or production readiness.

Attachment checks dependencies and report schemas, not numerical answers or business approval authority. Source rows remain live. REBIND 'compatible' permits validated compatible changes; REBIND 'pinned' rejects schema/object changes.

Host-controlled sessions

Unsealed connections can change crossfield_mode. Attached objects retain validation in off; setting strict alone does not create an authentication or tenant boundary.

A trusted native host can seal a strict connection to an authenticated principal and independently approved attachment fingerprints. This requires REBIND 'pinned' and the matching host API.

Sealed SQL cannot reset controls, change USE, or replace the attachment. A new principal or model requires a replacement connection. The host supplies authentication, source permissions and native/process isolation; privileged native code remains under host control. Catalog names alone do not isolate tenants. See docs/HOST_SESSIONS.md.

Optional retrieval and current limits

Query Farm’s products have distinct roles. Haybarn will distribute Crossfield with its matching DuckDB engine. Orchard is for connector discovery; a listing does not qualify its semantic model. Rowfence controls VGI row, column and function access; any combined deployment needs its own integration qualification. Cupola and Grainlift are optional adjacent tools, not prerequisites for this walkthrough. The current native example checks do not establish browser/WASM support.

Jaffle needs no VGI worker. Provider-backed models can use separately configured retrieval sources, including VGI invocation profiles. Provider modules must match the engine; worker, transport and credential setup belong to each integration.

The Open-Meteo worker check recorded for these guides used a worker requiring VGI protocol 2.2.0 and a native client advertising 2.1.0; that pair failed before semantic attachment. Native interval checks and local measurement examples are separate passing evidence. Recheck the actual engine, client and worker combination when qualifying a newer build.

Current VGI examples use a partial matching invocation build. They do not establish complete VGI API or transport compatibility. Independent connectors also do not imply a globally atomic snapshot, and a late provider error may follow streamed rows.

The documented query profiles do not include remote model services, automatic dependency attachment, SQL definition authoring, bridge allocation or nested report definitions. Named reports execute live; materialized reports are not implemented. Strict business queries use one attachment; cross-revision reconciliation belongs in ordinary composition around governed results.