The Distributed Decision Engine That Exposes The Data Control Plane Lie

Most organizations treat Microsoft Fabric lineage like governance. It feels like governance because it’s visual, centralized, and comforting. But lineage does not prevent anything from happening—it only explains what already happened. This episode dismantles the idea that visibility equals control and walks through why Fabric’s architecture makes that confusion inevitable. There are no demos, no UI tours, and no feature walkthroughs. Instead, this episode focuses on architecture, timing, and inevitability. We break down why lineage is a forensic tool, why governance requires authority, and why platforms optimized for execution cannot govern by observation alone. You’ll hear five concrete scenarios that show how “governed” Fabric estates drift into probabilistic security—and how to tell, definitively, whether a control is real or just metadata theater. Opening: The Comfortable Assumption Lineage feels safe because it looks like control. It produces diagrams, arrows, and dependency graphs that give leaders something to point at. But governance is not about explanation—it’s about refusal. Real governance requires the power to deny execution in real time, before a write completes and before data changes state. Most organizations don’t realize this gap during design reviews. They realize it during audits, when screenshots and lineage graphs fail to answer the only question that matters: what actually prevented this? Governance Is a Verb, Lineage Is a Noun This episode starts by fixing language, because bad governance always begins with bad definitions. Governance is a verb. It constrains, refuses, and enforces intent.
Lineage is a noun. It describes, traces, and reconstructs. Observability tells you what happened. Governance determines what is allowed to happen. A speedometer is not a brake, and lineage is not authority. If a system cannot say “no” synchronously—before execution completes—it is not governing. It is documenting outcomes after the fact. Many “governance programs” are really entropy management efforts with good intentions and excellent dashboards. The Policy Enforcement Point Fabric Doesn’t Have Every governed system has a policy enforcement point (PEP): a synchronous, transactional, authoritative gate that sits directly in the execution path. Fabric does not have one. Fabric lineage is emitted telemetry. It is metadata generated after notebooks run, pipelines execute, and outputs are written. That makes it observability by definition. No amount of labels, endorsements, or integrated catalogs changes the fact that lineage exists after execution. Governance that arrives after execution is paperwork—useful paperwork, but still paperwork. Fabric Is a Router, Not a Firewall Fabric is designed to reduce friction, not introduce choke points. It is an execution substrate—a forwarding plane—not a control plane. Workspaces, capacities, and roles provide organization and resource management, not intent enforcement. As Fabric adoption scales, reuse, copying, sharing, and shortcutting become normal and encouraged behaviors. Reduced friction increases blast radius. Lineage provides a map of the routes data took, but it never acts as the checkpoint that decides whether the route should exist. The platform will always execute faster than humans can govern unless enforcement is architectural, not procedural. Deterministic vs Probabilistic Security Once enforcement is partial, security becomes probabilistic. Some paths are gated, some are merely logged, and people naturally choose the paths that work. Over time, exceptions become permanent, and governance quietly collapses into human judgment calls made under deadline pressure. Lineage makes probabilistic security feel complete because it produces closure: a graph that shows everything. But proving how data moved is not the same thing as preventing it from moving. Visibility does not reduce risk when prevention was required. Scenario 1: Cross-Workspace Data Exfiltration A dataset is shared from Workspace A to Workspace B. A notebook or pipeline in Workspace B materializes a copy under a new boundary. Lineage records the flow perfectly—but the data is already duplicated. The question governance must answer is simple: was there a deny-before-write gate tied to destination context? If not, the outcome was inevitable, not accidental. Scenario 2: Over-Privileged Roles Fabric RBAC assigns capability bundles, not intent. Contributor, Member, and Admin roles are powerful and often granted to unblock delivery. Once granted, governance collapses into role assignment. Lineage becomes a regret ledger, documenting actions that were allowed because the role allowed them. Nothing in the system prevented those actions from occurring. Scenario 3: Sensitivity Labels Without Execution Constraint Labels describe data; they do not enforce behavior unless bound to a deny gate. A labeled table can still be read, transformed, copied, and written into weaker boundaries. Label propagation creates the illusion of control while the risk surface expands. Knowing what you leaked is not the same as preventing leakage. Scenario 4: Purview + Fabric Lineage Adding Purview does not convert observability into governance. It adds a second observer. Purview excels at cataloging, classification, and cross-system visibility, but it still operates after execution. If a notebook write succeeds, neither Purview nor Fabric lineage prevented anything. They only improved the narrative after the fact. Scenario 5: Incident Response Timeline The incident timeline exposes the truth. Impact happens first. Detection happens later. Lineage appears during reconstruction. Containment is manual and messy. Reports are written. Artifacts are produced. But governance that begins after impact is incident response, not prevention. If the first time policy appears is after execution, the system never governed the event. The Responsibility Map

• Identity (Entra): Who are you
• Fabric: Can it run
• Purview: What happened
• Missing Layer: Should it run here, now, with this data

Most failures come from asking the wrong layer to solve the right problem. Observability tools are blamed for not enforcing. Execution platforms are blamed for not judging intent. Governance requires a policy decision and enforcement layer that exists before execution—not after. The 4-Question Governance Litmus Test If a control cannot answer “yes” to all four questions, it is not governance:

1. Can it say no?
2. Can it say no before execution?
3. Can it enforce centrally?
4. Can it fail safely (deny by default)?

Lineage, tags, catalogs, and dashboards fail this test by design. They are telemetry, not authority. Prevention vs Observability: The Decision Tree If you need prevention, design choke points and remove pathways. If you need observability, maximize visibility and accept execution. Mixing the two creates probabilistic security. Partial enforcement guarantees drift. Rule of thumb:
Prevention lives above Fabric.
Observability lives after Fabric. Confuse the two, and you don’t get governance—you get better audit diagrams. A 30–60 Day Governance Model That Doesn’t Depend on Hope Real governance starts with subtraction, not features:

• Define explicit deny conditions
• Externalize enforcement into real choke points
• Reduce Fabric privilege bundles
• Treat lineage as audit-only telemetry

This shrinks blast radius, reduces exceptions, and restores determinism. Final Takeaway Fabric lineage explains what happened. Governance prevents what’s allowed to happen. Confusing the two turns your data estate into conditional chaos. In the next episode, we design an actual data control plane—and explain why Microsoft doesn’t ship one by default. Subscribe, and send this episode to the person who keeps calling dashboards “controls.”

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365–6704921/support.