FLUIDFLUID
  • Introduction
  • Quickstart
  • Why FLUID
  • FAQ
  • What FLUID Is
  • Core Principles
  • Agentic-Native Layer
  • FLUID vs ODCS / ODPS
  • Reference Implementation
  • Anatomy
  • Cheatsheet
  • Minimal Contract
  • Specification
  • Versions
  • Changelog
  • JSON Schema 0.7.5 (stable) ↗
  • Reference 0.7.5 (HTML) ↗
  • Preview: 0.7.6
Examples
How-to
What's New
Deck
  • Contributing
  • Governance ↗
  • Conformance Corpus ↗
  • Vision
GitHub
GitHub
  • Introduction
  • Quickstart
  • Why FLUID
  • FAQ
  • What FLUID Is
  • Core Principles
  • Agentic-Native Layer
  • FLUID vs ODCS / ODPS
  • Reference Implementation
  • Anatomy
  • Cheatsheet
  • Minimal Contract
  • Specification
  • Versions
  • Changelog
  • JSON Schema 0.7.5 (stable) ↗
  • Reference 0.7.5 (HTML) ↗
  • Preview: 0.7.6
Examples
How-to
What's New
Deck
  • Contributing
  • Governance ↗
  • Conformance Corpus ↗
  • Vision
GitHub
GitHub
  • What's New

    • What's New
    • FLUID 0.7.6 (preview) — Declarative Packaging Modes
    • What's New in FLUID 0.7.5 — Streaming Kafka → Iceberg Sink & Confluent Tableflow
    • What's New in FLUID 0.7.4 — Runtime agentPolicy Enforcement at the MCP Gateway
    • What's New in FLUID 0.7.3 — Source-Aligned Acquisition
    • What's New in FLUID 0.7.2 — Semantic Truth Engine
    • What's New in FLUID 0.7.1 — Agentic Governance + Provider-First Orchestration

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 / deniedUseCases take 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-text purposeLimitation.
  • 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, Global or Multi-Region.
  • Regions — allowedRegions / deniedRegions.
  • Frameworks — regulatoryFramework from 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

Capability0.5.70.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
Triggersschedule, event, manual, dependencyadds 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.

Edit this page on GitHub
Last Updated: 10/5/26, 9:55 AM
Contributors: fas89, Claude Opus 4.8
Prev
What's New in FLUID 0.7.2 — Semantic Truth Engine