Your reference for clarity in the age of AI

Role, Goal, Constraints

Open by stating who the model is acting as, what outcome you want, and the hard limits it must respect.

Use this as the default scaffold for any non-trivial request. A model with no stated objective optimizes for a plausible-looking answer rather than your actual goal. Naming the role narrows vocabulary and assumptions; naming the goal gives a target to satisfy; naming constraints turns vague preferences into checkable rules. Together they collapse a wide space of valid-but-wrong responses into the narrow band you wanted.

You are a contracts reviewer. Goal: flag clauses that expose us to uncapped liability. Constraints: cite the clause number, do not rewrite the contract, keep each note under 30 words.

Watch for: A grand role with no concrete goal or constraints is theater — the role alone changes tone, not correctness.

See also: Assign a Persona, Define Done, Name the Audience

Show, Don't Tell

Include one worked example of the input-to-output transformation you want instead of describing it.

Use this when the desired output has a shape or style that is easier to demonstrate than to specify, which is most of the time. A single exemplar communicates formatting, tone, granularity, and edge-case handling that paragraphs of instructions leave ambiguous. Models tend to match a concrete example more reliably than they parse prose rules, so one good demonstration often beats a page of description.

Rewrite headlines to be concrete. Example: 'We improved performance' -> 'Page loads dropped from 4.1s to 0.9s'. Now do: 'We enhanced the onboarding experience.'

Watch for: A single example can over-anchor the model to its surface details; vary your exemplars when the real inputs will vary.

See also: Provide a Template, Specify the Output Format, Provide Reference Text

Specify the Output Format

State the exact structure you want back — JSON, table, bullet list, headed sections — and its fields.

Use this whenever the output will be read by a program, pasted into a system, or compared across runs. Unspecified format is a common source of correct-but-unusable answers. Pinning the schema makes outputs parseable, comparable, and reviewable, and forces the model to commit to a finite set of fields rather than rambling. Specifying format also implicitly specifies scope: a three-column table cannot hide a missing column.

Return only valid JSON: {"risk": "high|medium|low", "reason": string, "clause_ref": string}. No prose before or after.

Watch for: Demanding rigid structure for genuinely exploratory questions can amputate useful nuance the format has no slot for.

See also: Provide a Template, Define Done, Use Delimiters

Assign a Persona

Cast the model as a specific kind of expert or reader so it adopts that frame's priorities and vocabulary.

Use a persona when the same facts should be filtered through a particular professional lens — a skeptical auditor, a patient teacher, a hostile reviewer. The persona acts as a compression key for a whole set of expectations about what matters, what to check, and how to phrase things, which is faster than enumerating those expectations. It works by activating a coherent cluster of conventions the model already represents.

Act as a skeptical peer reviewer for a statistics journal. Find the weakest claim in this abstract and explain why a reviewer would reject it.

Watch for: A persona shapes tone and emphasis but does not grant knowledge — 'act as a doctor' does not make medical facts more accurate.

See also: Role, Goal, Constraints, Name the Audience, Set the Reading Level

Permit 'I Don't Know'

Explicitly allow the model to say it is unsure or lacks the information rather than answering anyway.

Use this on any factual, retrieval, or high-stakes question. The default conversational pressure is to produce a fluent answer even when grounds are thin. Granting permission to abstain raises the bar for asserting, which trades some coverage for a large gain in trustworthiness. It converts a confident fabrication into an honest gap you can then go fill.

If the answer is not stated in the document above, reply exactly 'Not stated in the source.' Do not infer or guess.

Watch for: Without a concrete abstain instruction the model may treat 'I don't know' as failure and still confabulate; make the escape hatch explicit and easy.

See also: Provide Reference Text, Cite Your Sources, Define Done

Lead With Context

Put the background, materials, and situation before the instruction that acts on them.

Use this when the task depends on supplied material — a document to summarize, data to analyze, a thread to answer. Front-loading context establishes the frame before the model reaches the instruction, so the ask is interpreted against the right backdrop rather than the model's generic priors. It also keeps long reference material from burying the actual request, which you place last where it lands clean.

[Full support transcript pasted here] Using only the conversation above, write the three-sentence resolution summary the agent should log.

Watch for: Leading with context fails if you never separate it from the instruction — without delimiters the model may treat your background as something to answer rather than use.

See also: Use Delimiters, Provide Reference Text, One Task Per Prompt

Name the Audience

Tell the model who will read the output and what they already know.

Use this whenever the same content could be pitched at very different levels — a board, a beginner, a regulator, a child. The audience determines what to assume, what to define, what to omit, and how much to hedge, and the model cannot calibrate any of that without it. Naming the reader resolves a dozen tacit decisions at once and prevents the safe-but-useless middle register the model defaults to.

Explain this database migration risk for a non-technical product manager who knows the feature but not the schema. No SQL.

Watch for: Naming an audience but then demanding completeness pulls in opposite directions — decide whether tailoring or coverage wins.

See also: Set the Reading Level, Assign a Persona, Constrain the Length

Define Done

State the criteria the output must meet to count as complete and correct.

Use this for any task where 'good enough' is contestable. A model with no completion test stops at the first plausible answer. Spelling out acceptance criteria turns the request into something the model can self-check before responding, and turns your review into a checklist rather than a vibe. It also surfaces hidden requirements — listing them forces you to decide what you actually need.

Done means: every input row appears in the output, the totals reconcile to the stated grand total, and any row you couldn't classify is listed separately under 'Needs review'.

Watch for: Vague criteria like 'make it good' add words without adding a test; if you can't check it, you haven't defined done.

See also: Specify the Output Format, Role, Goal, Constraints, Say What Not To Do

Constrain the Length

Set an explicit budget — word count, sentence count, or item count — for the response.

Use a length constraint when you need outputs that fit a slot, scan quickly, or stay comparable across runs, because models tend toward expansive, hedged prose. A budget forces prioritization: the model must decide what matters most rather than including everything plausibly relevant. Counting discrete units (three bullets, two sentences) constrains more reliably than vague words like 'brief', though models hold exact word counts only approximately.

Summarize the report in five bullets, each one sentence, ordered by financial impact.

Watch for: Too tight a budget on a genuinely complex answer forces the model to drop load-bearing caveats; size the limit to the task.

See also: Define Done, Specify the Output Format, Name the Audience

Provide a Template

Give a fill-in-the-blank skeleton and ask the model to populate it.

Use a template when many outputs must share an identical structure — incident reports, product entries, review notes — so each one is comparable and nothing gets skipped. The skeleton carries the format so the model spends its effort on content, and empty fields act as explicit prompts that prevent omission. It is among the most reliable ways to enforce structure, because the structure is literally already present.

Fill in: Finding: Evidence (quote + line): Severity (1-5): Recommended fix: — leave a field blank only if truly N/A, and say why.

Watch for: A template can suppress findings that don't fit any field, so add a free-text 'other' slot when completeness matters.

See also: Specify the Output Format, Show, Don't Tell, Define Done

Say What Not To Do

List the specific failure modes, words, or moves to avoid alongside what you want.

Use negative constraints when you can predict the wrong answers better than you can fully specify the right one — a recurring mistake, a forbidden phrase, an out-of-scope action. Positive instructions leave the complement undefined, so naming the trap closes off a known-bad region directly. It is especially useful for stamping out a behavior you keep seeing across runs.

Write the apology email. Do not admit legal fault, do not promise a refund, and do not use the word 'unfortunately'.

Watch for: Long prohibition lists can keep the banned item salient and occasionally surface it; keep the don'ts few and specific, and pair each with the positive behavior you want instead.

