August 2026 – EduDataSci – Educating the world about data and leadership

The Internet After Apps: Public, Private, and Personal AODPs in an Intent-Driven World

When software can be generated for a person, a task, or a moment, the durable architecture must move out of the application and into the interface to data and action.

A wealth advisor finishes a client call and asks an agent to build a small application.

The application should assemble the household’s accounts, identify securities that could raise $75,000, preserve the client’s income targets, avoid restricted positions, estimate tax consequences, and prepare an explanation for the client. It is not intended to become the next enterprise advisor platform. It may only be needed for the next hour.

The software could be generated almost immediately. That is the appealing part.

The dangerous part is everything the software must touch.

It needs market information, client preferences, account positions, tax lots, suitability rules, firm policies, trading restrictions, approval thresholds, and access to an order-management system. It must know which information belongs to the client, which belongs to the firm, and which comes from public or commercial sources. It must distinguish between calculating a proposed trade and submitting one. It must preserve evidence of what it read, why it made a recommendation, who approved it, and what eventually changed.

The application may be disposable. Its authority cannot be.

This is the architectural problem hiding underneath intent-driven computing and enterprise vibe coding. As software becomes easier to generate, more of the burden moves onto the interfaces through which that software reaches data, policy, and operational systems. We cannot make every dynamically generated application trustworthy in the same way that we certify a major enterprise platform. We can, however, force every application to operate through trustworthy products.

That is the purpose of the Action-Oriented Data Product, or AODP.

An AODP is a reusable, domain-owned product that exposes governed data and governed actions through a secure, discoverable, contract-driven interface. AODPs can exist in public, private, and personal spaces. Connected through a mesh, they provide the durable substrate underneath people, agents, and software assembled for individual tasks.

The internet built around pages and applications does not disappear. It gains another layer: an internet of governed data and action.

The Pipeline You Don’t Have to Build

There is a peculiar habit in data engineering: we measure sophistication by the machinery we build. A source drops CSV files into storage, so we create a pipeline. The pipeline needs a schedule, parameters, schema handling, retries, logging, alerts, deployment rules, credentials, and somebody willing to answer for it at 2:00 a.m. None of that is especially difficult. That is precisely the problem. Enterprises spend an astonishing amount of engineering time repeatedly solving work that is too ordinary to deserve bespoke engineering.

Microsoft Fabric Shortcut Transformations attack that problem at the right level. They convert supported files referenced through a OneLake shortcut into a managed Delta table, keep the table synchronized with the source, and expose the result to SQL, Spark, Power BI, and other Fabric consumers. CSV, Parquet, and JSON transformations are generally available. Excel support is in preview. A separate public-preview capability applies built-in language processing to text files for summarization, translation, sentiment analysis, personally identifiable information detection, and named-entity recognition.

That feature list is useful. The architectural consequence is more important.

Shortcut Transformations move routine ingestion from something every project must build into something the platform simply does.

That is the difference between accelerating a pipeline and deleting the need for one.

Fabric Runtime 2.0 Changes the Fabric Engineering Baseline

A Fabric notebook can contain six lines of PySpark and still depend on an enormous amount of technology that is not visible in those six lines. The result depends on the version of Spark that planned the work, the Python or Scala runtime that interpreted the code, the Delta implementation that read and wrote the tables, the Java virtual machine underneath Spark, the operating system beneath that, and the Fabric services that connected the workload to OneLake and compute.

That hidden stack is easy to ignore while it remains stable. Fabric Runtime 2.0 is the moment when ignoring it becomes dangerous.

Runtime 2.0 is now the latest generally available Fabric Spark runtime. It moves the platform to Apache Spark 4.1, Delta Lake 4.2, Python 3.13, Java 21, Scala 2.13, R 4.5.2, and Azure Linux 3.0. Microsoft currently requires customers to opt into it, but plans to make it the default selection for new workspaces and Environment items in late September 2026.

Those facts make Runtime 2.0 sound like a substantial but conventional platform upgrade. It is more important than that. Runtime 2.0 brings together a new Spark generation, a newer Delta protocol, native execution, lower-latency streaming, modern language runtimes, stronger environment management, and a clearer lifecycle for Fabric applications.

The significance is not that every Fabric workload suddenly needs the newest feature. The significance is that the runtime has become part of the application’s architecture, operating model, performance model, and deployment contract.

Govern the Decision, Not Just the Model

An AI model can be technically sound and still produce an indefensible business outcome.

Imagine a wealth-management copilot that produces a reasonable recommendation. The arithmetic works and nothing looks obviously wrong. It also used stale household information, retrieved research approved for institutional clients, missed an account restriction, and placed the recommendation into a client email before an adviser reviewed it.

None of those failures necessarily means the model was defective. They mean the organization governed the model while leaving the decision system around it underdefined.

That distinction is becoming central to enterprise AI. Organizations do not take risk simply because a model exists. Risk appears when model output changes a customer interaction, a financial decision, an operational action, or the movement of money. The proper unit of governance is therefore not just the model. It is the complete AI-enabled decision: its purpose, data, retrieved knowledge, prompts, rules, models, tools, human authority, resulting action, and retained evidence.

This post explains why AI governance has become its own operating discipline, how it connects policy to observable behavior and evidence, and why good governance expands the set of AI uses an organization can responsibly place into production.

The key control of AI governance is not the model. It is the decision the enterprise makes with it.

Fabric Can Finally Monitor Itself: Building a Real-Time Capacity Control Loop

Most Fabric capacity incidents are diagnosed in reverse.

A report slows down. A refresh misses its window. A user sees a capacity-limit error. Then someone opens the Capacity Metrics app and works backward through the evidence to find out what happened.

That is useful monitoring, but it is still an autopsy.

Capacity Overview Events change the sequence. Microsoft made them generally available in this month, giving Fabric a near-real-time stream of each capacity’s smoothed utilization and throttling posture. A Summary event represents a 30-second window for an active capacity, except that all-zero windows are suppressed. State events arrive when status changes. Those signals can flow through Real-Time hub and Eventstream, land in Eventhouse, appear on a Real-Time Dashboard, trigger Fabric Activator, and ultimately drive a guarded scaling action through Azure Resource Manager.

This is also a useful way to reintroduce Real-Time Intelligence. RTI is sometimes described as Fabric’s specialist workload for telemetry, clickstreams, and IoT. Capacity Overview Events show the larger idea. Fabric can use its own event-driven architecture to observe and operate Fabric.

The goal is not “add an alert when utilization reaches 80 percent.” It is an architecture that turns capacity management into a controlled feedback loop.