Generative AI – 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.

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.

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.

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.

The AI Knowledge Layer Banks Can Actually Govern: Why Azure Foundry IQ Matters to the CTO, CRO, and CISO

Financial services didn’t get cautious by accident. Banks, insurers, and capital markets firms have learned—repeatedly—that the fastest way to turn a promising innovation into a headline is to let it outrun governance.

GenAI is no different. In most institutions, the gap isn’t “we don’t have models.” The gap is that we don’t have a trusted, permission-aware way to ground agents on enterprise knowledge—without quietly bypassing entitlements, data classifications, and audit expectations.

In this post, I’ll lay out what Azure Foundry IQ (Microsoft’s current naming is Foundry IQ inside Microsoft Foundry, formerly Azure AI Foundry) actually is, why it should matter to CTOs, CROs, and CISOs, and how its value shows up in business outcomes, business risk avoided, and compliance risk—specifically in Financial Services.

Beyond Automation: Using SAMR to Explain AI Value in Property & Casualty Insurance Services

Most conversations about AI in property and casualty insurance start with the same promise: “faster, cheaper, smarter.” But in practice, the real question is where AI is being used.

Is it just doing the same work a little quicker… or is it changing the way underwriting, claims, and loss control actually run?

One of the cleanest ways to explain that difference is to borrow a framework from education technology: the SAMR model—Substitution, Augmentation, Modification, Redefinition—originally articulated by Ruben Puentedura. In SAMR, the first two levels are typically “enhancement” and the latter two are “transformation,” because they represent meaningful redesign (or reinvention) of the work itself.

In this post, I’ll map SAMR to the kinds of operational and strategic value AI can create across P&C insurance services (intake, underwriting, claims, fraud, and risk/loss services), staying away from customer chatbots and focusing instead on business process change that actually moves KPIs. Along the way, I’ll flag where AI and Insurance leaders tend to underestimate the “operating model” work required to reach the top of the SAMR ladder.

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.

Straight Through Processing for Documents: When “Touchless” Becomes the Cost-Saving Feature

Most organizations don’t drown in documents because they lack OCR.

They drown because every document creates work-in-the-middle: a person opens an email, downloads an attachment, checks a value, rekeys it into a system, compares it to a second system, and routes it to a third. Multiply that by thousands of invoices, claims, onboarding packets, and compliance forms, and your “document workflow” turns into a labor model.

That’s where Straight Through Processing (STP) comes in.

In this post, I’ll lay out what STP actually means, why it’s the most practical way to think about cost reduction in document-heavy operations, and what “STP-ready” AI document automation requires beyond basic extraction—without anchoring the conversation to any single vendor.