Why Fluid Forge

A data product is a contract, not a pipeline. Fluid Forge turns one versioned contract.fluid.yaml into a governed, multi-cloud data product — so the same file that makes data trustworthy for your team is what an AI agent reads to consume it safely.

You write the product specification once. The CLI compiles it for your target cloud, validates it in CI before anything ships, and serves it — to people and to agents — under the same declared rules.

pip install data-product-forge
fluid init my-project --quickstart
fluid validate contract.fluid.yaml   # catch a breaking change in review, not at 2am
fluid plan contract.fluid.yaml
fluid apply contract.fluid.yaml --yes # a real, versioned data product — on your laptop, no cloud account

The problem: five tools, five ways to drift

Shipping one trustworthy data product today usually means five tools and five languages:

That's five places for the same product to disagree. When the schema changes, someone has to remember to update all five — or production breaks at 3am. And before any of it ships there's a queue of tickets, approvals, and hand-rolled IAM. That tax is the same one the data-mesh and data-contract movements each set out to remove.

The shift: write the product, not the pipeline

Forge inverts the work. Instead of writing infrastructure code, you write the product specification — and the pipeline falls out when the CLI compiles it.

One contract.fluid.yaml declares the schema, where it's exposed and bound, how it's built and scheduled, who may read it (accessPolicy), which AI agents may use it and for what (agentPolicy), and where the data may physically live (sovereignty). Trust isn't a promise you make after the fact — it's validate → plan → apply, checked on every change.

The new twist: the contract that earns human trust is exactly what an agent needs to consume the product safely. One artifact, two consumers.

The contract carries the context

Raw data plus a query isn't enough to use a data product correctly — you also need its context: what each field means, how fresh it is, how good it is, where it came from, and who may use it for what. For decades that context lived in people's heads, wikis, and ticket threads — exactly the knowledge a senior engineer supplies in review, and exactly what a new hire (or an AI agent) doesn't have.

The industry now has a name for the gap. The 2026 framing is blunt: the model is table stakes; context is the moat. A capable model handed a real-but-ambiguous field still picks the wrong one, because nothing told it which definition the business stands behind — the difference between a smart model and one with the right context. Without that judgment layer, agents produce fluent, confident, wrong answers.

A Fluid Forge contract is that context — made machine-readable and shipped with the product:

Because the context travels inside the contract — versioned, validated, and portable — it doesn't rot in a wiki or get stranded inside one BI tool. When the product ships, its meaning ships with it. That's what makes the contract so powerful: a downstream consumer doesn't re-derive the meaning, and an agent reads it instead of guessing. Over fluid mcp output-port serve, the same governed surface serves the data and the context that makes it safe to act on.

The model layer is commoditizing; your encoded meaning is not. The contract is where that meaning lives — one artifact your team, your pipelines, and your agents all read the same way.

What you get

One contract, not five tools

Why it matters Collapse the five-tool, five-language stack into one specification — fewer drift incidents, fewer 3am pages, faster delivery. You change the contract and re-apply, instead of editing four systems in lockstep and hoping they agree.

A single contract.fluid.yaml carries the schema, exposes / binding (the infrastructure), the schedule, accessPolicy, agentPolicy, and sovereignty — and compiles to native provider DDL plus OpenTofu infrastructure. → What is a contract?

Trustworthy by construction, enforced in CI

Why it matters Trust becomes something you ship, not an audit you pass. A breaking change surfaces at fluid validate in code review — not after a pipeline fails at 2am.

The validate → plan → apply lifecycle is bound by cryptographic digests (bundleDigest + planDigest), re-verified before any DDL runs; a tampered plan.json is rejected outright. It's a tamper-evident version of the shift-left "catch it before production" promise. → The 11-stage production pipeline

Multi-cloud by default, not as a migration

Why it matters Most organizations are already multi-cloud — one team on Snowflake, another on BigQuery, a third on S3 + Athena. One contract works across all of them, with no per-cloud rewrite and no lock-in at the contract layer.

Change binding.platform and the same contract retargets local (DuckDB) → aws (Athena / Glue) → gcp (BigQuery) → snowflake. Every provider implements the same interface, so the compiled output changes without touching the contract. → Providers

AI agents get a contract, not raw access

Why it matters Agents act on whatever data they're handed — they don't pause to sanity-check it. Governing what an agent may read is a prerequisite for scaling agentic AI, not a compliance afterthought.

agentPolicy declares which models may use a product, and for what, in the same file as human accessPolicy. fluid mcp output-port serve then exposes a governed, read-only surface over the Model Context Protocol — binding one expose of a published product and enforcing the contract's rules on every call. → Serve a data product to AI agents

Data-mesh product thinking, without the re-org tax

Why it matters Get the data-mesh outcomes — domain ownership, reuse, faster time-to-insight — without the months of socio-technical setup and dedicated platform team that stalled most adoptions.

Native Data Mesh productType (SDP / ADP / CDP — source-, aggregate-, and consumer-aligned) sits alongside the medallion Bronze / Silver / Gold layer, with consumes[] composition rules so products build into higher-value products. → Product types

Who it's for — and who it isn't, yet

A fit if you have:

• Two or more clouds, or a credible chance of a second one
• Compliance pressure — SOX, GDPR, HIPAA — that makes governance non-optional
• AI agents reading your data (often your newest and largest consumer)
• A platform team building a self-serve contract layer for internal users
• Data-product owners who don't want to learn five tools to ship one product

Not the right tool (yet) if you're:

• A single-warehouse, single-team analytics shop with no governance pressure — dbt alone is simpler; adopt Forge when cross-tool drift starts to bite
• Running sub-second streaming — Forge's model is batch and mini-batch (5-minute to 24-hour latency); for sub-second, look at Materialize / RisingWave
• Expecting a hosted control plane today — Forge is CLI + CI; a hosted UI is on the roadmap, not shipped

We keep an honest Forge vs dbt / Dagster / Terraform / Snowpark breakdown for exactly this reason — that's how a tool earns trust.

See it for yourself

# from nothing to a deployed, validated data product — locally, no cloud account
pip install data-product-forge
fluid init my-project --quickstart && cd my-project
fluid validate contract.fluid.yaml
fluid plan contract.fluid.yaml
fluid apply contract.fluid.yaml --yes

• Getting started — the local-first path, in a few minutes
• Consume a data product — already have one to use? Discover it, trust its contract, and read it as a human, a pipeline, or an agent
• Governance, compliance & the business case — for data & compliance leaders: the audit-and-trust story + an honest, per-provider enforcement matrix
• Providers — does it support my stack? (BigQuery, Snowflake, Athena, DuckDB)
• Vision & roadmap — what we believe, and what's shipped vs. planned
• Apache-2.0, open source, no contributor agreement — no vendor capture at the contract layer.