How I Brief AI With the CASE Framework

The prompt is the brief

When it comes to producing the best outputs from AI, I believe it boils down to two things: context engineering and prompt engineering. The quality of the context and the quality of the prompt will often determine the quality of the output.

I follow a process for each. Context engineering uses what I call a Context Vault. I think of a Context Vault as a lock and the prompt as the key.

A vault full of your frameworks, stories, and voice rules does nothing until a prompt opens it. And a prompt with nothing behind it opens an empty room.

So what is a prompt, really? It’s the brief you hand the AI for one specific piece of work. It isn’t a strategy document or a permanent asset. You build it for the task in front of you, run it, get the output, and move on. The template you refine over time stays. The prompt itself is disposable.

Here’s the part most people miss. The prompt is the only place your intent shows up. The vault holds your material and the model holds the language skill, but the prompt is where you decide what happens next. That’s where positioning gets switched on, or quietly left off.

The four parts of a CASE

CASE stands for Context, Action, Specifications, and Expectations. Each part does a different job, and each one pulls from a different source.

Context: the situation

Context is the situational brief. Who’s the audience for this piece? What’s the deliverable? What happened before this prompt that the AI needs to know to act sensibly?

While the Context Vault is the pool of information the AI model works from, in this CASE (pun intended) context refers to the task at hand. It’s any of the 5Ws behind the task you’re prompting your AI (who, what, when, where, and why).

Context tells the AI where to look. If you’ve built a Context Vault, point the AI at the specific slice that matters for this task. “Use my vault, especially the FORCEPS notes and the hospital story” beats “use my vault” every time. A directed pointer keeps the AI reading from your reality instead of improvising one.

Action: the task

Action is the directive and deliverable. Draft, critique, summarize, restructure, compare, score, audit. Name it in one word if you can, and attach the shape of what you want back.

“Make this better” isn’t an action. “Tighten the opening so the buyer feels diagnosed in the first sentence” is. The specificity is the point, because a vague verb sends the AI straight to the median version of the task.

Specifications: the criteria

Specifications are the parameters and constraints. Length, tone, format, what to include, what to avoid. Mine say things like “no em dashes,” “no colons in titles,” “active voice,” and “lead with the bottom line.”

These rules belong to you, not to the task. That’s why they travel from prompt to prompt. Write them once into a template and you stop fighting the same battles every session.

Specifications are also where your frameworks get enforced. A LinkedIn post about credibility should name FORCEPS as the proof framework. A sales call analysis should name OATH for buyer awareness. A website audit should name QUEST so the AI walks the page through Qualify, Understand, Educate, Stimulate, and Transition. Naming the framework keeps the AI inside your thinking instead of drifting into someone else’s.

Expectations: the result

Expectations are the outcome and the precedent. They tell the AI what a win looks like. Sometimes that’s an outcome: “this proposal has to help close the deal,” or “my CEO should be able to read this in two minutes and decide.” Sometimes it’s a standard the output has to clear.

The strongest way to set an expectation is to show one. Paste in a past post and the AI picks up your rhythm. Paste in a past critique and it picks up your critique style. Paste a screenshot of a table or chart you like and the AI picks up the style and format.

Those examples don’t have to be your own work, either. A competitor’s page you want to beat, a peer’s post that hit the angle you’re after, a spreadsheet layout, a screenshot, a transcript. Anything that says “do something like this” belongs here.

There’s one rule I hold myself to. An example has to be good. A mediocre example anchors the AI to mediocre output, so I keep a small library of strong examples organized by task type.

One more thing. For decades I’ve taught that implication beats specification when humans are reading. With AI, it flips. The model needs the demonstration, which is why the best expectations come with an example attached.

Why I dropped the R

CASE is the second name for this framework. The first was RACES: Role, Action, Context, Examples, Specifications. I taught RACES in workshops, on podcasts, and in masterclasses through 2025 and early 2026, and plenty of people learned the discipline through it.

Three things changed my mind.

The first was evidence. A study by Zheng and colleagues, published in Findings of EMNLP 2024, tested 162 personas across 2,410 factual questions on four families of language models. Adding a persona to the system prompt didn’t improve performance compared with no persona at all. That matched what I was seeing. “Act as a senior consultant” gave the model a costume to wear, and the costume pulled attention away from the work.

