Crossfield by Query.Farm

Spend less time
reconciling reports.

Give teams and AI agents shared definitions to work from.

Crossfield keeps business calculations consistent as people ask new questions. Define which records count, how metrics are calculated, and which operations are allowed—then reuse those rules through SQL.

A semantic layer inside DuckDB.

See a business example Read the documentation →

Coming in Haybarn Crossfield will ship as part of Query Farm’s DuckDB distribution. Request evaluation access → Release details →

Many sources.Shared definitions.New questions.

You built the data platform. The answers still differ.

The systems are connected and teams can access the data. But a dashboard, a SQL report and an AI-generated analysis can still interpret the same business question differently.

More people and AI agents can now generate queries. Unless the reporting rules are shared, each new query can introduce another version of the business logic.

The meeting starts with a reconciliation.
Two reports disagree. The team has to untangle who counted what before discussing what to do.
The SQL runs and returns rows, but it does not answer the business question.
An analyst or AI agent may use a plausible calculation while omitting the agreed cancellation rule or selecting the wrong reporting date. Successful execution does not establish that the query measures what the business intended.
Changing a reporting rule can improve the reported result without improving business performance.
Using revised delivery promises can raise the reported on-time rate even when the delivery records are unchanged. Readers need to see that definition change before interpreting the higher rate as better service.

See how teams define a business measure and reuse it across reports.

Choose order fulfillment or investment reporting. Each example shows how different calculations or reporting scopes produce different answers, then follows the team’s chosen definition into a reusable model. Both examples use synthetic data with independently checked results.

The order fulfillment walkthrough is shown below. You can also read the investment reporting example.

Order fulfillment · Illustrative dataLink to this scenario

Three reports use the same “on-time delivery” label for different measures.

The warehouse reports on individual shipments. Customer service looks at complete orders. Another report uses delivery promises that were revised after the order was placed. Each measure can serve a legitimate reporting purpose. Using the same label for all three obscures which question each report answers.

Before deciding whether service is improving, the team has to establish what each number means: which deliveries count, whether incomplete orders are included, and which promise date applies.

What each report means

Shipment dashboard: Delivered shipments that arrived by the original promise. Items still undelivered are absent.; 83.3%
Customer service report: Complete orders delivered by the original promise. Incomplete orders stay in the denominator.; 50%
Revised-promise report: The same orders, evaluated against revised delivery promises.; 75%

The same synthetic source snapshot, interpreted three ways. Five of six delivered shipments were on time. Of four eligible orders, two were complete by the original promise and three by revised promises.

With Crossfield, agree on the definition and reuse it.

The business chooses complete orders delivered by the original promise as its customer-service measure. The model excludes canceled orders and keeps incomplete orders in the eligible population.

50%Complete orders delivered by the original promise

Analysts and AI agents can query that named metric by region or overall without reconstructing its rules. A proposed change to revised promises is reviewed separately, so a change in the definition is visible before it changes reporting.

The business chooses the meaning. Crossfield makes its calculation reusable and validates queries against the model’s rules.

Inspect the source records behind these figures

Illustrative fulfillment data Four orders. Two fulfilled on time.

All 4 orders were due Jan 31. Snapshot: end of Feb 3. Each shipment carries one item.

A100
Jan 30On time Jan 31On time

Complete on time 2 / 2 items delivered
A101
Jan 31On time Feb 2Late

Complete late 2 / 2 items delivered
A102
Jan 31On time PendingUndelivered

Incomplete 1 / 2 items delivered
A103
Jan 31On time

Complete on time 1 / 1 item delivered

Delivered shipments on time 83.3% 5 on time ÷ 6 delivered

This counts shipments and leaves the undelivered item out.

Orders on time 50% 2 complete on time ÷ 4 eligible

Every eligible order counts, including the incomplete one.

An order counts as on time only when every item arrives by its original Jan 31 promise. Each segment above represents one shipment or one order.

Synthetic orders originally due January 31, observed through February 3. The setup prepares one stored fact per order from its shipments. The model owns eligibility and the complete, on-time calculation. Read the full source setup →

Investment reporting · Illustrative dataLink to this scenario

Three reports use the same “exposure” label for different calculations and portfolio scopes.