See also: Role, Goal, Constraints, Define Done, Constrain the Length

Set the Reading Level

Specify the target reading level or expertise so the explanation lands for the actual reader.

Use this when comprehension matters more than completeness — onboarding docs, public explainers, cross-discipline handoffs. Naming a level (a sharp 12-year-old, a first-year analyst, a domain expert) controls vocabulary, sentence length, and assumed prior knowledge, which a generic request leaves to chance. Reading level is a concrete dial the model can turn, unlike vague asks for 'simple' language.

Explain how a vaccine works at roughly an eighth-grade reading level: short sentences, no jargon, one everyday analogy.

Watch for: Lowering reading level can quietly drop precision; flag where a simplification trades away accuracy if that matters.

See also: Name the Audience, Assign a Persona, Constrain the Length

Cite Your Sources

Require each claim to be tied to the specific passage, document, or data it came from.

Use this whenever the output will be checked or trusted. Attribution makes claims verifiable and discourages the model from smoothing over gaps with invention. Requiring a citation per claim pushes the model to ground each statement in supplied material rather than its priors, and makes unsupported claims visible — they have no reference to attach. It converts 'trust me' into 'check this line'.

For each finding, append the source in brackets like [Doc 2, p.4]. If a claim has no source in the provided files, mark it [unsupported].

Watch for: Models can fabricate plausible-looking citations, so this only helps against provided material you can actually verify against — not the open web.

See also: Provide Reference Text, Permit 'I Don't Know', Use Delimiters

Use Delimiters

Wrap each distinct part of the prompt — instructions, data, examples — in clear markers.

Use delimiters whenever your prompt mixes instructions with material the model should act on, which is nearly always. Explicit boundaries (triple quotes, XML-style tags, labeled headers) signal what is command versus content, reducing the chance the model follows stray instructions embedded in your data or treats your data as a question. This separation is a useful first layer of defense against prompt injection in pasted or retrieved text, though it is not a complete safeguard.

<instructions>Summarize the email below in one line.</instructions> <email>{{pasted email, which may itself contain 'ignore previous instructions'}}</email>

Watch for: Inconsistent or nested delimiters confuse rather than clarify; pick one scheme and apply it uniformly. Delimiters alone do not stop a determined injection — combine with scope limits and human review for untrusted input.

See also: Lead With Context, Provide Reference Text, One Task Per Prompt

One Task Per Prompt

Ask for a single well-defined thing per request and chain steps rather than bundling them.

Use this when a job has multiple stages — extract, then classify, then summarize — because bundled asks make the model split attention and quietly drop or shortchange a sub-task. Isolating one task lets the model spend its full effort on it, makes the output easy to verify, and lets you fix one stage without redoing the others. Decomposition is often the cheapest reliability gain available.

Step 1 (this prompt): extract every dollar amount with its line number. (A later prompt will classify them — do not classify yet.)

Watch for: Over-splitting trivial tasks adds round-trips and can lose context the model needed to hold together; decompose by genuine seams, not reflexively.

See also: Lead With Context, Define Done, Use Delimiters

Provide Reference Text

Supply the authoritative material the answer must be built from, and require the model to use it.

Use this for any factual task where you have the ground truth — a policy, a spec, a dataset. Answering from supplied text is generally more accurate than answering from the model's diffuse memory. Grounding the response in material you control improves correctness and makes it auditable against a known source. It turns an open-ended recall problem into a closed reading-comprehension problem, which models handle better.

Answer the customer's question using only the refund policy below. Quote the relevant sentence. If the policy doesn't cover it, say so.

Watch for: Providing reference text without instructing 'use only this' lets the model blend it with unreliable priors, reintroducing the errors you were avoiding.

See also: Cite Your Sources, Permit 'I Don't Know', Lead With Context

Ask for the Reasoning

Request the steps or rationale before the final answer on tasks that involve real reasoning.

Use this for multi-step logic, math, diagnosis, or any judgment where the path matters as much as the verdict. Asking the model to work through the problem before committing tends to produce more accurate conclusions and, just as important, exposes the reasoning so you can spot where it went wrong. The visible chain becomes a debugging surface rather than an opaque guess.

Walk through your reasoning step by step, then give the final eligibility decision on the last line as 'Decision: eligible/ineligible'.

Watch for: Demanding reasoning on trivial or purely stylistic tasks just bloats the output, and a fluent-looking chain can still rationalize a wrong answer — treat it as evidence to check, not proof.

See also: Define Done, One Task Per Prompt, Permit 'I Don't Know'

Give an Out for Ambiguity

Instruct the model to ask a clarifying question when the request is underspecified rather than guessing.

Use this on open-ended or judgment-heavy tasks where a wrong assumption is costly, because the default behavior is to silently pick an interpretation and run with it. Inviting a clarifying question surfaces the ambiguity early, when it is cheap to resolve, instead of after a full answer built on the wrong premise. It is most valuable in multi-turn work where one good question saves several wasted rounds.

If anything about scope, audience, or format is unclear, ask me up to two questions before you start. Otherwise proceed.

Watch for: Without a cap, the model may stall on endless questions; bound the number and let it proceed when the ambiguity is minor.

See also: Permit 'I Don't Know', Role, Goal, Constraints, One Task Per Prompt

State the Stakes

Tell the model what the output is for and what a mistake would cost.

Use this when the consequence of error is asymmetric — a legal filing, a medical note, a customer-facing claim — so the model calibrates caution to the actual risk. Naming the stakes tends to shift behavior toward hedging, double-checking, and flagging uncertainty where it counts, rather than applying uniform confidence to everything. It tells the model where to be careful, which a flat request cannot.

This goes into a regulatory filing, so an overstated claim is worse than an omission. Flag anything you are not certain the source supports.

Watch for: Stakes framing nudges caution but is not a safety control — high stakes still require human verification, not just a more careful tone.

See also: Permit 'I Don't Know', Cite Your Sources, Define Done

Anchor the Vocabulary

Define the key terms, categories, or labels the model must use, so it doesn't invent its own.

Use this when outputs must be consistent across runs or align with an existing system — fixed severity levels, a controlled tag set, house terminology. Without a defined vocabulary the model coins synonyms and drifts between labels, making results hard to aggregate or compare. Pinning the terms turns free-form generation into classification against a known set, which is more reliable and far easier to audit.

Classify each ticket using only these labels: Billing, Access, Bug, Feature-Request, Other. Use the exact label strings, nothing else.

Watch for: A category set that doesn't cover the real inputs forces everything into 'Other' or invites silent miscoding; include an explicit catch-all and review what lands in it.

See also: Specify the Output Format, Provide a Template, Define Done

Decompose Before You Delegate

Break a complex task into named subtasks before asking for any output.

Use this when a request bundles several distinct operations — research, then draft, then format — that a single prompt would blur together. Naming the parts forces explicit coverage of each, so omissions become visible instead of silently dropped. Decomposition also gives you discrete units to verify and re-run independently.

Before writing anything, list the sub-tasks this request contains. Then do them one at a time, labeling each.

Watch for: Over-decomposing a trivial task adds ceremony and latency without improving the result.

See also: Plan Then Execute, The Iterate Loop, Checklist Verification

The Iterate Loop

Instruct, inspect the output, then refine the instruction — and repeat.

Treat this as the default rhythm for any non-trivial task rather than expecting one prompt to land. The gap between what you asked and what you got is the most precise signal available about what your instruction under-specified. Each pass converts a vague intention into a sharper, more constrained prompt.

After reviewing a draft: That is close, but tighten the second paragraph and drop the marketing tone. Keep everything else.