The second was the name itself. CASE explains what you’re doing the moment you say it: you’re making a case for the AI to act on. RACES was a sport that needed a backstory.

The third was practical. RACES kept getting misheard in dictation, voice notes, and transcripts, landing one sound away from a word I’d rather not be associated with. CASE fixed that.

Dropping Role also gave me a better order. Context first is how anyone briefs anyone. Then the task, then the constraints, then what good looks like. It reads top to bottom the way a good brief should.

The senior partner and the paralegal

I use a legal analogy for this, because it’s the closest human version of briefing an AI.

A senior partner doesn’t do the research. The paralegal does. But the partner decides what the case is about, what to produce, what standards the firm holds, and which precedents matter. A vault without a brief is a partner who never tells the paralegal what to research. A brief without a vault is a partner who never handed over the file.

CASE maps onto that relationship. Context is the case file. Action is the assignment. Specifications are the firm’s standards. Expectations are the outcome the partner needs and the precedents that show it, both the firm’s own past cases and the rulings worth following from the broader field.

You don’t type every word anymore. The AI does. But the judgment, the standards, and the voice still belong to you, because they’re what went into the brief.

What a weak prompt costs your position

Why does this matter beyond getting better drafts? Because weak prompts slowly erode a position.

A prompt like “write a LinkedIn post about positioning” pulls the AI toward the average of every post on that topic it has ever read. The average isn’t your voice or your point of view. It’s the middle of the pack, and the middle is where everyone else already lives.

A position sits at the edge of that distribution. That’s what makes it a position. So a weak prompt asks the AI to do the exact opposite of what your positioning was built to do.

The damage is gradual, which is what makes it dangerous. The first drifting post reads fine. By the fifth, it feels generic. By the tenth, your audience is reading content anyone in your category could have published. Nothing collapsed. It just diluted, one weak prompt at a time.

Every part of CASE pushes back against that pull. Skip one and you let the AI fill that slot with the average. Use all four and the position holds across the volume, with your fingerprints intact.

A CASE prompt, side by side

Here’s what the difference looks like on the same task.

The weak version:

"Write a LinkedIn post about why proof matters in B2B sales."

The CASE version reads more like this.

The audience is founders of expert-led consulting firms who rely on referrals, and you should use my FORCEPS notes and the client story about the stalled proposal from my vault (context). Draft one LinkedIn post (action) under 200 words, first person, no em dashes, open with the story, organize the proof points with FORCEPS, end with a question (specifications). The post should get a founder to reply with their own stalled deal, and attached are two of my past posts that did that, plus one competitor post whose structure I want to beat (expectations).

Same model. Same task. One gets the average, and the other gets you.

Where each part comes from

Each slot pulls from a different source, which is why CASE works as a system and not just a checklist.

Context comes from two layers: the task you’re doing right now and the vault you’ve built over years. Action comes from your intent, which means thinking through what you want before you type. Specifications come from your standards and your frameworks. Expectations come from your goals, your body of work, and the outside work you admire.

If you’ve built a vault, Context takes seconds. If you haven’t, you’ll rewrite your background from scratch every time, and you’ll leave out most of what you know. That’s a big part of why I treat the vault and the brief as one working unit, and it’s the core of the AI Amplifier model.

Use it as a guide, not a goal

I’m deliberate about what CASE is and isn’t. It’s a framework for the structure of a brief. It isn’t a recipe for a specific tool, model, or prompt app.

The recipe layer changes every quarter. Models get replaced, interfaces shift, new features show up. The structure of a good brief doesn’t change. Learn CASE once and you can open any new AI tool and know within the hour where the Context, Action, Specifications, and Expectations go.

That’s the portable skill. The tool-specific tricks are disposable.

The name is the position

I’ve built a handful of named frameworks over 35 years, including FAME, OATH, QUEST, FORCEPS, and IDEAL. They all started the same way. My ADHD brain needs structure to hold a multi-part idea, and an acronym gives it one.

The side effect came later. The names help clients carry the ideas too, and a named framework can be referenced while an unnamed one can only be described. References compound across people. Descriptions don’t. That’s the same logic I write about in brandifying instead of branding.

CASE was named with that in mind. The meaning is baked into the letters, the legal frame carries the analogy, and it survives dictation. It’s the same principle at the heart of Power Positioning, applied to the framework’s own name.

---

Frequently Asked Questions