One portfolio report adds the absolute values of long and short positions. Another lets them offset. A third includes an additional trading book. Labeling all three “exposure” hides decisions that materially change the answer.

The team must reconcile the calculation, included positions and valuation date before using the numbers. An AI agent querying the same position records also needs those decisions made explicit.

What each report means

Gross exposure, current books: Add absolute position values in Book A and Book B at the January 31 close.; $23m
Net exposure, current books: Add signed values, allowing the long and short positions to offset.; $7m
Gross exposure, broader scope: Use the gross calculation and also include the Expansion book.; $28m

The same synthetic January 31 USD position records. Book A and Book B contain Atlas positions of +$12m and −$8m, plus a $3m Boreal position. The Expansion book adds $5m.

With Crossfield, agree on the definition and reuse it.

For this report, the business chooses gross exposure for Book A and Book B at the January 31 close. The model names gross and net separately and makes the included books and date explicit.

$23mGross exposure for the approved reporting scope

Reporting teams and AI agents reuse the same measure by issuer, by book or overall. Net exposure remains a distinct valid metric. A proposed scope expansion can be compared with the current model before it reaches reporting.

The business chooses the meaning. Crossfield makes its calculation reusable and validates queries against the model’s rules.

Inspect the source records behind these figures

This close-up shows the two Atlas positions. The current portfolio also includes a $3 million Boreal position; the proposed scope adds the $5 million Expansion book.

Illustrative cash-equity positions The same positions. Two valid measures.

Both books hold the same issuer’s common shares, valued at the same USD closing price.

Book ALong position

+$12m

Book BShort position

−$8m

Gross exposure $20m |+$12m| + |−$8m|

Add the absolute position values. Both books contribute to the total.

Net exposure $4m +$12m − $8m

Add the signed position values. The long and short positions offset.

Both bars use a $20m scale. All amounts are USD.

Gross and net answer different questions. Net exposure describes the signed balance of these positions; it is not a measure of total risk.

Synthetic cash equities already valued in USD. This example covers reporting definitions, not pricing, FX conversion, derivatives netting, or a complete risk calculation. Read the full source setup →

Put the definition in the model. Reuse it in each query.

A semantic layer is a shared specification for business metrics and the rules for using them.

Crossfield makes that specification executable in DuckDB, so reporting definitions can be maintained and reviewed independently of individual reports.

Define the reporting rules.
Specify the calculations, which records count, and how sources can be combined.
Attach the model.
Make those definitions a named catalog alongside the data in your DuckDB connection.
Query and validate.
Select metrics and dimensions. Crossfield checks the request; DuckDB executes it.

The model retains the reporting rules as users ask different questions. Optional strict mode rejects supported queries that bypass those rules.

Attach a model and query its business definitions.

The model becomes a named catalog alongside your data. Attach it as operations, then select its metrics with FROM SEMANTIC. BINDINGS maps the model’s source to your existing warehouse catalog.

SQL · Attach and query the model

ATTACH 'fulfillment-current.package.json' AS operations (
    TYPE crossfield,
    BINDINGS '{"warehouse":"warehouse"}'
);

SELECT region, eligible_orders, on_time_orders, on_time_percent
FROM SEMANTIC operations.fulfillment
GROUP BY region
ORDER BY region;

The runnable guide includes the source data, model package and expected results. Its setup already performs the attachment shown here.

Inspect how DuckDB executes this example.

Review how each result is calculated.

The generated SQL shows the original January 31 promise date and cancellation filter, then checks that every unit arrived by the promised date. Incomplete orders contribute to the eligible count, without contributing to the on-time count.

EXPLAIN (SEMANTIC) shows the selected definitions and generated SQL without executing the report or calling providers.

Reporting population4 eligible orders

Originally due January 31. Canceled orders excluded.

Approved calculation2 delivered in full, on time

Count incomplete orders in the denominator.

2 ÷ 4 × 100 = 50%

SQL · Explain the report

EXPLAIN (SEMANTIC)
SELECT region, eligible_orders, on_time_orders, on_time_percent
FROM SEMANTIC operations.fulfillment
GROUP BY region
ORDER BY region;

Read the complete generated SQL

