Governance, Compliance & the Business Case

Governance in Fluid Forge is not a phase you bolt on after the data ships. It's declared in the same contract.fluid.yaml as the schema — who may read it (accessPolicy), which AI models may read it (exposes[].policy.agentPolicy), and where the data may physically live (sovereignty) — checked in CI before anything deploys, provisioned as each cloud's own controls where the provider supports them, and checked against the live platform by fluid verify afterwards. This page is the audit-and-trust story written for the people who sign off on it.

Why it matters For a CDO or compliance lead, the question is never "does the tool have a governance feature?" — it's "can I prove, on demand, who could read what, why it was allowed, and that nothing changed between review and deploy?" Forge answers that with artifacts you already control: a versioned contract that declares the rules, a CI gate that rejects violations before they ship, a plan bound by digest to what apply runs, and a verify report that compares the live platform with the contract. Who read what is in your cloud's own audit log, under the identities the contract granted. Governance becomes something you ship and prove, not an audit you scramble to pass.

The trust story in one line

fluid validate → fluid plan → fluid apply, bound by cryptographic digests.

fluid plan emits a bundleDigest and a planDigest into plan.json. fluid apply re-verifies both before it runs a single line of DDL. A plan.json that was tampered with between review and deploy is rejected outright — the apply never starts. That is the difference between governance that is shift-left (the breaking change or the unauthorized grant surfaces at fluid validate in code review) and governance that is an after-the-fact audit (you discover the drift weeks later, in production, at 3am).

The same contract that earns human trust — schema, sensitivity, freshness SLOs, lineage, access rules — is exactly what an AI agent needs to consume the product safely. One artifact, two consumers, the same declared rules. (See the consumer companion page, Consume a data product.)

What governance lives in the contract

Five declarations carry the governance surface. All are reviewed, versioned and validated with the schema. What each one becomes depends on the cloud; the enforcement matrix has the detail.

Honesty note — placement matters. agentPolicy lives per-expose at exposes[].policy.agentPolicy, so each expose carries its own AI-access boundary. A contract that puts agentPolicy at the contract root fails schema validation. Likewise, there is no top-level security: block in the current schema (v0.7.5) — the contract root is closed, and a security: key fails fluid validate. If a draft you inherit has either, it never passed validation.

→ Full treatment: Governance & Policy (access, sensitivity, sovereignty, audit) and Agent Policy (the per-expose AI gate + runtime enforcement).

Mapping Forge to compliance frameworks

Why it matters Your auditors don't care which YAML key Forge uses. They care which control it supports. This table is the translation layer between your compliance obligations and the contract fields that back them — the rows you can paste into an adoption brief or a SOC 2 readiness doc.

sovereignty.regulatoryFramework records which regimes govern the product, from a fixed enum (GDPR, CCPA, CPRA, HIPAA, PIPEDA, LGPD, PDPA, POPIA, DPA, APPI). The codes are declarative: no code switches on a rule of its own, and SOX or SOC2 fail fluid validate. The controls an auditor asks about come from the fields below.

Framing, deliberately: Forge supports these controls — it gives you the declarations, the CI gate, and the native audit trail that an auditor asks for. It does not certify you compliant. Compliance is an organizational outcome; Forge is the tooling that makes the technical evidence cheap to produce and hard to fake.

→ Detail: sovereignty.regulatoryFramework.

The honest provider enforcement matrix

Why it matters This is the table that gets a tool thrown out of a procurement review when it's wrong. Enforcement is not uniform across clouds: the same field is a native control on one cloud and is not read on another. Here is what fluid apply provisions on 0.18.1, field by field.

Read the cells carefully:

