The Reference

Everything, organized by argument instead of by date.

A seven-chapter method and 47 essays on redesigning outcome-producing work systems for AI. The method tells you what to do. The essays are the evidence, the failure patterns, and the examiner’s reasoning underneath it.

All of it is free and none of it asks for an email address.

00 · The method

The AI Transformation Field Guide

Seven steps from understanding the real work to running a governed, improvable human–AI system. Read in order the first time.

  1. 01Understand the Work
  2. 02Decide What Should Change
  3. 03Redesign the Work
  4. 04Design the Human–AI System
  5. 05Prove It Works
  6. 06Govern It
  7. 07Operate & Adapt

01 · The examiner's eye

How to look at an AI program and see what is actually there.

Start here. Everything else in the reference assumes you can tell the difference between a program that is working and a program that is presenting well.

01

What a Bank Examiner Sees When They Look at an AI Program

Most AI teams see their program from the inside. An examiner sees it from the outside — and the view is different. Here's what I actually look at.

02

Why I Started Thinking About AI Like a Bank Examiner

The discipline I learned examining banks is exactly what AI programs are missing. Not bureaucracy. The actual discipline: evidence, accountability, traceability.

03

The Examiner's Checklist: What Financial Regulators Actually Look for in AI Governance

A former bank examiner explains what financial regulators actually look for in AI governance — documentation trails, named accountability, monitoring evidence, and the FS AI RMF's 230 control objectives.

04

Eight Questions That Tell You Whether Your AI Is Actually Governed

Most AI governance programs start and end with the model. Here are eight questions that cover the full surface. Most organizations can answer three.

05

Three Questions Every Executive Should Ask About Their AI Program

If an executive asked only these three questions in every AI briefing, they'd have more governance insight than most organizations generate with entire committees.

06

The Difference Between Monitoring and Watching

Every AI team says they monitor their models. When you ask what that means, the answer is almost always: there is a dashboard. That is not monitoring. That is watching.

07

What the Military Taught Me About Evaluating Systems Under Pressure

Before I was a bank examiner or an AI PM, I was an OC/T and Drill Sergeant. The gap between military evaluation standards and enterprise AI evaluation is enormous.

02 · How programs fail

The failure patterns, named. Almost none of them are technical.

Programs rarely fail because the model was weak. They fail at handoffs, in meetings, inside business cases, and in the gap between a demo and an operating model.

01

Your AI Pilot Worked. That's the Dangerous Part.

A successful AI pilot is one of the most dangerous things that can happen to an organization. Not because the technology doesn't work — it does. The danger is in what a successful pilot makes people believe.

02

Three AI Programs, Same Three Failures

Different organizations, different industries, different models, same three patterns. These failure modes show up so consistently they're practically a taxonomy.

03

Enterprise AI Fails at the Handoff, Not the Algorithm

The model worked. The problem was everything that happened after the algorithm was finished. Four teams. Four handoffs. At each one, context is lost.

04

The Meeting Where the AI Project Actually Dies

The project didn't fail when the model produced bad outputs. It failed five months earlier, in a conference room, during a meeting that lasted forty-five minutes.

05

The Business Case for AI Is Almost Always Wrong

The math always works on the slide. The math almost never works in production. The standard business case format was designed for deterministic investments. AI does not work like that.

06

The Vendor Demo Is Not the Product

The demo is designed to produce a wow reaction. It is not designed to show you what the product will actually do in your environment, on your data, at your scale.

07

Nobody Gets Fired for Buying AI. They Get Fired for What Happens After.

The procurement decision was unanimous. Eighteen months later, the system is live in name only. This isn't an edge case. This is the modal outcome.

08

How to Kill a Project That Leadership Loves

Adjacent to an enterprise AI program, I watched a project that everyone knew was failing. Everyone knew. Nobody said it. This is the hardest problem in enterprise AI.

09

The Question That Outlasts the Pilot

Every serious AI initiative eventually stops asking what the tool can do and starts asking what the organization can defend.

10

I Spent a Year Inside an Enterprise AI Program. Here's What I'd Do Differently.

A practitioner retrospective — the kind of honest accounting that usually happens over drinks at a conference but rarely makes it into writing.

03 · What governance actually is

Not an ethics statement. Applicability, controls, evidence, accountability.