Actual native engine output, including generated aliases. Review the population filters and metric calculations.

expanded_sql · Complete captured output

WITH "__crossfield_fact_bbd41d58-a472-44de-bd04-78121436d06b" AS (
        SELECT
            __cf_source_0.region AS __cf_d0,
            "system".main.count(__cf_source_0.id) AS __cf_metric_0,
            "system".main.sum(
                CASE
                    WHEN (((__cf_source_0.delivered_units >= __cf_source_0.ordered_units) AND (__cf_source_0.last_delivered_date <= __cf_source_0.original_promised_date))) THEN (1)
                    ELSE 0
                END) AS __cf_metric_1,
            ((100.0 * "system".main.sum(
                CASE
                    WHEN (((__cf_source_0.delivered_units >= __cf_source_0.ordered_units) AND (__cf_source_0.last_delivered_date <= __cf_source_0.original_promised_date))) THEN (1)
                    ELSE 0
                END)) / "system".main.count(__cf_source_0.id)) AS __cf_metric_2,
            1 AS __cf_present
        FROM warehouse.main.order_facts AS __cf_source_0
        WHERE ((__cf_source_0.original_promised_date = CAST('2024-01-31' AS DATE)) AND (__cf_source_0.status != 'cancelled'))
        GROUP BY __cf_source_0.region
    )
SELECT
    __cf_keys.__cf_d0 AS region,
    "__crossfield_fact_bbd41d58-a472-44de-bd04-78121436d06b".__cf_metric_0 AS eligible_orders,
    "__crossfield_fact_bbd41d58-a472-44de-bd04-78121436d06b".__cf_metric_1 AS on_time_orders,
    "__crossfield_fact_bbd41d58-a472-44de-bd04-78121436d06b".__cf_metric_2 AS on_time_percent
FROM ((
                SELECT __cf_d0
                FROM "__crossfield_fact_bbd41d58-a472-44de-bd04-78121436d06b"
            ) AS __cf_keys
        LEFT JOIN
            "__crossfield_fact_bbd41d58-a472-44de-bd04-78121436d06b" ON ((__cf_keys.__cf_d0 IS NOT DISTINCT
                        FROM "__crossfield_fact_bbd41d58-a472-44de-bd04-78121436d06b".__cf_d0
                    ))
    )
ORDER BY __cf_keys.__cf_d0

Captured from the matching build and runnable fixture. Download the SQL · Download the full explanation as JSON. Generated aliases are not stable identities.

Execute the original semantic query to retain Crossfield’s validation. EXPLAIN (SQL) also binds and optimizes; binding can invoke provider callbacks. EXPLAIN ANALYZE executes.

Choose how much freedom a reporting query should have.

A data team comparing definitions needs flexibility. An AI reporting application may need queries to stay within an approved model. Crossfield lets you set that policy for each DuckDB connection.

SQL from analysts and AI agentsChoose one mode for the connection

Checked inside DuckDB

off

Explore your data

Keep ordinary SQL available for exploration and data preparation. Queries through an attached semantic catalog still follow its definitions.

Query an attached model
Validate the model query
Return approved calculations

Direct source queries also remain available.

semantic

Compose semantic results

Use governed semantic blocks within ordinary SQL. Compare model revisions or reconcile results while retaining the definitions inside each block.

Use semantic query blocks
Validate each semantic block
Compose results with outer SQL

You own the outer calculations; they are not approved model metrics.

strict

Require the reporting rules

Require supported business queries to follow one model attachment’s policy. Reject direct source queries and unapproved calculations.

Submit a business query
Validate the query and its model
Execute Reject

The reporting contract applies to the surrounding query too.

Attached semantic definitions are validated in every mode. Both off and semantic allow ordinary SQL; strict adds restrictions to supported business statements. These settings apply to this connection.

The engine can reject a query that bypasses the reporting rules.

Crossfield uses hooks in DuckDB to check the sources and calculations a query actually resolves to. Those checks follow supported queries through aliases, CTEs and prepared statements. In strict mode, a request outside the model’s policy produces an error before execution, giving a person or AI agent a chance to repair it.

Why this requires integration with DuckDB’s engine →

Use strict mode for this example

USE selects the default model catalog. The setting applies the reporting restrictions to this connection.

