TIDD-EC Prompt Framework: Do, Don't and Precise Instructions

Study guide

TIDD-EC: prompts with strict boundaries that hold

Some prompts can be loose because a weak answer costs nothing. A brainstorm, a rough draft, a subject line you will rewrite anyway. Other prompts carry real weight. A reply to a patient, a refund decision, a clause summary, a note in a personnel file. In those cases a confident wrong answer is worse than no answer at all, and a vague instruction like be careful gives the AI nothing concrete to follow. This course teaches TIDD-EC, a six part framework that makes your boundaries explicit and impossible to miss. Task type, Instructions, Do, Don't, Examples, Context. Each part answers a different question, so nothing important is left to chance.

The framework is built for people who work with rules. Legal teams, HR advisers, finance analysts, clinicians and support leads, and anyone whose written output may be read by a regulator, a customer or a court. You will learn why the Do and Don't lists carry the real strength of the framework, how to write each rule as something you can tick off against a finished answer, and how to attach a reason to every Don't so the AI generalises your limit to questions you never thought to list. Every lesson includes a worked example from a real job, a common mistake, and the exact wording to reuse. No technical background is needed. If you can write a short list of rules for a new colleague, you can build a TIDD-EC prompt.

What is a prompt framework?

A prompt is the request you type into an AI tool such as ChatGPT, Claude or Gemini. A prompt framework is a reusable structure for that request: a short checklist of the parts a good prompt contains, usually named with an acronym so it is easy to remember. Why it helps: the AI fills in whatever you leave out with generic guesses. A framework makes sure you include the parts that change the answer, such as who it is for, what you want to achieve and the format you need.

Frameworks make prompts repeatable: you fill the same parts each time, save the prompt as a template and share it with colleagues. They are not magic words: the value comes from the detail you put in each part. They help most when a request is complex or open to interpretation; a quick, simple question can stay short. There are well over sixty named frameworks, and most of them remix the same ingredients: role, task, context, audience, format, constraints and examples.

In this course you learn TIDD-EC, which is a fill-in-the-slots framework: an acronym where each letter stands for one part of your prompt. It is best for: compliance-heavy and high-precision work in legal, HR, finance, healthcare and support.

Why explicit boundaries belong in a prompt

TIDD-EC stands for Task type, Instructions, Do, Don't, Examples, Context. The first letters name the six parts, and each part answers a different question. What kind of work is this. What steps should be followed. What must happen. What must never happen. What does a good answer look like. What situation and source documents does it rely on. When all six are present, the model is not guessing about any of them, which is what makes the framework reliable in work where a wrong answer has a cost.

The real strength sits in the explicit Do and Don't lists. A Do list states what must happen, such as quote the clause number and use the customer's name. A Don't list states what must never happen, such as no legal advice, no promises of timelines, no speculation about causes. Together they form a fence around the answer. The fence is not there to make the AI cautious or unhelpful. It stops the model from admitting fault on the company's behalf, inventing a number, or sharing details that should stay private, while leaving drafting, summarising and rewording fully open.

Boundaries only work when they are specific. Do not admit fault is clear and testable. Be careful is not, because it gives the model nothing concrete to follow and nothing for you to check. Use this framework where a mistake carries weight, such as legal wording, medical information, financial statements or HR decisions. In low stakes drafting, a lighter prompt is often enough, and adding six sections of rules just slows you down.

Task type and Instructions: set the approach and the order

Task type is the category of work you want. Classification, summary, reply, extraction, rewrite. Naming it first tells the model which approach to take before it reads any detail, and the label changes the output even when the source text stays exactly the same. Ask for a summary and the model compresses the document. Ask for extraction and it pulls out the named items and ignores the rest. Put the task type at the top of the prompt, before the source text and before the steps, because the model reads top down and uses the first line to set its approach.

Instructions are the specific steps or guidelines to follow. Number them when order matters, because numbered steps are followed in sequence and fewer get skipped. A three step instruction such as identify the clause, quote it word for word, then explain it in one plain sentence keeps the model from jumping straight to the explanation and losing the quote. State the output shape at the end of your instructions, such as a three column table or a short list of no more than five bullets. Without a stated shape, the format drifts from run to run and you end up reformatting by hand.

The most common mistake in this part is mixing two task types in one ask. Summarise this contract and also draft a reply to the client sounds efficient, but the output splits and each half gets thinner. Run one task type per prompt, then follow up with a second prompt for the next job. The second prompt can carry the first answer as its source text, so nothing is lost and each task gets the model's full attention.