Watch for: Looping without diagnosing why the last output missed just reshuffles the same error.

See also: Two-Pass Draft Then Edit, Self-Critique And Revise, Decompose Before You Delegate

Verify Then Trust

Treat every confident-sounding claim as unverified until you check it.

Apply this to any output you will act on — facts, figures, code, citations, legal or medical statements. Fluency and correctness are independent: stated confidence reflects linguistic plausibility, not ground truth, so surface polish is not evidence. A verification step converts a trust problem into a checking problem you control.

List every factual claim and citation in your answer, then mark each as one you can confirm or one I should independently verify.

Watch for: Verifying with the same model that produced the claim can launder an error rather than catch it; use an independent source.

See also: Ground Answers In Provided Documents, Adversarial Self-Check, Checklist Verification

Adversarial Self-Check

Have the model argue why its own answer is wrong before you accept it.

Use this after a draft answer on anything with a defensible-but-fallible conclusion. Generating a critique engages different reasoning than generating an answer, so it can surface failure modes glossed over while committed to the first response. The adversarial framing licenses the model to break from its answer instead of defending it.

Now take the opposing view: give the three strongest reasons your answer above could be wrong, then revise if any hold.

Watch for: A token-effort critique that rubber-stamps the original gives false assurance.

See also: Red-Team Your Own Output, Self-Critique And Revise, Verify Then Trust

Ask For Step-by-Step Reasoning

Require the intermediate steps, not just the final answer.

Use this for arithmetic, logic, multi-constraint, or causal problems where a leap to the answer often hides an error. Forcing explicit intermediate steps gives the model room to work each part and gives you a traceable chain to audit instead of an opaque verdict. The visible reasoning is where you catch the mistake.

Work through this step by step, showing each intermediate result, before stating the final answer.

Watch for: Plausible-looking reasoning can be post-hoc rationalization that does not actually constrain the answer; check that the steps entail the conclusion.

See also: Plan Then Execute, Independent Recompute For Verification, Score Against A Rubric

Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" (2022)

Plan Then Execute

Get an explicit plan approved before any work is produced.

Use this for long or expensive tasks where a wrong direction wastes a full output — code changes, documents, multi-step research. Separating cheap, easily-corrected planning from costly execution lets you catch a flawed approach when fixing it costs one sentence. The plan also becomes a contract you can check the result against.

First give me a numbered plan and wait. Do not write any code until I approve the plan.

Watch for: Skipping plan review and letting it execute immediately discards the entire benefit.

See also: Decompose Before You Delegate, Ask Clarifying Questions First, Checklist Verification

Self-Critique And Revise

Have the model evaluate its draft against stated criteria, then rewrite.

Use this for prose, code, or arguments where quality criteria are nameable but a first pass rarely meets all of them. Evaluation and generation are distinct moves; a separate critique step catches weaknesses the generative pass optimized away. Naming the criteria turns a vague "make it better" into targeted repair.

Critique your draft for clarity, accuracy, and concision; list specific weaknesses; then produce a revised version fixing them.

Watch for: Without explicit criteria the critique drifts and the revision changes things that were already fine.

See also: Adversarial Self-Check, Two-Pass Draft Then Edit, Score Against A Rubric

Two-Pass Draft Then Edit

Generate a rough draft first, then edit it as a separate pass.

Use this for writing and code where trying to be complete and polished at once produces neither. Drafting and editing pull in opposite directions — generative breadth versus critical pruning — and forcing them into one pass compromises both. Separating them lets each pass do its job fully.

Pass 1: draft this freely without worrying about length. Pass 2: cut it to half the length and sharpen every sentence.

Watch for: Collapsing both passes into one prompt reintroduces the tension you were trying to avoid.

See also: Self-Critique And Revise, The Iterate Loop, Plan Then Execute

Checklist Verification

Supply an explicit checklist and require a pass/fail line for each item.

Use this when output must satisfy concrete, enumerable requirements — required sections, formatting rules, constraints, edge cases. A checklist converts open-ended "is this good" judgment into discrete binary checks that are hard to skip and easy to audit. The per-item response makes any gap immediately visible.

Check the output against this list and reply PASS or FAIL with a reason for each: [1] cites a source, [2] under 200 words, [3] no jargon.

Watch for: A checklist that only restates obvious requirements gives a false sense of rigor while missing the subtle failures.

See also: Score Against A Rubric, Verify Then Trust, Self-Critique And Revise

Generate Multiple Options Then Compare

Ask for several distinct candidates before choosing one.

Use this for open-ended problems — naming, design, strategy, phrasing — where the first idea is rarely the best and one sample cannot reveal the space. Requiring genuinely different options forces exploration instead of refinement of a single path, and a side-by-side comparison surfaces tradeoffs that are invisible in isolation. The comparison is where the judgment happens.

Give three genuinely different approaches, then a short table of their tradeoffs, then your recommendation with reasoning.

Watch for: Options that are minor variants of one idea give the illusion of choice without real exploration.

See also: Score Against A Rubric, Plan Then Execute, Self-Critique And Revise

Score Against A Rubric

Define explicit scoring criteria and have the output graded on each.

Use this when you need to compare candidates or measure quality consistently rather than rely on a global gut verdict. A rubric decomposes a fuzzy quality judgment into named dimensions with their own scales, making the assessment reproducible and the weak dimensions explicit. It also lets you weight what actually matters to you.

Score each option 1-5 on accuracy, clarity, and feasibility, with a one-line justification per score, then total them.

Watch for: Rubric scores read as objective but inherit the bias of whoever wrote the criteria and whoever applies them.

See also: Generate Multiple Options Then Compare, Checklist Verification, Self-Critique And Revise

Ask Clarifying Questions First

Require the model to ask what it needs before it answers.

Use this when a request is ambiguous or under-specified and a wrong assumption would waste the whole output. Models default to guessing at missing context and committing to that guess; forcing questions surfaces the assumptions while they are still cheap to correct. The questions themselves often reveal what you failed to specify.

Before answering, ask me any questions you need to avoid guessing. Do not proceed until I have answered.

Watch for: On a fully-specified request this just adds a stalling round-trip; reserve it for genuine ambiguity.

See also: Plan Then Execute, Define Escalate-To-Human Criteria, State Your Assumptions

Define Escalate-To-Human Criteria

Tell the model exactly when to stop and hand off instead of guessing.

Use this in automated or agentic workflows where a confident wrong action is worse than a pause. Models will otherwise attempt anything asked, including tasks beyond their reliable competence; naming explicit stop conditions converts silent overreach into a visible handoff. You set the boundary in advance, not the model mid-task.

If the action is irreversible, if required data is missing, or if the request falls outside the stated scope, stop and ask me rather than proceeding.

Watch for: Vague triggers like "if unsure" fail because self-reported confidence is poorly calibrated; make the conditions concrete and observable.

See also: Ask Clarifying Questions First, Verify Then Trust, Bound The Task Scope

Ground Answers In Provided Documents

Restrict the answer to supplied sources and require citation of each claim.

Use this for factual questions where you have authoritative material and want to suppress invented detail. Anchoring generation to a given corpus and demanding per-claim citation makes unsupported statements structurally harder to produce and easier to spot. It converts "is this true" into "is this in the source," which you can check.

Answer using only the documents below. Cite the section for each claim. If the documents do not say, reply "not stated."

Watch for: A model can still cite a real source for a claim it does not actually support, so spot-check that each citation backs its claim.

See also: Verify Then Trust, Force An I-Don't-Know Option, Checklist Verification

Red-Team Your Own Output