SQL · Select the model and enable strict mode

USE operations.semantic;
SET crossfield_mode = 'strict';

Attach a model and query its business definitions.

The model becomes a named catalog alongside your data. Attach it as portfolio, then select its metrics with FROM SEMANTIC. BINDINGS maps the model’s source to your existing warehouse catalog.

SQL · Attach and query the model

ATTACH 'exposure-current.package.json' AS portfolio (
    TYPE crossfield,
    BINDINGS '{"warehouse":"warehouse"}'
);

SELECT issuer, gross_exposure, net_exposure
FROM SEMANTIC portfolio.exposure
GROUP BY issuer
ORDER BY issuer;

The runnable guide includes the source data, model package and expected results. Its setup already performs the attachment shown here.

Inspect how DuckDB executes this example.

Review how each result is calculated.

The expanded SQL shows the January 31 valuation date and the included trading books. It sums absolute position values for gross exposure and signed values for net exposure, grouped by issuer.

EXPLAIN (SEMANTIC) shows the selected definitions and generated SQL without executing the report or calling providers.

Positions · January 31 close · Book A and Book B

Gross exposureSum absolute values

Atlas: |+$12m| + |−$8m|

Net exposureSum signed values

Atlas: +$12m − $8m

Atlas · $20m gross · $4m net

The expanded SQL shows the date and book filter, both formulas, and the grouping by issuer.

SQL · Explain the report

EXPLAIN (SEMANTIC)
SELECT issuer, gross_exposure, net_exposure
FROM SEMANTIC portfolio.exposure
GROUP BY issuer
ORDER BY issuer;

Read the complete generated SQL

Actual native engine output, including generated aliases. Review the population filters and metric calculations.

expanded_sql · Complete captured output

WITH "__crossfield_scope_5493b7ab-4c66-43f7-a15f-c7d876b53c19"(
    __scope_column_0,
    __scope_column_1,
    __scope_column_2) AS (
        SELECT
            __scope_column_0 AS issuer,
            __scope_column_1 AS gross_exposure,
            __scope_column_2 AS net_exposure
        FROM (
                WITH "__crossfield_fact_ef3c92dc-e0ee-45ef-9137-570876360528" AS (
                        SELECT
                            __cf_source_0.issuer AS __cf_d0,
                            "system".main.sum("system".main.abs(__cf_source_0.market_value_usd)) AS __cf_metric_0,
                            "system".main.sum(__cf_source_0.market_value_usd) AS __cf_metric_1,
                            1 AS __cf_present
                        FROM warehouse.main.positions AS __cf_source_0
                        WHERE ((__cf_source_0.as_of = CAST('2024-01-31' AS DATE)) AND (__cf_source_0.book IN ('Book A', 'Book B')))
                        GROUP BY __cf_source_0.issuer
                    )
                SELECT
                    __cf_keys.__cf_d0 AS issuer,
                    "__crossfield_fact_ef3c92dc-e0ee-45ef-9137-570876360528".__cf_metric_0 AS gross_exposure,
                    "__crossfield_fact_ef3c92dc-e0ee-45ef-9137-570876360528".__cf_metric_1 AS net_exposure
                FROM ((
                                SELECT __cf_d0
                                FROM "__crossfield_fact_ef3c92dc-e0ee-45ef-9137-570876360528"
                            ) AS __cf_keys
                        LEFT JOIN
                            "__crossfield_fact_ef3c92dc-e0ee-45ef-9137-570876360528" ON ((__cf_keys.__cf_d0 IS NOT DISTINCT
                                        FROM "__crossfield_fact_ef3c92dc-e0ee-45ef-9137-570876360528".__cf_d0
                                    ))
                    )
                ORDER BY __cf_keys.__cf_d0
            ) AS __scope_input(__scope_column_0, __scope_column_1, __scope_column_2)
    )
SELECT
    __scope_column_0 AS issuer,
    __scope_column_1 AS gross_exposure,
    __scope_column_2 AS net_exposure
FROM "__crossfield_scope_5493b7ab-4c66-43f7-a15f-c7d876b53c19"

Captured from the matching build and runnable fixture. Download the SQL · Download the full explanation as JSON. Generated aliases are not stable identities.