Do: the must-haves, written as checkable rules

The Do section holds the must-haves of your prompt, the items the answer cannot skip. In a billing dispute example, the Do list might be quote the clause number, use the customer's name in the opening line, and end with the next step and its deadline. Each of those is a checkable rule, which means you can tick it off against the finished answer. Quote the clause number is checkable. Be professional is not, because there is nothing to tick. If you cannot point at the part of the answer that satisfies a rule, the rule is not written yet.

Turn vague wishes into rules by naming the exact behaviour. Instead of make it personal, write use the customer's name in the opening line. Instead of keep it short, write no more than 120 words. Instead of be accurate, write every figure must appear in the source text. The rewrite takes an extra minute and saves a review cycle, because the model now knows precisely what to produce and you know precisely what to look for.

Keep the list short. Five strong rules beat fifteen weak ones, because a long list buries the items that really matter and spreads the AI's attention across trivia. If the finished answer misses one of your Do rules, the answer is not done. The rules are your acceptance test, not a set of suggestions. And remember that Do is only one part of TIDD-EC. It works best when the Task and the Context are already clear, so the rules have something solid to attach to.

Don't: forbidden behaviours, each with a reason

Don't is the fourth letter of TIDD-EC and it lists the forbidden. No legal advice. No promises of timelines. No speculation about causes. It sits next to the Do list, which names what must happen, and between them the model knows both edges of the path. Build the list from errors you have actually seen. A rule that traces back to a real mistake is specific and testable. A rule invented for a risk you have never met just adds noise and dilutes the ones that matter.

Always attach a reason to a rule. Current models generalise from the reason, so no legal advice, because patients need a qualified professional, also blocks a reworded question you never listed. Reasons turn a rule into a principle. No promises of timelines, because only the care team knows release dates, tells the AI how to behave when a patient asks about a follow up appointment instead of asking about a release date. Without the reason, the model follows the letter of the rule and misses the point of it.

Keep the list short. Three to six rules that matter beat a page of vague warnings. If everything is forbidden, the AI has no room to draft and the real limits get buried among the noise. A Don't list does not make the AI less useful. It fences off risk while leaving drafting, summarising and rewording fully open, so the answer is safe to send and still does the work you needed.

Examples and Context: shape and facts, kept apart

Examples show the AI what a compliant answer looks like. One good example is often enough, because it fixes format, detail and tone at the same time. If your team has a reply that passed review last month, paste it in and label it as the shape to follow. Keep the example short. A long example tempts the AI to copy it rather than follow its shape, and it can crowd out the context that should be doing the real work.

Context gives the situation and the source documents the answer must rely on. Name the audience, the reason for the request, and the policy, contract or notes to use. Paste the source text or name the file clearly. If the context is buried in a wall of text, key facts get missed or mixed together, and the model fills the gaps with something plausible. Short labelled fields are easier to complete and harder to leave incomplete.

The honesty line matters most of all. Tell the AI to say I don't know when the context does not contain the answer, so a gap becomes a signal instead of a confident guess. E and C work as a pair. The example sets the shape, the context supplies the facts, and the honesty line keeps the two apart. Without it, the model will borrow facts from the example to fill a hole in the context, which is exactly the failure this framework exists to prevent.

TIDD-EC in your job: a reusable, reviewed template

Choose the template target by risk, not by volume alone. A reply you write daily but that carries low stakes wastes the effort. A monthly claim or refund letter with legal weight repays a template many times over. High-risk recurring reply is the phrase to remember when choosing. Build the first template for that one reply, then let the pattern spread to the others as you see which ones keep coming back.

A Don't rule is strongest when it comes from a real correction. Each complaint, edit or escalation about a reply is evidence of a failure mode, and writing it as a short negative instruction stops the AI repeating it. This turns team mistakes into reusable guardrails instead of one-off fixes. Add the final check line as the last line of the template, asking the model to confirm every Do is met and no Don't is broken before it answers. You then get a draft that has already been compared against your rules.

A colleague review catches what you cannot see. You wrote the rules, so you read them as intended, not as written. A reviewer checks whether each Do is observable and each Don't is specific, which is the difference between a personal prompt and a team standard. Version the template like any other work document. When a new mistake appears, add a Don't rule and note the date. Over time the template becomes a record of everything your team has learned about that reply, which is institutional memory in one prompt. Keep the Context slot as a fill-in form with short labelled fields such as decision, reason, amount and next step, so it stays quick to complete and reusable across cases and colleagues.

Frequently asked questions