Attack the result as an adversary would before you ship it.

Use this for anything that will face scrutiny, misuse, or edge cases — security-sensitive code, public claims, policies, plans. An adversarial frame makes the model hunt for exploits, loopholes, and failure scenarios that a cooperative drafting frame never considers. Finding the breaks yourself is cheaper than having a critic or attacker find them.

Act as a hostile reviewer trying to break this. List every edge case, exploit, or failure mode you can find.

Watch for: Red-teaming surfaces problems but does not prioritize them; a long list without severity ranking can bury the real risk.

See also: Adversarial Self-Check, Checklist Verification, Self-Critique And Revise

Force An I-Don't-Know Option

Explicitly permit and require "I don't know" when evidence is absent.

Use this for factual and analytical tasks where a fabricated answer is worse than an admission of ignorance. Models are biased toward producing a fluent answer even with no basis; explicitly licensing abstention removes the pressure to confabulate. Naming "unknown" as an acceptable output reshapes what the model optimizes for.

If you do not have reliable grounds to answer, say "I don't know" rather than guessing. Do not fill gaps with plausible detail.

Watch for: Overused, it becomes an excuse to abstain on answerable questions; pair it with a genuine attempt first.

See also: Ground Answers In Provided Documents, Verify Then Trust, Define Escalate-To-Human Criteria

State Your Assumptions

Require an explicit list of assumptions alongside the answer.

Use this when context is incomplete but you still want the work to proceed rather than stall on questions. Every answer rests on assumptions; surfacing them lets you correct a wrong premise instantly instead of discovering it embedded in a finished output. The assumption list is a cheap audit trail for the reasoning.

Answer now, but list every assumption you made. Flag any that, if wrong, would change the conclusion.

Watch for: A list of trivial assumptions hides the load-bearing one; ask specifically for the assumptions that would flip the answer.

See also: Ask Clarifying Questions First, Plan Then Execute, Show The Confidence

Show The Confidence

Require a stated confidence level and its basis on each claim.

Use this when you must triage which parts of an answer to trust and which to verify. A uniform confident tone hides the real variation in reliability across claims; asking for per-claim confidence and its basis exposes the weak links for targeted checking. It turns one undifferentiated answer into a prioritized verification list.

For each claim, give a confidence level (high/medium/low) and one line explaining what that confidence rests on.

Watch for: Self-reported confidence is often miscalibrated, so treat it as a triage hint, not a measurement.

See also: Verify Then Trust, State Your Assumptions, Force An I-Don't-Know Option

Bound The Task Scope

State explicitly what is in scope and what to leave untouched.

Use this when a task could sprawl — refactors, edits, research — and unintended changes are costly to detect and undo. Models fill ambiguity with helpful additions you did not ask for; an explicit boundary converts open license into a constrained edit you can review. The negative instructions matter as much as the positive ones.

Change only the validation logic. Do not touch formatting, imports, or anything else, and tell me if something outside scope needs fixing.

Watch for: Boundaries set too tight force the model to leave genuine dependencies broken; allow it to flag necessary out-of-scope issues rather than silently fixing or ignoring them.

See also: Plan Then Execute, Define Escalate-To-Human Criteria, Decompose Before You Delegate

Independent Recompute For Verification

Re-derive the answer by a different method and check the two agree.

Use this for calculations, conversions, counts, and logic where a single derivation can be confidently wrong. An independent second path is unlikely to reproduce the exact same error, so agreement is real evidence and disagreement flags a problem the first pass concealed. It is stronger than re-reading because it does not just inspect the original reasoning.

Now solve it a second time using a completely different method and confirm both results match. If they differ, find the error.

Watch for: If the second method is not truly independent it can inherit the same mistake and falsely confirm it.

See also: Ask For Step-by-Step Reasoning, Verify Then Trust, Adversarial Self-Check

Show a Counter-Example

Include an example of a wrong or bad answer, labelled as such, so the model steers around a specific failure.

Use this when there is a particular mistake you keep getting — the wrong tone, a banned structure, an over-long reply. A positive example shows the target; a counter-example fences off the ditch beside it. Pairing a concrete "do this" with a concrete "not this" resolves ambiguities that a single good example leaves open.

Good: "Revenue rose 12% on stronger retention." Bad (too vague — do not do this): "Things improved this quarter." Now write the summary in the Good style.

Watch for: Too many counter-examples can anchor the model on the very patterns you are warning against — one or two sharp ones beat a long list of don'ts.

See also: Show, Don't Tell, Say What Not To Do, Provide a Template

Change One Thing at a Time

When a prompt is not working, adjust a single element per iteration so you learn what actually moved the result.

Use this whenever you are refining a prompt that is close but not right. Changing several things at once and getting a better answer tells you nothing about why — you cannot repeat it or build on it. Isolating one variable per pass turns trial-and-error into a controlled experiment, and you keep only the change that helped.

Run 1: add the audience. Run 2 (audience kept): add the output format. Run 3: add one example. Note which change actually improved the result.

Watch for: It is slower than rewriting wholesale, so reserve it for prompts you will reuse — for one-offs, a full rewrite is often faster.

See also: The Iterate Loop, Self-Critique And Revise, Two-Pass Draft Then Edit

Desk research with AI

Use AI to map a topic fast, then verify every load-bearing claim before you rely on it.

AI is good at orienting you in an unfamiliar area, generating search angles, and clustering scattered information into a structure you can interrogate. Treat its output as a set of leads to confirm, never as the finding itself: the model proposes, you dispose. Your credibility rests on primary sources you have actually read, not on a fluent summary you have not.

1. State your question precisely and ask the AI for the main sub-questions, key terms, and competing viewpoints. 2. Ask for candidate sources, organisations, and search queries, but treat any specific citation, statistic, or quote it offers as unverified. 3. Go to the primary sources yourself and read enough to confirm each claim you intend to use. 4. Feed verified excerpts back to the AI to synthesise, and ask it to flag where the evidence is thin or contradictory. 5. Keep a short trail linking each conclusion to the source you checked.

Watch for: The biggest failure is fabricated or subtly wrong citations and figures stated with total confidence; if you cannot open the source and find the claim, do not use it. A second trap is anchoring on the AI's framing so you stop looking for disconfirming evidence. Accountability stays with you because your name, not the tool's, is on the deliverable, so verify before you cite.

See also: Summarising long documents with AI, Drafting and writing with AI, Data analysis with AI

Drafting and writing with AI

Let AI produce a fast first draft you own, shape, and stand behind, not a final answer.

AI lowers the cost of getting words on the page and breaking writer's block, which matters because the hardest part of writing is often starting. The principle is that you remain the author: the draft is raw material you edit for accuracy, judgment, and voice until it genuinely reflects what you think. A document you would not defend in your own words is not ready to send.

1. Give the AI your audience, purpose, key points, constraints, and tone before asking for anything. 2. Ask for a first draft or an outline, not a finished piece, and request a few structural options. 3. Rewrite in your own voice, correcting every factual claim and removing anything you cannot personally stand behind. 4. Check that the argument is yours and the evidence is real, not plausible-sounding filler. 5. Read it aloud once for tone and clarity before sending.

Watch for: AI prose tends toward generic, padded, or overconfident text, and will invent supporting details if you let it; edit hard and verify facts. Sending lightly edited output risks both errors and a flat, anonymous voice that readers notice. You are accountable for every sentence, so never ship language whose meaning you have not checked and made your own.

See also: Desk research with AI, Summarising long documents with AI, Email and communications with AI

Summarising long documents with AI

Use AI to compress long material into a usable brief, then spot-check it against the source.