Execute the original semantic query to retain Crossfield’s validation. EXPLAIN (SQL) also binds and optimizes; binding can invoke provider callbacks. EXPLAIN ANALYZE executes.

Choose how much freedom a reporting query should have.

A data team comparing definitions needs flexibility. An AI reporting application may need queries to stay within an approved model. Crossfield lets you set that policy for each DuckDB connection.

SQL from analysts and AI agentsChoose one mode for the connection

Checked inside DuckDB

off

Explore your data

Keep ordinary SQL available for exploration and data preparation. Queries through an attached semantic catalog still follow its definitions.

Query an attached model
Validate the model query
Return approved calculations

Direct source queries also remain available.

semantic

Compose semantic results

Use governed semantic blocks within ordinary SQL. Compare model revisions or reconcile results while retaining the definitions inside each block.

Use semantic query blocks
Validate each semantic block
Compose results with outer SQL

You own the outer calculations; they are not approved model metrics.

strict

Require the reporting rules

Require supported business queries to follow one model attachment’s policy. Reject direct source queries and unapproved calculations.

Submit a business query
Validate the query and its model
Execute Reject

The reporting contract applies to the surrounding query too.

The engine can reject a query that bypasses the reporting rules.

Why this requires integration with DuckDB’s engine →

Use strict mode for this example

USE selects the default model catalog. The setting applies the reporting restrictions to this connection.

SQL · Select the model and enable strict mode

USE portfolio.semantic;
SET crossfield_mode = 'strict';

Build on the work your team already does.

Teams already document definitions, prepare tables and share calculations. Crossfield makes reporting rules available to SQL consumers and validates their use within its supported query contracts.

Compare each approach with the capability Crossfield adds. On narrow screens, scroll the table horizontally.

Existing practices and what Crossfield adds
What you use today	What it already does well	What Crossfield adds
Metric documentation	Explains the intended calculation and business context.	An executable definition that queries can reuse, with validation of approved operations.
Shared SQL, views and prepared tables	Centralizes data preparation and reusable calculations.	Explicit metric and dimension contracts, approved combinations, and inspectable semantic intent.
Calculations in a BI tool	Gives reports in that environment a common modeling surface.	Definitions available through Crossfield’s DuckDB SQL surface, independently of an individual report.
Instructions in AI prompts	Provides context to help an AI agent interpret a question.	Discoverable definitions and engine checks for supported queries, including optional strict enforcement.

Queries must use Crossfield to receive its validation. This does not automatically change calculations in existing reports or connect every BI tool.

Answer broader questions without merging every team’s definitions.

Combine independently computed results through an approved shared dimension. A portfolio team can maintain exposure while a risk team maintains limits, then bring both into one report by issuer. Each team retains ownership of its definitions.

Crossfield validates the model join; the resulting report compares exposure with limits. It does not block trades.

See exposure joined to risk limits →

Measure how a proposed reporting definition changes the result.

A change in the numbers should be explainable. Retain the current definition, attach the proposed revision alongside it, and query both against the same source snapshot. Reviewers can see how much of the difference comes from the reporting rules before those rules reach production.

Two model revisions. One DuckDB connection.Order fulfillment · Checked example

The same four eligible orders and shipment recordsOriginally due January 31 · Observed through February 3

Current definitionRevision 1

operations.fulfillment

Original delivery promise

An order is on time only if every unit arrived by the original promised date.

50%2 of 4 orders complete and on time

Proposed definitionRevision 2

revised.fulfillment

Revised delivery promise

Evaluate the same orders against their revised promised dates.

75%3 of 4 orders complete and on time

+25percentage points

The reported rate rises because the delivery standard changed. No additional orders were delivered. Reviewers can measure that effect before adopting the new definition.

Both definitions remain queryable under separate catalog names. Compare their results with ordinary SQL in semantic mode. Run this revision comparison →

Keep a queryable history of your reporting definitions.

Teams often need to explain a report long after its definition has changed. Keeping earlier versions lets you reopen the model that was used, read its rules, and compare its results with today’s definition using the same data. You can also test a proposed change this way before it reaches the reports your business relies on.

