Strategy – EduDataSci – Educating the world about data and leadership

Stop Settlement Fails Before They Start

At 9:42 a.m., an institutional equity trade executes normally. There is no break and no exception to repair.

By 2:00 p.m., the picture has changed. The client’s allocation is later than usual. The standing settlement instruction (SSI) on one record does not agree with the custodian’s current instruction. Securities expected from another account have not arrived. A routine counterparty acknowledgment is still missing.

None of those facts proves that the trade will fail. Together, they say that the trade is becoming harder to settle.

The traditional operating model waits for a definite exception, places it in a queue and asks an operations analyst to reconstruct what happened. A prevention model starts earlier. It watches the trade’s full lifecycle, recognizes a risky pattern, applies the firm’s control rules and intervenes while useful choices remain.

This is not a proposal for a better exception queue. It is a different job for operations: prevent avoidable failures, resolve safe and bounded issues automatically, bring judgment-heavy cases to the right expert, and remove recurring defects from the upstream process.

When Software Becomes Disposable: Why the Next Data Mesh Needs Action-Oriented Data Products

Something important changes when intent becomes the front door to software. If a banker, underwriter, advisor, claims lead, or merchant-risk analyst can ask for a task-specific application and receive it in minutes, then bespoke software stops being rare. It becomes cheap. The expensive thing is no longer the application layer. The expensive thing is the interface to truth: the boundary where customer data, authorization, business policy, and systems of record meet.

That shift deserves a different architectural response. I like to frame a data product as reusable, trustworthy, contract-driven, loosely coupled asset with clear ownership, explicit promises about freshness and meaning, and a versioned surface consumers can rely on. The data mesh tradition adds domain ownership, self-serve platform capability, and federated computational governance. My ingest-transform-surface model sharpens the picture further: inputs are explicit, transformation is deliberate, and the published surface is the contract. All of that is right. It just is not enough once agents and intent-driven tools begin to mediate real work.

Domain APIs need to become the front door for fit-for-purpose apps, and the mesh becomes the process glue that turns operational data into analyzable insight and analytical insight into operational action. My argument is that we should now make that shift explicit. The next mesh should be built from Action-Oriented Data Products: domain-owned data products whose interfaces declare not only what can be read and analyzed, but what can be done, by whom, for what purpose, with which guardrails, and against which authoritative source.

This is not a new name for old API management. It is a claim about the next architectural quantum. Data mesh already argued that the data product is the quantum of the analytical estate. In an intent-mediated world, that quantum must become action-oriented. The mesh stays. The node changes. To make that case, I want to do three things: show why current data products stop short, explain the historical parallels to object orientation, microservices, and data mesh, and define the architecture that lets agents discover and manipulate data safely.

One Agent, Several Kinds of Truth

An enterprise agent rarely fails because it cannot produce a fluent paragraph. It fails because it cannot distinguish the current balance from the definition of balance, the approved policy from the email that discussed an exception, or the authority to explain a decision from the authority to change a system of record.

That distinction matters in financial services. A relationship manager asking why a commercial borrower has become riskier is really asking several questions at once. What changed in the borrower’s accounts? How does the exposure roll through facilities, collateral, guarantees, and legal entities? What does credit policy require? What did the deal team agree to last week? If action is warranted, who may open a review, request documents, or change a limit?

No single knowledge source can answer all of that honestly. The useful architecture is a Copilot Studio agent that coordinates several bounded kinds of intelligence: Fabric IQ for business state, Foundry IQ for institutional knowledge, Work IQ for the user’s working context, an ontology for shared meaning, and MCP tools for controlled action. API Center anchors design-time inventory and discovery, while Microsoft Purview anchors data governance and supported AI-interaction compliance. Runtime enforcement remains with Entra, Power Platform data policies, native IQ permissions, API Management, and the source systems.

The Client Passed KYC. Why Can’t They Trade?

“Can the new fund trade on Monday?” should be an easy question.

The relationship manager knows the asset manager. The client record is active. KYC is complete. Legal has a signed agreement, and credit has approved a limit. Every team appears to have done its part.

But operations is still opening an account. A tax form is attached to the parent company rather than the fund. The agreement covers the right legal entity but not the requested product in that jurisdiction. A market permission has not reached the entitlement system. On Friday afternoon, every function can report that its task is complete—or at least within its service level—while the client still cannot place a trade.

No single system is necessarily wrong. Each system is answering a smaller question than the client asked.

This is the gap that process mining can address. The technology is often discussed in connection with claims automation, where it can identify slow routes, repeated work, and unnecessary handoffs. Those are useful applications. But the same method can be even more valuable in financial-markets onboarding, where one commercial outcome depends on several functions and systems agreeing at the same time.

The goal is not merely to complete KYC faster. It is to make the client usable—safely, lawfully, and with a clear record of how that decision was reached.

Every Decision Should Make the Next One Better

A manufacturer asks its bank for a $3 million increase in a working-capital line before a supplier’s pricing window closes. The relationship manager sees an established client and a time-sensitive opportunity. The application treats the request as another file to assemble. A decision engine uses the credit model’s output to route it to manual review. The underwriter asks for another forecast. Operations measures every handoff against its service level.

Everyone performs their function. The bank still answers too late.

The remedies sound obvious. Simplify the application. Improve the model. Remove steps from underwriting. Each may help. Yet a cleaner application can still lead to a poor credit decision, a more accurate model can produce a recommendation no one knows how to use, and a faster process can move uncertainty downstream.

Design thinking identifies the human problem worth solving. Decision science makes the choice, uncertainty, economics, and constraints explicit. Improvement science determines whether the change works reliably—and under which conditions.

Used together, the three disciplines improve the immediate decision and preserve the evidence needed to improve the next one.

When Everyone Can Build, the Specification Becomes the Control Plane

One of the easiest mistakes in the current AI cycle is to treat vibe coding as a developer-productivity story.

It is certainly that. A developer can use an agent to explore a repository, create a plan, write code, run tests, and open a pull request. But the more important change is happening outside the traditional development organization. A claims analyst, credit-policy manager, operations lead, product owner, or adviser-support team can increasingly describe a problem and receive a working application, automation, or analytical tool in return.

OpenAI reported in June 2026 that knowledge workers represented about 20 percent of Codex users and were increasingly using it to build lightweight tools that previously required engineering support. That is one vendor’s usage data, not a census of enterprise development, but it captures the direction: the boundary between understanding a business problem and being able to build software around it is getting thinner. OpenAI: Codex for knowledge work

That changes the control problem.

The old governance model assumed that code entered through an engineering workflow, where developers, architects, security teams, and reviewers could resolve what the requirements left unclear. Democratized development weakens that assumption. The answer is not to force every useful idea back through the old bottleneck. It is to move the primary control point earlier—from reviewing code after it exists to governing the specification that tells people and agents what may be built.

When software creation is democratized, the specification becomes the enterprise control plane.

This post explains why spec-driven development has become much more important, what changed in the tooling during 2025 and 2026, and what a fully integrated enterprise specification should contain. The goal is not more paperwork. It is executable clarity before autonomous execution.

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.