AI is strong at distilling reports, contracts, and threads into the gist and pulling out structure, which saves real time on dense material. The principle is verification proportional to stakes: the more a decision rests on the summary, the more you must confirm it against the original. A summary is a lens, not a replacement for the document it describes.

1. Tell the AI what you need from the summary, such as decisions, risks, obligations, or open questions, and the length you want. 2. Ask it to cite section or page locations for each major point so claims are traceable. 3. Spot-check the most consequential points directly against the source text. 4. Ask specifically what important caveats, exceptions, or dissents it may have dropped. 5. For anything high-stakes, read the relevant passages in full yourself.

Watch for: Summaries silently omit nuance, caveats, and minority positions, and can misattribute or overstate; the omission you do not see is the dangerous one. Long inputs may exceed what the tool reliably processes, degrading quality without warning. Because you act on the summary, you own its errors, so verify the points that carry weight.

See also: Desk research with AI, Drafting and writing with AI, Meeting prep and notes with AI

Data analysis with AI

Use AI to explore, transform, and explain data while you own the method and the numbers.

AI can suggest analytical approaches, write transformation and charting code, and translate results into plain language, accelerating exploratory work. The principle is that you remain responsible for correctness: understand the method, check figures against a known total, and confirm the data is clean before trusting any output. A confident chart built on a flawed join is still wrong.

1. Describe your data, its structure, and the question, and ask the AI for sensible approaches and their assumptions. 2. Have it generate code or formulas you can inspect, rather than accepting a bare numeric answer. 3. Validate against something you already know, such as a row count, a control total, or a hand calculation on a sample. 4. Probe edge cases like missing values, duplicates, and outliers, and ask how each is handled. 5. Write the interpretation yourself, stating limitations explicitly.

Watch for: AI can produce plausible code with subtle errors, misread units, or assert statistics it did not actually compute; never report a number you have not reconciled. It may also overstate certainty or imply causation from correlation. Decisions follow from these figures, so accountability for accuracy and interpretation is yours, not the tool's.

See also: Desk research with AI, Summarising long documents with AI, Drafting and writing with AI

Email and communications with AI

Use AI to draft and sharpen messages while you own tone, facts, and the decision to send.

AI helps you draft routine correspondence quickly, adjust tone, and pressure-test how a message will land before it goes out. The principle is that communication is a relationship act you are accountable for: the AI drafts, but you confirm every fact, set the tone, and remain the sender. The recipient holds you, not a tool, responsible for what was said.

1. Give the AI the context, your relationship to the recipient, the outcome you want, and any facts or commitments involved. 2. Ask for a draft and, where useful, a softer and a firmer variant. 3. Verify every name, date, figure, and promise against your own records. 4. Edit for your voice and the specific reader, removing anything generic or overstated. 5. Read it once more for tone and unintended implications before sending.

Watch for: AI can invent details, agree to things you did not authorise, or strike a tone that is off for the relationship; never send a commitment you have not checked. Sensitive or confidential content should not be pasted into tools without regard to your organisation's data rules. Because the message goes out under your name, the judgment to send and its consequences are yours.

See also: Drafting and writing with AI, Meeting prep and notes with AI, Summarising long documents with AI

Meeting prep and notes with AI

Use AI to brief you before meetings and structure notes after, with you verifying the record.

AI can assemble background, suggest questions, and turn rough or transcribed notes into structured summaries with clear action items, reducing the overhead around meetings. The principle is that the official record and any commitments remain yours to confirm: AI drafts the artefact, but you check it against what was actually said and decided. An unverified action list can quietly create or erase obligations.

1. Before the meeting, give the AI the agenda and attendees and ask for background, likely issues, and questions worth raising. 2. During the meeting, capture decisions and owners; if you use a transcription or notetaking tool, confirm participants consent first. 3. Afterwards, ask the AI to draft a summary with decisions, action items, owners, and due dates. 4. Verify each item against your own recollection and notes, correcting misattributions. 5. Circulate the confirmed version and invite corrections.

Watch for: Automated notes can misattribute statements, invent action items, or miss the real decision, and transcription errors compound; the named owner of a task may not have agreed to it. Recording people without consent can breach trust or policy. You own the accuracy of the record and the commitments it implies, so confirm before distributing.

See also: Summarising long documents with AI, Email and communications with AI, Desk research with AI

Hiring and CV screening with AI

Use AI to extract and structure candidate evidence faster, while a named human makes every accept-or-reject decision against the role's real requirements.

Treat AI as a clerk that extracts and tabulates evidence from CVs and applications, not as a judge that scores or ranks people. The principle: AI can read at scale but does not understand the role, the team, or what 'good' looks like in your context, and historical hiring data encodes past bias that an automated scorer will faithfully reproduce. Keep the AI's output as structured notes a human reviews, and fix the decision criteria as humans before any CV is seen, so the bar is set by the role rather than by what the applicant pool happens to contain.

1. Before opening any application, write the role's must-have and nice-to-have criteria as a checklist, so the bar is fixed in advance. 2. Ask the AI to extract specified fields from each CV (years in X, named tools, qualifications) into a table, with a quote or location for each claim. 3. Spot-check the extraction against several source CVs to confirm it is not misreading or inventing. 4. Have a human compare candidates against the human-written checklist, not against any AI-generated score. 5. Record the reason for each shortlist decision in the decision-maker's own words.

Watch for: The dangerous failure is asking AI to 'rank' or 'rate' candidates: it produces a confident number that launders bias and gives reviewers false permission to skim. AI also fabricates or misattributes details, so an unverified extract can sink a real candidate. Employment and discrimination law holds the employer accountable regardless of tooling, so a named human must own each decision and be able to justify it without reference to a model's output. Never let the tool auto-reject; a human reads every borderline case.

See also: Risk assessment with AI, Planning and prioritisation with AI

Planning and prioritisation with AI

Use AI to surface options, dependencies, and blind spots, then let a human set priorities using judgment the model does not have.

AI is strong at generating a wide option set and pointing out dependencies or sequencing you may have missed, and weak at knowing your constraints, your politics, and what actually matters this quarter. The principle: keep the model in a divergent, generative role and reserve the convergent, deciding role for the human who carries the consequences. A prioritisation produced entirely by AI hides its assumptions; a prioritisation reviewed by AI exposes yours.

1. State your goal, hard constraints, and current candidate list, and ask the AI to expand the option set and flag missing dependencies. 2. Ask it to argue against your current top priority, to stress-test your thinking. 3. Assign priority yourself using an explicit method, such as effort against impact, that you apply rather than the model. 4. Ask the AI what would have to be true for the plan to fail, and add those as risks to watch. 5. Write the final ranked plan yourself, noting which assumptions you are betting on.

Watch for: The trap is accepting an AI-generated ranking because it looks decisive; the model weights factors it cannot actually assess and will invent plausible justifications. It also anchors on whatever you said first, so it tends to confirm rather than challenge. Accountability stays with the human by keeping the prioritisation method and the final ordering yours, with the AI confined to broadening inputs and probing weaknesses, never issuing the verdict.

See also: Competitive analysis with AI, Risk assessment with AI, Board or exec prep with AI

Risk assessment with AI

Use AI to widen the set of risks you consider and pressure-test your mitigations, while humans own the severity calls and the sign-off.

AI is useful for brainstorming failure modes, surfacing categories you forgot, and playing devil's advocate against your assumptions, because it has read broadly across domains. It is unreliable at estimating likelihood or impact in your specific situation, and it cannot be accountable for a risk that materialises. The principle: let AI broaden the hazard list, but keep scoring, acceptance, and sign-off as human acts grounded in real evidence.