Your application can keep those model versions and their validation results in a DuckDB database using Crossfield’s release store. Your team can choose which version new sessions use and select an earlier release if needed. People already using an attached model continue with that version.

Save each versionKeep a copy of the rules used for reporting.
Compare the resultsRun both definitions against the same data.
Choose the version to useAdopt the tested definition and keep earlier versions available.

Keep the model files yourself, or have your application manage them in the release store. ATTACH alone does not save a history. To reproduce an old report exactly, you also need the data, filters and query inputs used at the time. Read how model history works →

How this compares with dbt, Cube and Snowflake

Version control is an established semantic-layer practice. Crossfield brings retained revisions into DuckDB as separately named catalogs, so SQL users can compare their results in one connection. The products below support change management through different workflows.

Product	Documented revision workflow
Crossfield	Retain versioned packages and attach revisions side by side in DuckDB. An optional native release store keeps immutable published packages and validation records. Crossfield revision guide
dbt Semantic Layer	Develop metric definitions in a version-controlled dbt project. Deploy the semantic manifest and configure the Semantic Layer against a deployment environment. dbt deployment guide
Cube Cloud	Test model changes in an isolated development environment. Personal API endpoints follow the selected branch before changes are promoted to production. Cube development workflow
Snowflake Semantic Views	Native database objects with YAML or SQL definitions kept in Git. Snowflake documents CI/CD, redeployment of earlier definitions and schema cloning for promotion. Snowflake deployment practices

This compares documented workflows, not an exclusive claim to versioning or revision comparison. Reviewed October 27, 2026.

Give each team more room to explore, with shared reporting rules.

The people maintaining definitions and the people asking questions have different jobs. A reusable model lets them collaborate without putting every calculation into every report.

Data teams

Maintain and test the definitions in a model. Review proposed changes against the current version before other teams adopt them.

Analysts

Choose metrics, supported dimensions and filters. Investigate new questions while retaining the model’s calculation and population rules.

Business users

Read reports with explicit meanings. Ask which definition produced a number and whether a definition change explains a difference.

AI engineers

Give AI agents discoverable inputs, permitted combinations and actionable errors. Inspect the planned calculation before running a report.

See how an AI agent discovers and uses the model

DiscoverRead approved definitions and accepted inputs.
AskChoose metrics, dimensions and a scope.
CheckValidate the request and inspect its meaning.
ExecuteRun the approved request through DuckDB.

If the request is rejected: revise it without changing the question, or ask the model owner for a definition.

The model supplies a contract the AI agent can inspect. Repair requires a supported alternative; a rejection does not authorize changing the business meaning.

An AI agent can still misunderstand the question. Repair must preserve its intended meaning; a rejection does not authorize silently changing the metric or removing a filter. Follow the recorded discovery and repair session →

The reporting rules are checked inside DuckDB.

Crossfield validates and compiles the semantic request. DuckDB binds, optimizes and executes it in the same connection. Local-table queries need no separate semantic query service.

Query Farm maintains a matching DuckDB build with additional query-lifecycle hooks. They let Crossfield retain the original request through prepared queries, validate selected implementations during binding, and reject disallowed operations before their callbacks run.

Models and approval rules stay in the extension. These specialist hooks are maintained independently of upstream acceptance and can support other extensions that need similar lifecycle control. Read why the engine changes are necessary →

People, applications and AI agentsSQL using named business metrics

Inside your DuckDB connection

Attached semantic modelDefinitions · relationships · approved operations

CrossfieldResolve definitions · validate · compile

Validation continues during binding

DuckDBNative query execution

Bind & validate
Optimize
Execute

Your tables and attached sources

Results through the same SQL connection

Crossfield’s rules run inside the query lifecycle. Invalid semantic requests raise an error; local-table queries need no separate semantic query service.

Open definitions with Apache Ossie.

Crossfield implements a supported profile of Apache Ossie’s semantic model and expression definitions, with explicit Crossfield approval and execution contracts. This is independent Query Farm work; support is not an Apache endorsement or a claim of complete interchangeability.

Read a small model and its SQL →

Delivered as part of Haybarn.

Haybarn, Query Farm’s DuckDB distribution, will include Crossfield and the engine support it needs. VGI can expose APIs and services as tables and functions; Crossfield adds shared reporting definitions over approved sources.

