Strategy – 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.

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.

The CFO Does Not Want Your Lineage Graph

When a senior executive challenges a number, the meeting does not pause so everyone can open a lineage tool, inspect a dependency graph, and trace SQL.

That is not how trust works at the executive level.

The CFO is not asking for a prettier diagram. They are asking for an answer. They want to know where the number came from, what logic produced it, and whether they should trust it. And they want that answer quickly, accurately, and in plain language.

That is why I think the current state of the art in data glossary and data lineage is fundamentally transitory. The graph matters. The catalog matters. The metadata matters. But none of those is the destination. They are ingredients. The destination is an interface that can answer the question directly and back that answer with evidence.

From Vibes to Specs: The New Citizen Development Financial Services Can Actually Trust

A friend of mine recently came back from a conference session on “vibe coding” with the kind of energy you only get when something fundamental has shifted. They are smart, tech-enabled, and fully comfortable around digital tools, but they are not a programmer. After a brief introduction, they sat down and built several applications. Not toys. Not abstract demos. Useful applications that solved real problems in both their daily life and their professional work. They even shared those applications with colleagues. And, as is often the case with these new tools, the apps were not only functional. They were polished, themed, and appealing to use.

That story is easy to file under amazement. It is harder, and more important, to recognize it as a signal. The computing world is going through a fundamental shift that changes the locus of invention. Before – and almost every programmer has had this experience, I suspect – non-developers would come up to you and tell you an idea, then try to get you to help them make it happen. Now they can do a lot of the hard work themselves!

The signal, though, is not that everyone should now go build production systems from a prompt window and hope for the best. The signal is that the distance between understanding a problem and expressing a solution in software has collapsed. The people closest to the work can now participate in shaping the tools they need in a much more direct way. That is the breakthrough. And in the financial services sector, where structure, security, explainability, and accountability are non-negotiable, the way to turn that breakthrough into something durable is not vibe coding. It is spec-driven development.

If we want a world where everyone can get to what they need to do, their way, even inside the highly governed world of banking, wealth management, lending, life insurance, reinsurance, property and casualty insurance, and credit card processing, then spec-driven development should become the new citizen development model.

Automate the Ordinary, Protect the Complex: Why Straight-Through Document Processing Lowers Risk

The most expensive document in a regulated workflow is often not the complicated one. It is the ordinary one that gets treated like an exception.

Every unnecessary touch adds labor cost, cycle time, rekeying risk, and inconsistency. That is why straight-through processing matters when it is part of a broader digital intelligence process. Done well, it reduces risk twice. On the front end, it automates the non-exceptional work. On the back end, it gives people more time for the cases a machine cannot resolve reliably—or should not be allowed to resolve alone. That is the real operating advantage now emerging across insurance and lending workflows.

Straight-through processing is not just scanning or OCR. It is an operating model: classify the document, extract the right fields, validate them against rules and third-party data, determine whether confidence is high enough, and then either complete the task or route the file into an exception queue with context. That direction is already built into the market. ACORD describes its standards work as supporting the insurance industry’s goal of straight-through processing, McKinsey notes that document-classification capabilities can be reused across underwriting, claims, and policy servicing, and McKinsey’s 2026 banking work describes end-to-end workflows that accelerate flow while escalating exceptions to humans in the loop.

After FabCon: What Agentic Apps on Microsoft Fabric Could Actually Look Like in Insurance and Wealth Management

The real test for agentic AI is not whether it can answer a question. It is whether it can answer the right question, with the right data, under the right controls, and then move work forward without creating new risk. That is why Microsoft’s March 12 piece on operationalizing agentic applications mattered. It shifted the conversation away from chatbot theater and toward architecture, telemetry, governance, and action. Since FabCon Atlanta in March 2026, that story has become more concrete: Microsoft used the event to frame trusted AI around OneLake, Real-Time Intelligence, Fabric IQ, and AI agents; said Fabric data agents are now generally available; introduced Fabric Remote MCP in preview; and announced Planning in Fabric IQ.

Just as important, the weeks immediately after FabCon filled in several missing pieces. Microsoft says Fabric IQ now supports Azure Private Link integration, and it also says Fabric IQ ontology will be exposed through public MCP endpoints. Microsoft added Ontology Rules with Fabric Activator, documented Business Events in Real-Time Intelligence, published source control and deployment-pipeline guidance for Fabric data agents, and, in April 2026, announced shortcut transformations as generally available. Taken together, those updates make Fabric’s agent story look less like a promising concept and more like an emerging operating model.

That matters because Fabric IQ is no longer just a semantic side note. Microsoft now describes IQ as a workload spanning ontology, plan, graph, data agents, operations agents, and semantic models. Ontology defines entity types, relationships, properties, and condition-action rules bound to real data. Graph adds relationship-centric analysis. Plan brings budgets, forecasts, and scenarios onto the same governed platform. And Fabric data agents can answer questions over lakehouses, warehouses, semantic models, KQL databases, ontologies, and Microsoft Graph in Fabric.

Pages: 12

FinOps for the Data + AI Era: Strong Structures Beat Strong Opinions

The fastest way to turn cloud enthusiasm into executive skepticism is simple: ship something impressive in Data or AI…and then hand Finance a bill no one can explain.

That’s not a tooling problem. It’s a structure problem.

In this post, I’m going to make the case for strong FinOps structures that actively engage Data, AI/ML, and the broader cloud stack—not as a “cost police” function, but as an operating model for technology value. We’ll look at why the scope of FinOps has expanded, what makes Data and AI spend uniquely tricky, and what “strong” actually looks like when it’s working.

Knowledge Graphs: The Quiet Superpower Behind Trustworthy AI

If you’ve spent any time building with large language models, you’ve felt the tension: they’re brilliant at language, and occasionally too confident about facts. The more “enterprise” your use case becomes—policies, procedures, product catalogs, research, student records, regulated workflows—the more that gap matters.

This post is about the missing layer that closes it. Knowledge graphs give AI something it often lacks: a durable, explicit model of meaning and relationships. We’ll walk through what knowledge graphs really are, why they matter more now than ever, and how graph-based retrieval (GraphRAG) is changing what “good” looks like in modern AI.

Perfect AI Is the Wrong Standard: Automate the Happy Path and Take the Win

One of the most common complaints I hear about Artificial Intelligence—both from the public and from professionals—is some variation of: “It’s not 100% perfect.”

That reaction is understandable. But it’s also revealing.

In most areas of work, we don’t demand perfection. We demand progress. We accept that humans make mistakes, that processes have variance, and that edge cases exist. Yet the moment a workflow becomes automated—especially when it has “AI” stamped on it—many people quietly shift the standard to flawless execution.

Here’s what I want to do in this post: unpack why “100% perfect” is an unhelpful expectation for AI, and show why automating the happy path (the most common case) can deliver meaningful returns even if exceptions still require human attention.

The Chief Risk Officer’s Quiet Obsession: Data Platforms and Data Products

A Chief Risk Officer (CRO) at an FSS Corporation rarely wakes up thinking, “I can’t wait to talk about data architecture today.”

But they do wake up thinking about something that inevitably leads back to it:

Can I trust what we’re about to tell the Board, the regulator, and the market—especially when conditions get ugly?

That question is why the CRO cares deeply about your Data Platform and your Data Products. Not as “tech initiatives,” but as the machinery that turns risk from opinions and spreadsheets into repeatable, auditable decisions the business can stand behind.

In this post, I’ll connect the CRO’s mandate to the practical realities of platforms and products—and why getting this right is a risk control, not a nice-to-have. Along the way, you’ll see why risk management and operational resilience don’t live in policy binders—they live in data.