A validated output is only useful where somebody can reach it.

Delivery is the least glamorous third of the platform and the one most likely to be quietly oversold. Some destinations are simple. Some create side effects in a system that has its own opinions. We treat those differently, and we say which is which.

Destinations

Four shapes, in increasing order of how much can go wrong.

A table in a warehouse

The output lands as a dataset your existing tools already query. Nothing downstream needs to know Beetl exists.

This is the default, and for most engagements it is also the right answer.

A file or object-store batch

For handoffs to systems that prefer a drop location, or to a partner who wants a file on a schedule.

Contract-checked on write, so a malformed batch fails here rather than in somebody else's importer.

A dashboard, or a question in plain language

Embedded dashboards over the curated output, and natural-language queries against validated datasets with the source records still attached to the answer.

Reporting is a destination for integrated data. It is not the product, and a dashboard built on an unowned pipeline is just debt with a nicer surface.

A customer-owned staging database

Where the receiving system wants to run its own import, we prepare and reconcile the data and hand it over at the boundary.

Often the safest option when the destination is an ERP with strong opinions about how records enter it.

Curated output

The output is queryable, and the answer carries its provenance.

Once a pipeline has produced a validated dataset, it can be queried directly, charted, or asked about in plain language. The point is not the chart. It is that the number can be traced back.

1Queries run against the curated dataset, not against the source system.
2Results are durable artifacts rather than a transient view.
3Charting happens server-side, so a shared result is the same result.
Beetl's query editor showing a SQL query against a curated dataset, the returned rows, and a chart built from the result.
Query editor over a validated output, with server-side charting.
Dashboards

A dashboard is a destination, not the product.

Where a recurring view is what the business actually needs, we build it on the curated output rather than on a direct connection to a source system. The difference matters the first time somebody asks where a number came from.

1Built on the validated dataset, so the dashboard and the warehouse agree by construction.
2Per-tenant isolation, so a shared dashboard shows each customer only their own rows.
An embedded dashboard built on a Beetl curated dataset, showing two charts of manufacturing wear-rate data.
Embedded dashboard over a validated output.

Writing back into a live system

This is the honest part. When a destination is a warehouse, a file, or a staging table, delivery is a solved problem and we treat it as one. When the destination is a live API or ERP, it is not, and the reason is worth stating plainly.

A remote system usually cannot offer a transaction across several requests. One call succeeds, a later one fails, and rollback may not exist. Handling that safely needs a delivery journal: a stable identifier per input record, captured response values, idempotency keys, attempt counts, and a visible permanent-failure state.

We have designed that and we have not shipped it. Until we have, we prefer warehouse, file, or staging handoffs wherever the destination allows, and we reduce exposure by reconciling against the source-faithful copy rather than trusting that a load went through.

What we will not do is describe stateful delivery as though it were finished. It is the single easiest thing to oversell in this category, and the failure mode lands on your data rather than ours.

Tell us where the data has to end up.

The destination usually decides how hard the engagement is. It is the first thing we scope.

Talk to us