These examples use local tables. Provider-backed workloads also need matching connector components.

Explore model-owned retrieval →

What adopting Crossfield involves.

Start with one reporting requirement and understand the execution boundary before extending it to more users.

Do we have to replace dbt or our data pipelines?

Your existing preparation workflows can remain. Crossfield models can reference supported tables available to DuckDB. You still author and validate the semantic model and its bindings; this is not an automatic import of every existing dbt or BI definition. See model authoring.

Where does it run, and which DuckDB build do we need?

Haybarn will provide Crossfield together with the matching DuckDB engine. The engine includes the query-lifecycle hooks Crossfield needs to enforce semantic rules during binding and execution. Read why Crossfield is part of Haybarn.

Does it decide which business definition is correct?

The business owns that decision. Crossfield makes the chosen definitions explicit and reusable, and validates supported queries against them. Source quality, model correctness and the choice of metric still need review. Different populations, filters or source snapshots can legitimately produce different answers.

Can we require AI agents to follow the model?

Optional strict mode rejects supported business queries that bypass approved sources or calculations. In an unsealed connection, callers can change the mode. A trusted application can seal a connection to approved model and binding identities. The application still supplies authentication, source permissions and native/process isolation; strict mode is not a catalog access-control system. Read the host-controlled session boundary.

Can we use our current BI tools and AI applications?

The integration point is the matching DuckDB SQL connection. Clients must support the required build and query surface. These examples do not establish compatibility with every BI product or AI framework. Definitions are not automatically applied to queries that execute elsewhere.

How will Crossfield be available?

Crossfield will be included in an upcoming Haybarn release. These guides currently use development builds, so you can evaluate the implemented features before that release. Contact Query Farm for evaluation access, or read the release details and build requirements.

Inspect the evidence behind the examples.

Both scenarios include source data, complete model definitions, independently specified answers and actual engine explanations. They are reproducible synthetic demonstrations, not customer case studies or measured productivity claims.

Order fulfillment

Inspect the six observed shipments and four eligible orders. Reproduce the original-promise result and compare it with the revised definition.

Run the fulfillment example →Read its native verification record

Investment reporting

Inspect the position records, reproduce gross and net exposure, and compare the current scope with the proposed Expansion book.

Run the investment example →Read its native verification record

The published verification records identify the executed checks and matching development builds. Each downloadable package includes its own setup instructions and expected results.

Start with a report you already need.

Read a model, inspect its SQL, or run a complete example with the matching build. For your own workload, start with one disputed metric and the rules it should follow. Query Farm can help assess the model and execution requirements.

You built the data platform. The answers still differ.

The meeting starts with a reconciliation.

The SQL runs and returns rows, but it does not answer the business question.

Changing a reporting rule can improve the reported result without improving business performance.

Three reports use the same “on-time delivery” label for different measures.

What each report means

With Crossfield, agree on the definition and reuse it.

Three reports use the same “exposure” label for different calculations and portfolio scopes.

What each report means

With Crossfield, agree on the definition and reuse it.

Put the definition in the model. Reuse it in each query.

Define the reporting rules.

Attach the model.

Query and validate.

Attach a model and query its business definitions.

Review how each result is calculated.

Choose how much freedom a reporting query should have.

The engine can reject a query that bypasses the reporting rules.

Attach a model and query its business definitions.

Review how each result is calculated.

Choose how much freedom a reporting query should have.

The engine can reject a query that bypasses the reporting rules.

Build on the work your team already does.

Answer broader questions without merging every team’s definitions.

Original delivery promise

Revised delivery promise

Current reporting scope

Expanded reporting scope

Keep a queryable history of your reporting definitions.

Give each team more room to explore, with shared reporting rules.

Data teams

Analysts

Business users

AI engineers

The reporting rules are checked inside DuckDB.

Open definitions with Apache Ossie.

Delivered as part of Haybarn.

What adopting Crossfield involves.

Inspect the evidence behind the examples.

Order fulfillment

Investment reporting

Start with a report you already need.

Run a business example↗

Author a model↗

Compose and compare↗

Build with discovery↗

Run a business example

Author a model

Compose and compare

Build with discovery