Choosing Defensible Inputs

You don't need to write code to shape whether an AI-informed decision is sound. What you do need is the confidence to ask about the ingredients: what information the system is allowed to look at, what a score actually promises, and what a pattern does and does not prove. That is where most avoidable damage happens, and it happens in conversations you are already in.

Across this course, you will play the same role — Director of Business Operations — across four different conversations.

By the end of this course, you'll be able to:

• Choose and defend the inputs a decision is allowed to use, screening out hindsight information and stand-in proxies
• Read a confidence score for what it does and does not promise, and decide which cases must wait for a person
• Separate a pattern that anticipates an outcome from a cause you can actually act on

This first lesson starts with the input list, because almost every problem later in the course traces back to something that should never have been on it.

In this lesson, you will learn to:

• Explain what an input is and why the input list shapes a decision.
• Screen inputs for relevance, availability at decision time, appropriateness, and defensibility.
• Recommend a smaller, defensible list with a reason for every removal.

An input is simply a piece of information the tool is allowed to look at when it makes its call. Nothing more mysterious than that. If you were handing a new team member a single sheet of paper before they made a judgement, the input list is what's printed on that sheet.

In machine learning, choosing which of these inputs the model should use is often called feature selection. For a business leader, the important question is not the technical selection method, but whether each input deserves to be there.

Here's the part that surprises people. The list matters more than the tool. A genuinely capable system fed the wrong sheet of paper will give you a fast, confident, well-presented wrong answer, and it will keep doing it at scale. Meanwhile a modest tool with a thoughtful, well-chosen list will quietly earn its place. So when a data team walks you through a proposal, the question that gets you the furthest is not how good the model is. It is: "Show me the list of things it's allowed to look at."

Here is how that question sounds when Milo, the engineer proposing the build, walks the input list past Ryan, the business partner who must sign off on it:

• Milo: The build's ready to go. We're feeding it every field we hold on the account, about ninety of them.
• Ryan: Before we do that, can you read me the list? Not the model, just what it's allowed to look at.
• Milo: Why does that matter more than the model? It's a strong model.
• Ryan: Because the model can only reason about what's on the sheet. If half the sheet is noise or things we shouldn't be using, a strong model will just be confidently wrong faster.
• Milo: Fair. I've never actually read the ninety out loud to anyone.
• Ryan: That's the test. If you can't read it out loud comfortably, it isn't finished.

Notice what Ryan did: he didn't challenge anyone's competence. He just asked for the list to be spoken aloud, which is usually enough to expose the problem on its own.