1. Describe the system, decision, or project and ask the AI to enumerate plausible failure modes across people, process, and technology. 2. Ask it to challenge your existing mitigations and name where each could quietly fail. 3. Score likelihood and impact yourself, using your own framework and real data, not numbers the AI supplies. 4. For each material risk, assign a named human owner and a mitigation. 5. Record which risks you are knowingly accepting and who accepted them.

Watch for: AI will produce confident probability and severity numbers that have no empirical basis; treating them as data is the core mistake. It can also miss the context-specific risk that only a domain expert would catch, so its list is a starting point, not a complete register. Keep accountability human by ensuring every scored risk and every acceptance decision carries a named owner who can defend it, and never let an AI-generated register pass as a completed assessment.

See also: Planning and prioritisation with AI, Hiring and CV screening with AI

Board or exec prep with AI

Use AI to draft, tighten, and stress-test the narrative of a board pack, while a human verifies every number and owns every claim.

AI helps shape a clear story, anticipate the questions a board will ask, and compress dense material into a readable summary, which saves real time under deadline. It must never be the source of facts, figures, or financials, because it confabulates numbers fluently and a wrong figure in a board pack is a governance failure. The principle: AI shapes the narrative; the human supplies and verifies the substance.

1. Give the AI your already-verified figures and source documents, and ask it to draft a tight narrative and an executive summary. 2. Ask it to generate the toughest questions a sceptical board member would ask, and prepare answers. 3. Check every number in the draft back to its authoritative source yourself. 4. Have the accountable executive read, edit, and approve the final pack in their own voice. 5. Keep an audit trail linking each key claim to its source.

Watch for: The signature failure is an AI silently altering or inventing a figure during summarisation, which then reads as authoritative; a single unverified number can mislead a board. AI also smooths over uncertainty, presenting tentative results as settled. Accountability rests with the presenting executive, who must defend every figure and statement without citing the tool, so source-checking and personal sign-off are non-negotiable. Do not paste confidential board material into any tool without confirming its data-handling terms.

See also: Competitive analysis with AI, Planning and prioritisation with AI

Competitive analysis with AI

Use AI to structure a comparison and generate hypotheses about competitors, then verify every factual claim against primary sources before acting.

AI is good at organising a market into comparison frameworks, suggesting axes you had not considered, and drafting a first-pass landscape. It is unreliable on current facts: it confuses competitors, repeats outdated or invented details, and has no live view of the market unless you give it the sources. The principle: use AI for structure and hypotheses, and treat every specific claim as unverified until checked against a primary source.

1. Define the question and the competitors, and ask the AI to propose a comparison framework and the dimensions that matter. 2. Feed it only material you have gathered from primary sources, and ask it to organise and contrast, not to recall from memory. 3. Verify each factual assertion against the competitor's own published materials or other authoritative sources. 4. Ask the AI where your analysis might be wrong or biased toward your own position. 5. Write the conclusions and the so-what yourself, owning the strategic read.

Watch for: The core risk is treating AI's recall as fact: it states competitor pricing, features, or funding with confidence and is frequently wrong or out of date, and acting on that can be costly. It also tends to flatter the asker's own position. Keep accountability with the human by sourcing every factual claim to a primary document and by making a named analyst responsible for the conclusions; an AI-generated landscape is a draft to verify, never a finding to circulate.

See also: Board or exec prep with AI, Planning and prioritisation with AI

Code review and debugging with AI

Use AI to widen your review coverage and speed up diagnosis while you remain the engineer of record who approves every change.

Treat the model as a fast, tireless second reviewer that proposes hypotheses and spots patterns, not as an authority on whether code is correct. Correctness is established by tests, types, and your own reading; AI accelerates the search for problems but never certifies their absence. Hold the human accountable by putting every AI-suggested fix through the same gate as any human commit: a failing-then-passing test, a clean build, and your sign-off. If you cannot explain why a change is correct, it is not ready to merge regardless of where it came from.

1. Paste the diff or function with its context (callers, types, the bug report) and ask for likely defects, edge cases, and unstated assumptions. 2. Ask the model to explain the code back to you; a gap between its explanation and your intent often pinpoints the bug. 3. For a live bug, give it the error, stack trace, and a minimal reproduction, and ask for ranked hypotheses rather than a single answer. 4. Write or run a test that confirms the real cause before applying any fix. 5. Review the fix line by line, then commit it under your name on your judgment, not the model's.

Watch for: Models invent plausible APIs, miss security and concurrency issues, and state wrong diagnoses with confidence. They optimise for output that looks resolved, so an untested 'fix' can mask the real fault or introduce a new one. Never merge a change you cannot explain yourself; never paste secrets or proprietary code into a tool without checking your data policy; always reproduce the bug and confirm the fix with a test you control.

See also: Test-first debugging, Rubber-duck explanation, Reading a diff for intent, Spreadsheet and data wrangling with AI

Learning a new domain quickly with AI

Use AI to build a fast scaffold of a new field's vocabulary, mental models, and key questions, then verify against primary sources before you rely on any of it.

A model is good at giving you the shape of a field — its terms, debates, and standard methods — which is exactly what a newcomer lacks and what lets you read real material faster. Work in two phases: scaffold, then verify. Use AI for orientation and for translating jargon, but treat every load-bearing fact as a claim to confirm in a textbook, standard, or paper. Stay accountable by tracking which beliefs are AI-sourced and unverified versus grounded in a citation you have actually read.

1. Ask for a map of the domain: core concepts, the main schools or methods, and what practitioners disagree about. 2. Ask it to define the field's jargon in plain language, with an everyday analogy and where that analogy breaks down. 3. Have it generate the ten questions an expert would expect you to answer, then attempt them. 4. For each claim you will rely on, find and read a primary source that confirms it. 5. Write your own one-page summary from memory and have the model quiz you to expose gaps.

Watch for: Models blur the cutting edge with the settled, present contested points as consensus, and misstate specifics such as dates, named results, and citations. Fabricated references are common, so never cite a source the model gave you without retrieving and reading it. Keep a running list of unverified claims; the hazard of fast orientation is mistaking fluency for understanding.

See also: Desk research with AI, Literature review with AI, Socratic self-testing, Verifying a claim against primary sources

Literature review with AI

Use AI to organise, summarise, and cross-question a body of sources you have gathered, while keeping retrieval and every citation under human control.

AI is strong at synthesising themes, contrasting arguments, and drafting structure across documents you provide, which compresses the slow middle phase of a review. The model may summarise sources you supply, but it must not be the source: discovery and citation stay with you and the actual papers. Accountability means every claim in your review traces to a document you have read, not to the model's paraphrase or its recollection of the literature.

1. Gather the actual papers yourself through proper databases; do not ask the model to supply the reference list. 2. Feed it the texts or your notes and ask for a thematic map of agreements, disagreements, and gaps. 3. Ask it to surface the strongest tension between two sources and state both positions fairly. 4. Have it draft a synthesis outline, then write the prose yourself from the originals. 5. Check every citation, quote, and number against the source document before it enters your draft.

Watch for: Models hallucinate references, misattribute findings, and overstate how settled a question is. Asking a model to 'find papers on X' from memory produces convincing fakes, so retrieval must come from real indexes. Summaries can quietly drop caveats and sample limits that change a finding's meaning, so confirm the strength of every claim in the original and keep your name on the synthesis and its judgments.

See also: Desk research with AI, Learning a new domain quickly with AI, Verifying a claim against primary sources, Note-to-draft synthesis