The decision, not the system, is the unit of governance. These pieces work out what that means in practice — and what most governance programs produce instead.

01

Your AI Ethics Statement Is Not a Governance Program

Every major company published responsible AI principles this year. Beautiful PDFs. Professional design. And operationally meaningless.

02

If Your Governance Lead Quit Tomorrow, Would Your Controls Survive?

Five questions that expose whether your AI governance program is persistent or fragile. Most organizations score between 8 and 14.

03

The Org Chart Doesn't Have a Role for AI Governance

Find the person responsible for ensuring AI systems are governed throughout their lifecycle. You won't find them. The role doesn't exist.

04

The AI Inventory Problem: Most Companies Don't Know What They're Running

The first time most large enterprises try to build an AI inventory, they send an email. The response rate hovers around 30%. The teams that respond are the ones already doing governance well.

05

The Documentation Standard Nobody Follows — and Why It Matters

Ask an AI team if they document their models and they will say yes. Ask to see the documentation and you will get a README that has not been touched since development.

06

What Happens When Your AI Model Updates and Nobody Tells Compliance

The compliance team spent six weeks documenting an AI system. By the time they finished, the model it described no longer existed.

07

Stop Measuring AI by Accuracy. Start Measuring It by What Happens When It's Wrong.

Ninety-five percent accuracy on a loan approval system means one in twenty applicants gets the wrong decision. Accuracy tells you nothing about who bears the cost of the 5%.

08

Every Generative AI Deployment Has Exactly Three Risks

Hallucination, data leakage, and prompt injection. If your organization can't name the controls for each, you're not governed — you're hoping.

09

Why Your Data Scientists and Your Compliance Team Don't Talk to Each Other

The compliance team schedules a risk review. The data scientist shows up with performance metrics. The compliance analyst shows up with a checklist. For forty-five minutes, they talk past each other.

10

The Year AI Governance Got Real

At the start of 2025, AI governance was a conference-panel topic. By the end, it was a board-level agenda item. The shift happened because the consequences arrived.

04 · The data underneath

Readiness, pipelines, debt, maintenance. The part nobody demos.

Model quality is the visible layer. What decides whether a system survives contact with production is the layer underneath it, and the team willing to maintain it.

01

AI Readiness Is a Data Problem, Not a Model Problem

AI projects that stall tend to have the same root cause. It isn't the model. It's the data underneath it — the pipelines, the quality, the governance, the lineage.

02

The Data Problem Nobody Wants to Talk About Before the AI Demo

The demo looked great. Nobody in the room asked where the data comes from at 2am on a Tuesday. That question is where most AI programs live or die.

03

Data Pipelines Are Decisions. Treat Them That Way.

Nobody calls a meeting to decide how to handle nulls in the customer address field. These decisions get made at 4pm on a Wednesday and become load-bearing the moment someone builds on top of them.

04

What 'Production-Ready' Actually Means for AI

The gap between 'it works' and 'it's production-ready' is where AI projects go to stall. Nobody agreed on what 'ready' meant before the building started.

05

The Real Cost of Technical Debt in ML Systems

ML technical debt is quiet. The system runs. The metrics look green. And somewhere underneath, the foundation has shifted in ways nobody is measuring.

06

Most AI Teams Build. Very Few AI Teams Maintain.

The data science team builds a model. It ships. The team moves to the next project. The model runs in production. Nobody owns it. This is the default operating model for enterprise AI.

07

Building Best Practices in a Data Engineering Team That Didn't Have Any

Most data engineering teams don't have a best practices problem. They have a 'nobody ever stopped to write it down' problem.

08

Your AI Can Be Wrong Without Making a Single Reasoning Mistake

A smart system can reason perfectly from a bad premise. Once that premise survives as context, the cost is not just one wrong answer. It is figuring out how much downstream work you can no longer trust.

09

The Dashboard Is Green. Now What?

AI products can look healthy long before you know whether they actually helped anyone.

05 · Roles, authority, decision rights

Who decides, who answers, and where the boundary goes.

When AI enters a task, the authority around that task has to be redesigned too. These pieces are about the people and the org chart, not the model.

Talk about a work system

If you read three of these and recognized your own organization, that recognition is the useful part. The conversation after it costs nothing.

The fastest way to find out whether any of it is true about your organisation is to run one piece of real work through the instrument. It returns a call and then argues with it.