What's New in FLUID 0.7.1 — Agentic Governance + Provider-First Orchestration
FLUID 0.7.1 adds agentic governance — which AI models may read an expose, and for what — together with data sovereignty, a root-level access policy, and provider actions as orchestration tasks. It is additive over 0.5.7: scripts/check-compat.py --from 0.5.7 --to 0.7.1 finds no narrowing change.
Every example on this page validates against the published 0.7.1 schema (JSON Schema Draft 2020-12) when placed in a minimal contract.
This page was corrected
Earlier versions of this page showed agentPolicy at the top level, sovereignty fields that do not exist, free-text use cases, and a top-level orchestration block. None of those validate against 0.7.1. The examples below use the shapes the 0.7.1 schema defines. Note also that the 0.7.1 schema bundled by the reference implementation differs from the published one — see Versions.
🤖 Agentic governance: exposes[].policy.agentPolicy (NEW)
Control which AI models can read an expose and how they may use it. The policy is per-expose, under exposes[].policy.agentPolicy:
exposes:
- exposeId: customer_insights
kind: table
# ...contract, binding...
policy:
agentPolicy: # NEW in v0.7.1
allowedModels: [gpt-4, claude-3-opus, gemini-1.5-pro]
deniedModels: [gpt-3.5-turbo]
maxTokensPerRequest: 8192
maxTokensPerDay: 100000
allowedUseCases: [analysis, summarization, qa] # controlled vocabulary
deniedUseCases: [training, fine_tuning]
canReason: false
canStore: false
auditRequired: true
purposeLimitation: "Customer-insights analysis only; no credit scoring or political profiling."
- Model access —
allowedModels/deniedModels. - Use cases —
allowedUseCases/deniedUseCasestake values from a fixed vocabulary:inference,reasoning,analysis,summarization,classification,embedding,search,qa,code_generation,fine_tuning,training,rag. Anything more specific goes in the free-textpurposeLimitation. - Rate limits —
maxTokensPerRequest,maxTokensPerDay. - Audit and retention —
auditRequired,canStore,retentionPolicy(maxRetentionDays,requireDeletion).
🌍 Sovereignty constraints (NEW)
Declare where data may live at the contract level, with the top-level sovereignty block:
sovereignty: # NEW in v0.7.1
jurisdiction: EU
allowedRegions: [europe-west1, europe-west3]
deniedRegions: [us-central1]
dataResidency: true # data must stay within the jurisdiction
crossBorderTransfer: false
regulatoryFramework: [GDPR, HIPAA]
enforcementMode: strict # strict | advisory | audit
- Jurisdiction —
EU,US,UK,CA,AU,JP,CN,IN,BR,GlobalorMulti-Region. - Regions —
allowedRegions/deniedRegions. - Frameworks —
regulatoryFrameworkfrom a fixed list (GDPR,CCPA,CPRA,HIPAA,PIPEDA,LGPD,PDPA,POPIA,DPA,APPI). - Transfers —
crossBorderTransfer(boolean) and, when transfers are allowed,transferMechanisms(SCCs,BCRs,Adequacy,DPF,Consent,Derogation).
⚙️ Provider-first orchestration (NEW)
A build's execution.orchestration can describe its Airflow DAG, including provider actions as tasks:
builds:
- id: customer_360
pattern: embedded-logic
engine: sql
properties:
sql: "SELECT * FROM staging.customers"
execution:
orchestration: # NEW in v0.7.1
engine: airflow
airflow:
dagId: customer_360
tasks:
- taskId: ensure_s3_bucket
type: provider_action
operator: ProviderActionOperator # see the note below
provider: aws # aws | gcp | azure | snowflake | databricks | kafka | kubernetes | local | custom
action: s3.ensure_bucket # <service>.<action>
params:
bucket_name: customer-data-lake
region: us-west-2
- taskId: load_to_snowflake
type: provider_action
operator: ProviderActionOperator
provider: snowflake
action: table.ensure
params:
database: ANALYTICS
schema: GOLD
table: CUSTOMER_360
dependencies: [ensure_s3_bucket]
Name each task's operator
In the 0.7.1 to 0.7.6 schemas, the conditional rules for fluid_execute, bash and python tasks also match any task that has no operator member, so such a task must satisfy all three at once (params.contract_path, a bash command and a Python callable) and is in practice rejected. Setting operator avoids it; any value that does not contain FluidExecute, Bash or Python leaves a provider_action task to its own rule (provider, action and params required).
Tasks can also declare the data products they wait on (dataProductDependencies), what they produce (produces), a cost estimate (costEstimate), and access control (accessControl); taskDefaults.errorHandling sets a retry strategy and which errors are retryable.
A top-level orchestration key arrives in 0.7.2. Be aware that its tasks list is not defined by any FLUID schema up to 0.7.6: orchestration is an open object there, so a validator accepts any orchestration.tasks content without checking it. The task shape the schema does check is the one above, under airflow.tasks.
📊 Root-level access control (NEW)
The top-level accessPolicy declares grants for the whole product:
accessPolicy: # NEW in v0.7.1
grants:
- principal: "group:data-analytics@company.com"
permissions: [read, select, query]
resources:
- "$.exposes[?(@.kind=='table')]"
- principal: "serviceAccount:pipeline@project.iam.gserviceaccount.com"
permissions: [write, insert, update]
conditions:
ipRanges: ["10.0.0.0/8"]
Each grant requires only principal. permissions come from a fixed list (read, select, query, write, insert, update, delete, admin, manage; create is added in 0.7.2), resources holds JSONPath expressions selecting the exposes in scope, and conditions is an open object.
📈 What 0.7.1 adds over 0.5.7
| Capability | 0.5.7 | 0.7.1 |
|---|---|---|
| AI model control | — | exposes[].policy.agentPolicy |
| Data sovereignty | — | top-level sovereignty |
| Orchestration | — | build(s).execution.orchestration with Airflow DAG, tasks and provider actions |
| Access control | — | top-level accessPolicy |
| Task dependencies on data products | — | airflow.tasks[].dataProductDependencies |
| Error handling | — | airflow.taskDefaults.errorHandling |
| Cost tracking | — | airflow.tasks[].costEstimate |
| Triggers | schedule, event, manual, dependency | adds dataset, schedule_and_dataset, timetable |
🔄 Backward compatibility
- ✅ No narrowing change from 0.5.7 (
scripts/check-compat.py). - ✅ Every addition is optional.
Migration:
fluidVersion: "0.7.1" # was "0.5.7"; the 0.7.1 schema accepts only "0.7.1"
See the Schema Changelog for the full version history, or the 0.5.7 → 0.7.1 diff for the auto-generated change list.