Spreadsheet and data wrangling with AI

Use AI to draft formulas, transformations, and cleaning steps, then validate every result against your own checks before you trust a single number.

Models are good at turning a described intent into a formula, a script, or a sequence of cleaning steps, which removes much of the syntax friction of data work. The model writes the transformation, but you own the truth of the output: a confident formula that returns a number is not the same as a correct one. Stay accountable by validating on known cases and reconciling totals, so no figure reaches a decision without a check you performed.

1. Describe your columns, their types, and the exact result you want, and ask for the formula or script plus an explanation of how it works. 2. Test it on a small slice where you already know the right answer. 3. Ask it to list the edge cases it did not handle — blanks, duplicates, mixed types, locale and date formats. 4. Reconcile against an independent check such as a row count, a control total, or a spot-checked sample. 5. Keep the transformation steps visible and repeatable rather than pasting in values whose origin you cannot trace.

Watch for: Formulas can be silently wrong, mishandle blanks and rounding, or break on a format the sample did not show, and the model cannot see your full data. It may also alter data when asked only to analyse it. Never paste confidential data into a tool without clearing your data policy, never accept an aggregate you have not reconciled, and keep the human as the one who signs off that the numbers are right.

See also: Code review and debugging with AI, Validating outputs against known cases, Reproducible data steps, Desk research with AI

Translation and localisation with AI

Use AI for a fast first-pass translation and locale adaptation, with a human reviewer owning meaning, tone, and anything high-stakes.

Machine translation is now fluent enough to produce a strong draft and to flag idioms and cultural references that need adapting, which speeds the bulk of routine work. But fluency is not fidelity: a smooth output can still be wrong, and the further the content sits from neutral — legal, medical, marketing, safety — the more a qualified human must own the result. Accountability rests with a reviewer who understands both languages and the context, never with the model alone.

1. Give the model the source text plus the audience, register, locale, and a glossary of terms that must stay consistent. 2. Ask for the translation and a note on any phrases that are ambiguous or culturally loaded. 3. For critical passages, request a back-translation and compare it to the original to catch meaning drift. 4. Have a fluent human review tone, terminology, names, formats, and anything sensitive. 5. Localise specifics — dates, currency, units, idioms, examples — for the target market rather than translating them literally.

Watch for: Models produce confident mistranslations, lose register, mangle named entities and negations, and default to the dominant dialect of a language. They can flatten culturally specific meaning into something fluent but wrong. Never ship safety-critical, legal, or medical translation without qualified human review, never assume consistency across a long document, and keep a named human reviewer accountable for the final text.

See also: Back-translation check, Glossary and terminology control, Locale adaptation, Literature review with AI

Preparing for a high-stakes conversation

Use AI to rehearse, anticipate objections, and sharpen your message — while you stay the one in the room.

AI is a useful sparring partner before a negotiation, a piece of difficult feedback, or a hard board question: it can surface counter-arguments, role-play the other side, and stress-test your framing before it matters. The principle is rehearsal, not scripting — you walk in with your own judgment and a feel for the terrain, not a memorised script that breaks on first contact.

1. Describe the situation, the other person's likely goals, and the outcome you want. 2. Ask the AI to argue their side as persuasively as it can, then name the three objections you are least ready for. 3. Draft your key points and have it poke holes in them. 4. Rehearse your opening and a few responses in your own words. 5. Decide your walk-away line and your one non-negotiable before you go in.

Watch for: The model doesn't know the real person or your history — treat its role-play as a drill, not a prediction, and never outsource the empathy or the judgment call. The conversation is yours to read in real time.

See also: Drafting and writing with AI, Planning and prioritisation with AI

Brainstorming and idea generation

Use AI to widen the field of options fast — then bring the judgment about which ideas are actually good.

AI is strong at divergence: generating many angles, combinations, and unconventional options far quicker than you would alone. The principle is a clean division of labour — it supplies quantity and range, you supply taste, feasibility, and the decision. Its job is to get you out of your own first three ideas, not to pick the winner.

1. State the problem, your constraints, and what a good idea must achieve. 2. Ask for 15–20 distinct options, deliberately including a few unconventional ones. 3. Cluster them and shortlist the few worth developing, and say why. 4. Push the shortlist: ask for variations, combinations, and the strongest objection to each. 5. Choose yourself — the model's enthusiasm is not evidence.

Watch for: AI ideas trend toward the generic and the safely average; treat the list as raw material to react against, not a ranking. Anchoring on its first suggestion defeats the whole point of brainstorming.

See also: Drafting and writing with AI, Planning and prioritisation with AI

Data Privacy: Know What Not to Paste

Treat every prompt as if it could be stored, logged, or read by someone else, and keep regulated or confidential data out of it.

Depending on the plan and settings, an AI tool may retain, transmit, or use submitted text, so pasted data can outlive the moment and leave your control. The safe default is that a prompt is not private. That means personal data, health or financial records, trade secrets, credentials, and client-confidential material need explicit clearance before they go in. A clear line on what may and may not be entered prevents the most common and most damaging disclosures, and it is far easier to hold than a case-by-case judgment made under deadline.

A support agent wants help drafting a reply, so before pasting the ticket they remove the customer's name, account number, and address, leaving only the anonymized problem description.

Note: Assuming an enterprise tier with a no-training clause makes any data safe to paste; the contract may still permit retention or logging, and screenshots, attachments, and pasted logs smuggle in data the policy was meant to exclude.

See also: Acceptable-Use Policy, Vendor and Model Risk, Security and Prompt-Injection Defence

Disclosure: Tell People When AI Was Used

Disclose AI involvement when its use could reasonably change how someone judges, trusts, or relies on the output.

People weigh information differently when they know a machine helped produce it, and undisclosed use erodes trust when it later surfaces. Disclosure is not needed for trivial assistance like spell-check, but it is warranted when AI shapes substantive content, informs a decision, or is presented as a person's own expert judgment. The working test is whether a reasonable reader would feel misled to learn after the fact. When in doubt, a brief, specific note costs little and protects credibility.

A team adds a one-line note that an article draft was generated with AI assistance and reviewed by a named editor, while omitting such a note for AI-assisted grammar fixes on internal email.

Note: All-or-nothing labeling, where teams either tag everything until the label becomes noise, or tag nothing until silence reads as concealment; the sharper gap is AI-generated images, code, or analysis passed off as fully human work.

See also: Human Accountability and Sign-Off, Acceptable-Use Policy, IP and Copyright

Human Accountability and Sign-Off

A named person owns every consequential AI-assisted output and is accountable for it as if they had produced it themselves.

AI cannot hold responsibility, so accountability must rest with an identifiable human who has reviewed and accepted the work. Without a clear owner, errors slip through because everyone assumes someone else checked, and no one is answerable when an output causes harm. Sign-off means the person has actually examined the output and stands behind it, not merely that they clicked approve. The more an output will be relied upon, the more the review has to be real rather than ceremonial.

Before a contract clause drafted with AI goes to a client, the responsible lawyer reads it line by line, confirms it says what they intend, and initials it, accepting the same liability as for any clause they wrote.

Note: Rubber-stamp approval, where sign-off becomes a formality and reviewers trust fluent output without verifying it; the more authoritative and well-formatted the text, the less it tends to get scrutinized.

See also: Disclosure: Tell People When AI Was Used, Record-Keeping and Audit Trail, Sensitive-Domain Limits

Bias and Fairness Review

Check AI outputs and AI-assisted decisions for systematic bias before they affect people, especially in hiring, lending, housing, and access to services.