• Snowflake reads none of the governance fields. The Snowflake emitter writes grants, masking and row access policies only from a top-level security: block, which the schema rejects, so a valid contract produces none of them. fluid validate does not warn about this as of 0.18.1. Manage Snowflake access outside the contract for now.
• AWS access is the binding's, not accessPolicy's. The AWS emitter does not write accessPolicy.grants. Declare readers under binding.governance.lakeFormation.grants; column restrictions then narrow those grants.
• Not built on GCP: VPC Service Controls, BigQuery row-level security and BigQuery data policies are not emitted as of 0.18.1. Policy tags are written by the OpenTofu path of fluid apply.
• Masking is at landing, not at query time. No cloud gets a dynamic masking policy. Values are treated when the DuckDB acquisition runner writes them, and an embedded-SQL build that would land a masked expose is refused. See masking at landing.
• What is proven. forge-cli's tests run the governed GCP modules through tofu validate and through tofu plan/apply against an in-process BigQuery stand-in, and the Lake Formation grants against moto. Against real Google Cloud, on 4 October 2026 and 0.18.0, products applied with fluid apply --env gcp created their retention partitions, Cloud KMS keys, dataset IAM members and policy tags, fluid verify passed against the live platform, and a denied principal was refused the restricted column. Not proven: the Lake Formation half against a real account as 0.17.0 derives it from columnRestrictions; the grant shape it emits was applied and enforced on a real account from 0.16.6, written by hand in the overlay. See Governance parity.

Where native enforcement is missing, route agent reads through the MCP output-port gate, and check what actually deployed with fluid verify.

→ Per-field detail: Governance & Policy → What gets emitted per cloud · AWS · Snowflake · GCP.

The audit trail

Why it matters "Show me who accessed this product last quarter" should be a query, not a project. The reads are already in your cloud's audit log under the identities the contract granted; Forge adds the decisions it makes itself.

What Forge records:

Forge does not write to BigQuery audit logs, CloudTrail or Snowflake ACCESS_HISTORY, and there is no cross-cloud record format. Direct reads land in those logs as they always do.

A deny record names its reason, from a closed vocabulary such as in-deniedUseCases or not-in-allowedModels, so a denied agent read is as auditable as an allowed one.

→ Detail: Agent Policy → Audit event schema and Governance & Policy → Audit trail.

How policy gets applied (the CLI path)

Why it matters The policy path is designed so the safe operations need no cloud credentials at all — your CI can gate every PR on policy correctness without ever touching production IAM. Deployment is a separate, explicit, opt-in step.

The policy commands, and the one that provisions:

fluid policy check contract.fluid.yaml            # CI gate — no cloud calls
fluid policy compile contract.fluid.yaml          # contract → bindings JSON, for review
fluid apply contract.fluid.yaml --yes             # provisions the controls
fluid verify contract.fluid.yaml --strict         # checks them on the live platform

→ Detail: fluid policy check · fluid policy apply · agent enforcement modes.

The business case (qualitative)

Why it matters The line item on your adoption brief isn't "buy a governance tool." It's "stop paying the five-tool drift tax." Here's the value, framed honestly — no invented ROI percentages, no benchmark claims, no customer counts. Just why.

• Five tools to one. Shipping a trustworthy data product today usually means five tools and five languages — the model (dbt), the infrastructure (Terraform), the schedule (Airflow), the access rules (OPA), the masking rules (a warehouse UI). That's five places for the same product to disagree. Forge collapses them into one contract.fluid.yaml.
• Fewer drift incidents. When the schema changes, you change one file and re-apply — instead of editing four systems in lockstep and hoping they agree.
• Fewer 3am pages. A breaking change or an unauthorized grant surfaces at fluid validate / fluid policy check in code review — not after a pipeline fails in production.
• No per-cloud rewrite. One base contract runs on local (DuckDB), AWS (Athena/Glue), GCP (BigQuery) or Snowflake: a per-cloud overlay changes only the binding (platform, format, location and, on 0.7.6, principals). See Switch clouds.
• Governance shifted left, into code review. accessPolicy, agentPolicy, and sovereignty are part of the contract from line one — reviewed and versioned with the schema, not retrofitted after the data is already in a vector store.

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
• 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

See also

• Why Fluid Forge — the engineer/leader value pillars this page extends for buyers
• Governance & Policy — every governance field, which command enforces it, and what it becomes per cloud
• Agent Policy — the per-expose agentPolicy concept + runtime enforcement
• AWS provider — Lake Formation detail
• Snowflake provider
• GCP provider — BigQuery detail
• Provider roadmap — governance maturity across clouds
• fluid policy check, fluid policy apply and fluid verify — the policy CLI path
• Agent governance task — the three agent enforcement modes
• Consume a data product — the consumer front door companion to this page