25. Governance

25.1 The Governance Object That Does Not Exist Elsewhere #

Conventional data governance operates over datasets, pipelines, reports, and models. A Data Swimming Pool introduces a governance object with no established equivalent: the correlation scope.

A correlation scope is not a dataset — it produces data rather than containing it. It is not a pipeline — it discovers rather than transforms. It is not a model — it is declarative configuration, though it may invoke models. It is a standing authorization to derive relationships between specified categories of data for a specified purpose, and it requires its own governance discipline.

25.2 Federated Computational Governance #

The framework adopts data mesh’s federated computational governance principle [28] and extends it.

flowchart TB
    subgraph FED["Federated Governance Council"]
        direction LR
        F1["Domain representatives"]
        F2["Platform team"]
        F3["Risk & compliance"]
        F4["Privacy office"]
        F5["Security"]
    end

    subgraph SETS["Sets Global Policy"]
        direction TB
        G1["Classification taxonomy"]
        G2["Purpose taxonomy"]
        G3["Autonomy promotion criteria"]
        G4["Precision thresholds by risk tier"]
        G5["Retention and residency rules"]
        G6["Interoperability standards"]
    end

    subgraph DOMAIN["Domain Accountability"]
        direction TB
        D1["Owns source data quality"]
        D2["Owns data contracts"]
        D3["Approves use of its data<br/>in cross-domain scopes"]
        D4["Owns domain-internal scopes"]
    end

    subgraph PLATFORM["Platform Accountability"]
        direction TB
        P1["<b>Owns the correlation substrate<br/>as a product</b>"]
        P2["Owns cross-domain scopes"]
        P3["Owns calibration integrity"]
        P4["Owns cost attribution"]
        P5["Owns the Autonomy Controller"]
    end

    subgraph AUTO["Computational Enforcement"]
        direction TB
        A1["Policy-as-code<br/><i>version controlled</i>"]
        A2["Scope Governor<br/><i>runtime limits</i>"]
        A3["Automated demotion<br/><i>on precision breach</i>"]
        A4["Contract validation<br/><i>at ingestion</i>"]
        A5["Purpose binding<br/><i>at correlation</i>"]
    end

    FED --> SETS
    SETS --> AUTO
    DOMAIN --> AUTO
    PLATFORM --> AUTO
    AUTO -.enforces on.-> RUNTIME["Runtime — no manual gate"]

    classDef fed fill:#3a2540,stroke:#a878c0,stroke-width:2px,color:#f6eaff
    classDef dom fill:#183028,stroke:#4caf7d,color:#e6fff2
    classDef plat fill:#0a5570,stroke:#3fd0f0,stroke-width:2px,color:#ffffff
    classDef auto fill:#3d3313,stroke:#d4a636,stroke-width:2px,color:#fff8e6
    class FED,F1,F2,F3,F4,F5,SETS,G1,G2,G3,G4,G5,G6 fed
    class DOMAIN,D1,D2,D3,D4 dom
    class PLATFORM,P1,P2,P3,P4,P5 plat
    class AUTO,A1,A2,A3,A4,A5 auto

Figure 37. Federated governance operating model. The council sets global policy; domains own their data and approve its use in cross-domain scopes; the platform owns the correlation substrate as a product with a named owner and budget. All policy is enforced computationally at runtime rather than through manual review gates — which is what makes the model scale.

25.2.1 The Platform Owns the Correlation Substrate #

Chapter 6 identified that data mesh leaves the inter-domain space ownerless. The framework’s resolution is explicit:

The correlation substrate is a platform-provided data product with a named owner, a published SLA, a budget, and a roadmap. It is not a shared service that everyone uses and no one maintains. Its owner is accountable for correlation precision, calibration integrity, substrate availability, and cost — and is measured on them.

This does not centralize domain data ownership. Domains continue to own their data, their contracts, and their quality. What the platform owns is the relating of domains, which no domain can own without acquiring expertise in another domain’s semantics.

25.3 The Scope Lifecycle #

Table 50. Correlation scope lifecycle. Stage 6 — mandatory shadow execution — is the stage most likely to be skipped under delivery pressure and most valuable when observed: it is where cost overruns and volume misestimates are discovered before they reach production.

25.4 Governance of Correlations Themselves #

Beyond scopes, individual correlation types require governance:

Table 51. Governance questions applied to correlation types. The accountability question is the one organizations most often leave unanswered, and it must be answered before an action class is promoted above L2 — not after an incident.

25.5 Metrics and Reporting #

The framework proposes a governance dashboard organized around five questions:

Is the substrate trustworthy? Calibration error by scope, share of correlations uncalibrated, retraction rate, divergence between streaming and batch results.

Is it proportionate? Active scope count against cap, share of scopes touching special-category data, DPIA coverage, scope overlap index.

Is it valuable? Correlations consumed against correlations produced, insights acted upon, outcome-confirmed insights, actioned-within-window rate.

Is it controlled? Autonomy level distribution across action classes, automatic demotions in period, policy denials at each boundary, reversal rate at L4.

Is it affordable? Cost per scope, cost per emitted correlation, cost per acted-upon insight, share of budget consumed by the top five scopes.

25.6 Regulatory Alignment #

Table 52. Regulatory alignment at a conceptual level. The EU AI Act row is the most consequential for this framework: the Autonomy Ladder and provenance ledger were designed independently but map closely onto its human-oversight and logging requirements, which the author regards as convergent evidence that the design is pointed in a defensible direction.

25.7 Governance Anti-Patterns #

Next: 26. Scalability →