Models learn patterns from historical data that can encode discrimination, and they reproduce those patterns at scale and with a veneer of objectivity. When AI influences decisions about individuals, unreviewed bias can cause real harm and legal exposure, so fairness review has to be a deliberate step rather than an afterthought. Examining outcomes across affected groups surfaces disparities that inspecting a single result will miss, and it should happen before deployment and on a recurring basis after.

A hiring team that uses AI to help screen resumes periodically compares the shortlist against the applicant pool to check whether qualified candidates from particular groups are filtered out at higher rates, and investigates when they are.

Note: Judging the model only on average accuracy while ignoring how errors distribute across groups; bias also enters through the prompt wording and through which outputs a human chooses to accept, not just through the model itself.

See also: Human Accountability and Sign-Off, Sensitive-Domain Limits, Review Cadence

Record-Keeping and Audit Trail

Keep enough record of significant AI use to reconstruct what was asked, what came back, and who decided what.

When an AI-assisted output is later questioned, you need to show how it was produced and who approved it, which is impossible without a trail. Records support accountability, incident investigation, and regulatory response, and they let you trace a problem back to a specific prompt, model version, or reviewer. The right level of detail scales with the stakes: a customer-facing decision warrants a fuller record than a throwaway draft.

A team logs the prompt, the tool and version, the date, the output, and the reviewer's name for any AI use that feeds a customer-facing decision, while keeping lighter records for low-stakes drafting.

Note: Logging everything indefinitely, which creates its own privacy and storage liability, or logging nothing because the tool's built-in history is assumed to be permanent and retrievable, when it may be purged, capped, or lost on account changes.

See also: Human Accountability and Sign-Off, Escalation Paths, Review Cadence

Acceptable-Use Policy

Write down which AI tools, tasks, and data are allowed, which are forbidden, and where the gray zone needs approval.

Without an explicit policy, people improvise, and individual judgment varies widely on what data is safe or what tasks are appropriate. A clear acceptable-use policy gives staff confidence to use AI well and a bright line where they must stop or ask. It works best when it names concrete examples rather than abstract principles, because abstractions get interpreted generously under deadline pressure. The policy should be short enough to be read and specific enough to be applied.

A policy lists approved tools for general drafting, bans entering customer financial data into any external AI tool, and requires manager approval before AI is used in client deliverables.

Note: Policies written once and never revisited as tools and risks change, or policies so restrictive that staff route around them with personal accounts, creating invisible shadow usage that is harder to govern than sanctioned use.

See also: Data Privacy: Know What Not to Paste, Vendor and Model Risk, Review Cadence

Vendor and Model Risk

Assess the providers and models you depend on for data handling, reliability, and the chance they change, degrade, or disappear.

Relying on an external AI service means inheriting its data practices, security posture, and business continuity, none of which you control. Models get deprecated, terms change, and behavior drifts between versions, so a workflow built on one provider can break or quietly shift output. Reading the actual contractual terms and keeping a viable fallback reduces the risk of being stranded or surprised by a change you did not choose.

Before adopting a tool for a core workflow, a team reviews the provider's data-retention terms and security documentation, checks its track record on deprecating older models, and confirms a workable alternative exists if the service is withdrawn.

Note: Reading the marketing claims rather than the data-processing terms, and building deep dependencies on one model's specific behavior that silently change when the provider updates or retires it.

See also: Data Privacy: Know What Not to Paste, Acceptable-Use Policy, Security and Prompt-Injection Defence

IP and Copyright

Treat AI output as carrying uncertain ownership and possible third-party rights, and verify before you rely on it commercially.

The legal status of AI-generated content is unsettled and varies by jurisdiction, and outputs can resemble or reproduce protected material seen during training. Using such content in products or publications without checking can expose you to infringement claims or leave you unable to protect work you assumed you owned. Caution and verification matter most where the output is published, sold, or built into a product, and least where it stays internal and disposable.

A team using AI to generate code checks the licenses of any suggested third-party components, and reviews generated marketing copy and images for close resemblance to existing protected works before publishing.

Note: Assuming AI output is automatically yours to own and automatically free of others' rights; both assumptions can be wrong, and the risk rises with verbatim or near-verbatim reproduction of distinctive content.

See also: Vendor and Model Risk, Human Accountability and Sign-Off, Disclosure: Tell People When AI Was Used

Security and Prompt-Injection Defence

Treat untrusted content the model reads as a potential attack, and do not let an AI take consequential action on it without a human gate.

When an AI reads web pages, emails, or documents, hidden instructions in that content can hijack its behavior, a class of attack known as prompt injection. The danger grows sharply when the AI can take actions like sending messages, running code, or accessing systems, because an injected instruction can become a real action. Limiting the AI's permissions and requiring human confirmation for consequential steps contains the blast radius even when an injection succeeds.

An assistant that summarizes incoming email is not given the ability to send replies or move money on its own, so a malicious instruction buried in a message cannot trigger an action without a person approving it.

Note: Trusting the output because the model is reputable, while overlooking that the attack rides in through the data the model processes, not through the model itself; granting broad tool access for convenience widens the exposure.

See also: Data Privacy: Know What Not to Paste, Vendor and Model Risk, Escalation Paths

Sensitive-Domain Limits

Set hard boundaries on AI use in high-stakes domains such as medical, legal, financial, and safety decisions.

In domains where errors cause serious harm, the cost of a confident wrong answer is too high to absorb, and AI produces fluent mistakes that are easy to miss. These areas demand qualified human judgment, genuine accountability, and often regulatory compliance that an automated tool cannot satisfy on its own. Defining where AI may assist but must not decide keeps it in a supporting role where its failures stay visible and recoverable.

A clinic permits AI to help draft patient-education material in plain language but prohibits using it to make diagnoses or treatment decisions, which remain with licensed clinicians.

Note: Scope creep, where a tool approved for low-risk drafting is gradually used for consequential decisions because it handled the easy cases well; fluency gets mistaken for competence.

See also: Human Accountability and Sign-Off, Bias and Fairness Review, Escalation Paths

Escalation Paths

Make it obvious how to report a problematic AI output, harm, or policy question, and ensure a named person owns the response.

People encounter bad outputs, near-misses, and ambiguous cases, and without a clear route to raise them, problems stay invisible until they become incidents. A defined escalation path turns scattered observations into signals the organization can act on, and it signals that surfacing concerns is expected rather than discouraged. Knowing who responds, and how quickly, matters as much as the path itself.

Staff have a named contact and a simple form to flag an AI output that produced biased, false, or harmful results, and flagged cases are reviewed within a stated timeframe by an accountable owner.

Note: A reporting channel that exists on paper but leads nowhere, so reports go unanswered and people stop bothering; the absence of any path means harms are handled quietly by whoever happens to notice, or not at all.

See also: Record-Keeping and Audit Trail, Sensitive-Domain Limits, Review Cadence

Review Cadence

Revisit your AI policies, tools, and risks on a regular schedule, because the technology and its hazards keep shifting.

AI capabilities, vendor terms, and threat patterns change quickly, so a governance approach set once will drift out of date and create false confidence. A scheduled review keeps policies, approved-tool lists, and risk assessments aligned with reality and folds in lessons from incidents and escalations. The exact cadence matters less than the commitment to actually hold the review and act on what it finds.

A governance group meets on a fixed schedule to review the tools now in use, update the acceptable-use policy, and examine the period's escalations for patterns that warrant a change.

Note: Treating governance as a one-time launch document no one returns to; or holding reviews that produce no changes, which signals the process is theater rather than control.

See also: Acceptable-Use Policy, Vendor and Model Risk, Escalation Paths