The AI Fluency framework: Delegation, Description, Discernment, Diligence

Most "how to use AI" advice is a pile of prompt tips: add this magic phrase, tell it to act like an expert, ask it to think step by step. The tips aren't wrong, but they don't add up to a way of thinking. A while ago I worked through Anthropic's AI Fluency: Framework & Foundations course, and what stuck wasn't a list of tricks — it was a small mental model that I now reach for every time I sit down to work with a model.

That model is the four-D framework: Delegation, Description, Discernment and Diligence. It was developed through a partnership between Anthropic and two academics — Rick Dakan of Ringling College of Art and Design and Joseph Feller of University College Cork — and it defines AI fluency as working with AI effectively, efficiently, ethically and safely. The four competencies are simply the muscles you train to get there. Here's how I read each one, and how it shows up in a data analyst's day.

The four D's as a loop, not a checklist — you cycle through them on every real task.

Why a framework beats a bag of prompt tips

Prompt tips are tactics with no strategy behind them. They tell you what to type without telling you when or why — so you collect dozens of them and still feel like you're guessing. A framework does the opposite: it gives you a small number of questions that apply to every task, regardless of which model or tool you're using. The four D's are exactly that. Before, during and after each piece of AI-assisted work, they ask: should AI even do this? Have I said what I want clearly enough? Can I trust what came back? And am I willing to put my name on it?

A prompt tip helps you with one message. A framework helps you with every message you'll ever send.

1 · Delegation — pick the right tasks

Delegation is the decision before the prompt: what should a human do, what should AI do, and how do you divide the work between you? It sounds obvious, and it's the step people skip most. The trap is handing AI the parts that need human judgement — defining the business question, choosing which metric actually matters — and keeping for yourself the grinding parts a model does well.

In my own work the split is fairly stable. I delegate to AI the first draft of a SQL query, boilerplate transformation code, reshaping a messy CSV, drafting documentation, or summarising a long thread of stakeholder emails. I keep for myself the framing — what we're actually trying to learn, which definition of "active customer" we're using, whether this number is even the right number to report. Good delegation is knowing that line and not letting convenience blur it.

2 · Description — say what you actually mean

Description is communicating intent so the AI can act on it. The course breaks it into three useful angles, and naming them changed how I write prompts. Product description is the output you want — the shape, format and content of the result. Process description is how you'd like it produced — the method, the steps, the constraints. Performance description is the manner — tone, role, level of detail, how the model should behave while it works.

Most weak prompts fail because they only do the first one. "Write me a SQL query for monthly active users" is a product request floating without context. The version that works adds process and performance: here's the schema and how a session is defined, exclude internal test accounts, use a CTE rather than nested subqueries, and explain any assumption you had to make. Description is just the discipline of supplying the context that lives in your head but not in the model's.

The pattern I use For anything non-trivial I write the prompt as three lines in my head: what I want (product), how I want it built (process), and how it should sound or behave (performance). If a result disappoints, it's almost always because I left one of the three unsaid.

3 · Discernment — judge what comes back

Discernment is the critical eye: evaluating outputs instead of accepting them at face value. It mirrors Description with the same three lenses. Product discernment asks whether the answer itself is accurate, complete and fit for purpose. Process discernment looks past the answer to the reasoning — is the logic sound, the method appropriate, the evidence real? Performance discernment watches the interaction itself — is the model actually helping, following instructions, behaving sensibly?

For a data analyst this is the non-negotiable D. A model will hand you a query that runs perfectly and quietly joins on the wrong key, double-counting half your revenue. The SQL is syntactically flawless; the logic is wrong. Product discernment alone would pass it. Process discernment catches it — you read the join, you sanity-check the row counts, you reconcile the total against a number you already trust. Confident output is not correct output, and the gap between them is exactly where discernment earns its keep.

Low discernment

"The query runs, ship it."
Trusts the explanation because it sounds fluent
Copies the chart without checking the totals
Finds out at the board meeting

High discernment

Reads the join keys and grain
Reconciles against a known-good number
Asks the model to show its assumptions
Catches the error before anyone sees it

4 · Diligence — own the outcome

Diligence is the responsibility wrapped around everything else: using AI ethically, safely and accountably. It also comes in three parts. Creation diligence is choosing the right system in the first place — does this tool suit the task, and is it appropriate for the data I'm about to put into it? Transparency diligence is being honest about where AI was involved, so colleagues and stakeholders can weigh the work fairly. Deployment diligence is accepting that the output is yours: if an AI-assisted report goes out under my name, the responsibility for it is mine, full stop.

In practice this is where data work gets serious. I don't paste customer-identifying data into a tool that isn't approved for it — that's creation diligence and data governance meeting in the same decision. When a dashboard's commentary was drafted with AI help, I'm comfortable saying so. And I never let "the model wrote it" become an excuse for a number that turned out wrong. Accountability doesn't get delegated.

You can delegate the typing. You cannot delegate the accountability.

Putting the four together

The D's aren't a one-time checklist; they're a loop you run on every real task. A typical analysis cycle looks like this:

Delegate — decide which parts of the analysis are mine to frame and which the model can draft, and resist handing over the judgement calls.
Describe — give it the schema, the definitions, the method I want and the format I need, covering product, process and performance.
Discern — read the output and the reasoning, reconcile against numbers I already trust, and push back where it's thin or wrong.
Diligence — confirm the tool was right for the data, note where AI helped, and stand behind the result before it ships.

What I like about the four D's is that they're tool-agnostic and they age well. Models will keep getting better; the prompt tricks that matter today will be obsolete in a year. But "decide the right split, describe clearly, judge critically, own the outcome" is durable. It's the difference between someone who can coax a clever answer out of a chatbot and someone who can fold AI into serious work without quietly breaking trust in the data.

If you want the full version from the source, the framework lives on Anthropic's AI Fluency site, with the original course also available on Coursera. I completed it earlier this year — it sits with my other certificates on my Learning page — and I'd recommend the few hours to anyone whose job is starting to involve a model in the loop. Not because it teaches new tricks, but because it gives the tricks somewhere to hang.