THE HUMAN EDGE Using AI with Judgement By Michael Borck ============================================================ ============================================================ SOURCE: index.qmd ============================================================ # Preface > Everyone has the same AI tools now. The edge is judgement. ## Why this book exists Something has changed at work, and it is easy to miss because the output looks so good. A report arrives. It is fluent, well structured, and complete. So does a data brief, a proposal, and a plan for a difficult conversation. Any professional with Copilot, ChatGPT, Claude, or Gemini can now produce work that looks like this, in minutes. Generic competence used to be an advantage. It is now the baseline everyone shares. This book has a name for working that way without noticing: vibe professionalism. Vibe coding produces plausible software without understanding it. Vibe professionalism produces plausible reports, analyses, and proposals without briefing them well, checking what they rest on, or owning the decision they feed. The work looks professional. The professionalism is missing. The failure is hard to spot. A rushed human draft looks rushed, and gaps show. An AI output that is wrong arrives polished, complete, and confident, in the same tone as an output that is right. The instinct you have spent your career building, the one that tells you weak work when you see it, stays quiet when you need it. This book teaches the alternative. When everyone has the same tools, the edge moves to what the tool cannot manufacture: your judgement. That means knowing what to ask for, deciding how much to trust the answer, checking it from outside the tool, and keeping a person in charge where the stakes require it. You will practise each of those on your own work. ## Who this book is for Professionals in any role and industry who use AI in their everyday work, or are about to. Team leaders who want to put AI into a team workflow responsibly will get particular value from Part 4. No technical background is required. You do not need to write code. You need real work to practise on, and a willingness to check output you would rather forward. If you lead decisions about which AI projects your organisation should fund, that is the companion volume, The Human Edge: Leading AI with Judgement, in development. This book builds the personal judgement that volume takes to the organisation. ## What this book is not It is not a guide to a particular AI tool. The four tools here work on Copilot, ChatGPT, Claude, Gemini, and whatever ships next. Product details, menu names, and model comparisons are confined to Appendix E, where they can date without taking the book with them. It is not a prompt library with a book wrapped around it. Appendix B gives you 27 starter prompts to copy and adapt. The chapters teach you to write your own, and to attach the right check to each one. It is not Conversation, Not Delegation retitled. That companion book teaches how to think with AI in any discipline. This book is narrower and more practical: how to stay credible at work when fluent AI output is everywhere. Where the two overlap, on RTCF and VET, this book teaches the working version and points to the deeper treatment. ## How this book is structured The book follows the Curtin Executive Education masterclass of the same name: four parts, one tool each, one question each. | Part | Tool | The question | You leave with | |---|---|---|---| | 1 · Judge | Trust Tool | How much should I trust this output? | A ten-second habit for every output | | 2 · Brief | RTCF | How do I ask for what I need? | Your own prompt library | | 3 · Check | Check Loop | How do I know it's right? | An analysis you have verified yourself | | 4 · Deliver | Opportunity Finder | Will it work every week? | A delivery plan with a 30-day gate | Part 1 explains what these tools produce and why their mistakes do not look like mistakes. You will learn to place any output in one of four corners in about ten seconds. The corner sets the check. Part 2 teaches briefing. Prompting is briefing a capable new colleague, and Context does most of the work. You will add upgrades when output is weak, push back when the tool agrees too easily, and save what works as a standing brief. Part 3 is about verification. You will analyse a real dataset with AI, then test three fluent claims made about it. One is verified, one is refuted, and one is overstated. You will also write down how you make one repeatable decision, and test those rules blind against calls you have already made. Part 4 takes the same judgement into delivery. You will choose one workflow from your own role, decide which steps AI leads and which stay with a person, design the human checkpoints in from the start, and set a Scale, Pivot, or Kill decision for 30 days' time. By the end, you should be able to: - decide how much to trust any AI output, on any tool, and check it from outside the tool; - brief AI so the first output is close to usable, and improve weak output without starting again; - use AI to analyse data without being fooled, and say what you checked; - put AI into one real workflow with human checkpoints designed in, and defend the 30-day call. ## How to read this book Work on your own tasks as you go. Each part ends in exercises drawn from the masterclass, collected in Appendix C. Keep a small record: your pass before AI, the brief you used, the corner you placed the output in, and what you checked. That record is the evidence that the work is yours. Most exercises need an AI tool you are allowed to use at work and a spreadsheet. Nothing in this book requires you to paste confidential material into a tool. Where your own work cannot go into a tool, use the scenario and decision cards in Appendix C, or the shape trick in Chapter 6: describe the data and let the spreadsheet do the sums. ## Conventions used in this book Green boxes are short exercises you can do now, most in five to twenty-five minutes. Blue boxes mark an idea, a prompt, or a distinction worth pausing on. Yellow boxes flag fluent output that looks right and is not, and the habits that let it through. Red boxes mark the checks and safeguards that are not optional. Do not skip these. RetailFlow, the fictional retailer whose customer service data you will analyse in Chapter 6, appears in grey case boxes. Its dataset is available with the online edition. ## How this book was written This book began as a one-day masterclass, The Human Edge: Using AI with Judgement, first marketed as AI for Professionals: Building Everyday Capability. The slides, exercises, field guide, and companion site from that day are the skeleton. The chapters expand the speaker notes, show the worked answers the room produced, and add the reading a single day has no room for. It was written using the method it teaches. AI drafted, the author pushed back. Claims that sounded right were checked against the dataset and the sources. Every figure in the RetailFlow case was recomputed from the file readers download. If that makes you ask whether you should trust it, Chapter 1 gives you a tool for answering that question about any output, including this book's own. Sources and credits. Australian evidence in Chapter 11 draws on the Department of Employment and Workplace Relations (2026) and Jobs and Skills Australia (2025). The Decide Like Me method in Chapter 8 draws on Dylan Davis. "Gell-Mann amnesia" is Michael Crichton's term (2002), named after the physicist Murray Gell-Mann. The Trust Tool, RTCF, and conversation-not-delegation ideas are developed at greater length in Conversation, Not Delegation. ## Ways to engage with this book - Read it online. The full book is freely available at the companion website, with search and navigation. - Download the PDF or EPUB. Generated from the same source, available from the website. - Do the day. The masterclass companion site has the interactive workbook, the prompt builder, the Trust Tool game, and the slides: michael-borck.github.io/the-human-edge. - Converse with it. Use the `llm.txt` file to load the book into an AI tool, then apply Chapter 7 to what it tells you. - Explore the source. The full source is on GitHub, including the chapter map and the source-site archive this book was seeded from. - Browse all books. This book is part of a series. See all titles at books.borck.education. The online version is always the most current. ## Where this book sits The series has a conceptual trunk and domain branches. Conversation, Not Delegation is the method; this book is the practice. The branches take those habits into code, web work, security, teaching, evidence and building with agents. The trunk was named after the branches grew. The books came first, and the same ideas kept returning under different names. Naming them now makes the relationship explicit; it does not make the series a hierarchy. | Route | Start here | Continue with | |---|---|---| | Everyday professional work | The Human Edge: Using AI with Judgement | Conversation, Not Delegation | | Choosing AI investments | The Human Edge: Using AI with Judgement | The Human Edge: Leading AI with Judgement (in development) | | Evaluating applied AI | Prove, Don't Persuade | Substantiate, Don't Assume | | Teaching with AI | Partner, Don't Police | Conversation, Not Delegation | | Building with agents | Speak Software | Build AI, Understand AI | | Understanding the machinery | Build AI, Understand AI | Speak Software | Start here if you want judgement at your own desk first. Start with Conversation, Not Delegation if you want the general method of thinking with AI before the workplace tools. ============================================================ SOURCE: copyright.qmd ============================================================ # Copyright The Human Edge: Using AI with Judgement © 2026 Michael Borck. Book content is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0 International). Original code examples and accompanying software are licensed under the MIT License. These grants cover material the author has authority to license. Separately credited third-party material retains its stated terms. Give appropriate credit, link the content licence and indicate changes; retain the MIT notice when reusing code. ISBN: (to be assigned) The online edition is the canonical version: michael-borck.github.io/the-human-edge-using. RetailFlow and Northbridge are fictional companies created for teaching. Any resemblance to real organisations is coincidental. The Decide Like Me method in Chapter 8 draws on Dylan Davis, as credited there. "Gell-Mann amnesia" is Michael Crichton's term (2002). ============================================================ SOURCE: chapters/01-the-convincing-average.qmd ============================================================ # The Convincing Average > Fluent is not the same as correct. ## Vibe professionalism There is a new way to look competent at work, and it requires almost no competence at all. Ask an AI tool for a plan, a brief, or an analysis. Forward what comes back. The document will be fluent. It will be structured. It will usually be about right. Nobody can tell from the document whether you briefed it well, checked what it rests on, or understood a word of it. Programmers have a name for the coding version of this. Vibe coding means describing software, accepting what the tool produces, and not reading the code. The professional version deserves the same name: vibe professionalism. It is reports, analyses, and proposals produced on vibes, polished output with no judgement behind it. The alternative is the same tools, used with judgement and without slowing the work: briefed well, placed before they are trusted, checked from outside, and delivered with a person visibly in charge. To use them that way, you need ten minutes of background and no computer science: just enough to know what kind of thing you are talking to, and why it fails the way it does. ## AI is a bigger pie Machine learning learns patterns from data rather than following hand-written rules. It sits behind fraud scores, demand forecasts, spam filters, and recommendations. It is probably already running inside your organisation, whether anyone calls it AI or not. Deep learning uses many-layered neural networks. It powers speech recognition, image understanding, and translation. Generative AI produces new text, images, audio, or code. Large language models are generative AI for language. They power the chat tools this book focuses on: ChatGPT, Claude, Gemini, and Microsoft Copilot. The focus is on chat tools for a practical reason. You can use them yourself, today, in plain language, on your own work. But the judgement in this book applies to any AI output. A fraud score, a forecast, and a chatbot reply all have to be placed and checked. If someone asks whether your organisation's forecasting model is AI, the answer is yes, and Chapter 2 applies to it in full. ## What these tools actually do A language model is trained on an enormous amount of text. It learns to predict which words are likely to come next. It is then tuned to follow instructions and be helpful. Ask it a question, and it produces the most plausible response to that question, one word at a time. Modern assistants add more on top. Many can search the web, read your files, and write and run small programs to do calculations. That has made them far better at arithmetic and current events than they used to be. Underneath, though, the core is still prediction. That one fact explains both what they are good at and how they fail. What you get back is a convincing average. Fluent, well structured, and usually about right. For a first draft, a summary, or a list of options, about right is often exactly what you need. For a contract figure, a citation, or a client's account balance, about right is the same as wrong. A language model does not look things up in a store of facts, unless the product around it does that for it. It generates the response that best fits the request. A wrong figure and a right one are produced by the same process, in the same tone. Nothing in the output marks the difference. That marking is your job. ## Where they help, and where they go wrong | Usually strong | Watch closely | |---|---| | Drafting emails, reports, proposals, and job ads | Specific facts: names, figures, dates, citations, legal detail | | Summarising and restructuring long documents | Your context: it knows nothing about your organisation unless you tell it | | Brainstorming options and counter-arguments | Agreeing with you: models are tuned to please, and often back down when challenged | | Explaining unfamiliar topics in plain language | Analysis framing: what was counted, what was left out, what was read as cause | | First-pass analysis of a spreadsheet | Anything that needs a person to be accountable for the decision | Read the right-hand column as the agenda for this book. Context is fixed by briefing (Part 2). Specific facts and framing are fixed by checking (Part 3). Accountability is fixed by deciding where a person stays in charge (Part 4). Agreement is fixed by pushing back (Chapter 4). ## The trap: mistakes that don't look like mistakes You have spent your career learning to spot weak work. A rushed draft looks rushed. Gaps show. A junior colleague who is guessing sounds like it. AI output breaks that signal. Its wrong answers arrive polished, complete, and confident. They use the same headings, the same tone, and the same level of detail as its right answers. So the alarm you normally rely on stays quiet when you need it. There is a second, quieter version of the same trap. You catch the tool's errors easily in your own field. Then you trust it on the law, the market, or the numbers, where you are least able to check. Michael Crichton named this pattern in 2002, after the physicist Murray Gell-Mann: Gell-Mann amnesia. Chapter 7 gives you a method for it. For now, hold the rule: be most sceptical where you know least. The most dangerous output is not the obvious mistake. It is the one that sounds completely right. Polish is part of the product. It tells you nothing about accuracy. ## Your pass first The first habit costs five minutes and protects everything after it. Before you give a task that matters to AI, do a rough pass yourself. A sketch is enough: the structure you would use, the three points that matter, the figure you expect to be roughly true. Then run the AI. Then compare. The comparison is where the value sits. Where you beat the tool is almost always context: the history, the politics, the thing nobody wrote down. Name that for what it is. That is your edge, and no model update takes it away. Where the tool beat you is a blind spot worth practising. Chapter 11 turns this into a weekly habit. Take this task, or one like it from your own week: > I manage a team of 8 in a mid-sized company. One of my team, a strong performer for three years, has been late and missing deadlines for the past month. Others are starting to notice. Write me a plan to address this. 1. Your pass first. Five minutes, no AI. Sketch your own plan. 2. Then AI's. Paste the task, unedited, into an AI tool. Use two tools if you have them. 3. Compare side by side. Where did you beat it? Where did it beat you? What did it get confidently wrong? In the masterclass, the comparison reliably surfaces the same things: different assumptions about tone, nobody asking about personal circumstances, confident employment advice nobody in the room could verify, and plans that are too punitive or too soft. The sentence to listen for in yourself is: "I'd take its structure and my judgement." That sentence is this book in miniature. Before anyone pastes anything into a tool, one rule comes first. Nothing confidential or personal goes into a tool your organisation has not approved. Appendix D covers data, privacy, and disclosure in full. ## What to carry forward - The output is a convincing average. About right is useful, until the task needs exactly right. - Mistakes do not look like mistakes. Your usual alarm will not fire. - You trust the tool most where you know least. Reverse that instinct. - Your pass first. Five minutes of your own thinking turns you from a forwarder into an editor. The next chapter turns "can I trust this?" into a ten-second decision you can make about any output, on any tool. ============================================================ SOURCE: chapters/02-the-trust-tool.qmd ============================================================ # The Trust Tool > Two questions place the output. The corner sets the check. ## A ten-second habit "Can I trust this?" is too vague to answer. It collapses two different questions into one feeling, and the feeling is usually wrong, because fluent output feels trustworthy whether it is or not. The Trust Tool separates the questions. Ask both about any output, before you act on it. 1. How exact must it be? Average means the ballpark is fine: a draft, a summary, a list of ideas. Precise means there is one right answer, and close is the same as wrong: a figure, a name, a date, a citation, a clause. 2. What happens if it is wrong? Small means cheap to fix and nobody harmed. Large means money, safety, reputation, or someone's job or wellbeing. Two questions, four corners. Precision runs across. Consequences run up. | | Average is fine | Precise, one right answer | |---|---|---| | Large consequences | B · Verify the load-bearing bits. Check the claims the output rests on. | D · Human in the loop. AI can help. A person decides, and signs. | | Small consequences | A · Trust with light review. Use it. Skim before it goes out. | C · Verify before you ship. Check every figure, name, and date. | The corners come with examples worth memorising. A birthday message for a colleague is corner A. A statistic quoted in a newsletter is corner C: easy to check, embarrassing in print. A strategy memo for the executive team is corner B: the prose can be average, but the three claims it rests on cannot. The figures in a board paper are corner D. Rule of thumb: lean in where about-right on low stakes is fine. Keep a person in charge where exactly-right meets high stakes. ## The corner sets the check - Corner A: read it once, as its reader would. Then use it. Spending twenty minutes verifying a birthday message is its own kind of failure. - Corner B: find the load-bearing claims. There are usually two or three: a deadline, an eligibility rule, a budget figure. Verify those against the source. Let the rest of the prose be average. - Corner C: check every precise element before it leaves you. Figures, names, dates, citations. One wrong publication year in print means a correction and a dent in credibility. - Corner D: AI may draft, structure, and list options. A person owns every word and figure, and makes the decision. Entitlements, safety figures, and anything about a person's livelihood live here. ## Check from outside the tool Asking the AI "are you sure?" does not count as a check. The tool tends to agree with itself, because agreement is what it was tuned to produce. The check comes from outside: the source document, the data itself, your own arithmetic, or a colleague who knows. Better models move the corners. They never remove the check. This one rule does most of the work in Part 3. Verification from outside feels slower than asking the tool to double-check. It is also the only kind that works. ## Place it: five scenarios In the masterclass, the room votes blind on scenarios like these, without seeing how anyone else voted. Blind matters, because it stops the room following the most senior person. Place each one yourself before reading the usual answer. 1. Rewrite your out-of-office message to sound friendlier. Corner A. The ballpark is fine, and a mistake is cheap. If you said B, ask what would actually go wrong. 2. Summarise a 40-page tender so your team can decide whether to bid. Corner B. The deadline, eligibility rules, and budget carry the decision. The decision to bid is already human. What needs checking is the three facts it rests on. 3. The publication year of a study you will cite in an internal newsletter. Corner C. One right answer. Wrong in print means a correction. If you said A because it is "only internal", ask who forwards newsletters. 4. Talking points for a difficult conversation with a team member. This one splits B and D, and the split is the lesson. B voters see a draft to adapt. D voters see a person's wellbeing. Both are right about something. 5. A letter telling a staff member their role is redundant. Corner D. Entitlements, law, and a livelihood. AI can help with structure. A person owns every word and figure. Two spares, for the pattern. Meeting minutes from your own notes are corner A, because you were there and minutes get corrected at the next meeting. A dosage or safety figure in a site procedure is corner D, because precise meets safety, and a person sources it and signs it. When people disagree about a corner, they almost always disagree about stakes, not precision. And stakes depend on who sees the output next. A formula in a budget spreadsheet is corner C if you will check it before it leaves you. It becomes corner D the moment it feeds a decision without another pair of eyes. ## Two traps that distort placement Gell-Mann amnesia, from Chapter 1, pushes everything in your own field toward D and everything outside it toward A. That is backwards. Your expertise is a checking instrument. Where you lack it, the output needs more outside verification. The mirror-image trap is the AI dismissal fallacy: "that's just ChatGPT" offered as a critique. That refuses to engage with the claim. Judge the reasoning, not where it came from. A correct claim from a tool is still correct, and a polished claim from a person can still be wrong. ## Practise until it is a reflex 1. List three tasks from your own week where you used AI, or wanted to. 2. Place each one in a corner. Write down the check the corner calls for. 3. Swap with a colleague, or argue the opposite corner yourself. Where do you disagree, and is the disagreement really about who sees the output next? The online Trust Tool game at trusttool.borck.education gives you ten scenarios from a domain you choose, with an explanation on every card. Ten minutes of play does more than an hour of reading about the grid. ## Three rules before you paste Placement protects what comes out. One more habit protects what goes in. 1. Classify it, then pick the tool. Know whether your material is public, internal, or confidential, and which tools your organisation has approved for each kind. 2. Leave out what identifies people. Names, client details, and personal information rarely change what the tool produces. Describe the case instead. 3. Know what the tool remembers. Check the training, memory, and history settings of any tool you use for work, and review them when the product changes. Appendix D develops all three, with Australia's six essential practices and the privacy rule for automated decisions. ## What to carry forward - Two questions: how exact, and what if wrong. The corner sets the check. - Disagreement about corners is usually disagreement about stakes. Stakes live with the next reader. - Check from outside the tool. "Are you sure?" is not a check. - Classify before you paste. Leave out what identifies people. You can now decide how much any output can be trusted. Part 2 is about the other half of the exchange: asking well enough that the first output deserves your time. ============================================================ SOURCE: chapters/03-brief-like-a-colleague.qmd ============================================================ # Brief Like a Colleague > Prompting is briefing, not spell-casting. ## The disappointing first output Most professional frustration with AI has the same shape. You type a short request, the way you would type a search query. Back comes something generic: correct in outline, useless in detail, written for nobody in particular. You conclude the tool is overrated, or you spend ten turns nudging it toward what you needed. The brief was the main problem. A language model fills gaps with the average. Every detail you leave out (the audience, the history, the constraint, what good looks like) comes back as a guess, and the guesses are what make output feel generic. Write the prompt the way you would brief a smart, fast colleague who is new to your job. RTCF is the checklist that makes it repeatable. ## RTCF: Role, Task, Context, Format | Part | Ask yourself | Example | |---|---|---| | Role | Who should it write as? | A senior HR adviser in a mid-sized Australian firm | | Task | What exactly, and how much? | Draft a reply to the client. Under 200 words. | | Context | What does it need to know? | 18-month client. Their board shifted priorities. I want a meeting, not a rewrite. | | Format | What should it look like? | Email. Acknowledge, explain, propose, close. | A good brief for real work runs four to eight sentences. That feels long the first time. It is still faster than three rounds of correction. Context does most of the work, because it is the only part the tool cannot guess. Audience, situation, stakes, constraints, and the material itself all live in Context. When a second attempt barely improves on the first, the missing ingredient is almost never a cleverer Role. It is the thing you would have told a new hire in the first two minutes. Role does the least. On current models, "you are an expert" adds tone more than capability. Use Role to set voice and level, then spend your effort on Context and Format. Be honest with yourself about this if you learned prompting from tip lists. The lists were written for weaker models. ## A before and after Before, the way most people write it: Write an update on the project for the steering committee. After, with RTCF: ROLE: You are an experienced project manager who writes plainly. TASK: Turn my notes into a weekly status update for the steering committee. CONTEXT: The audience is time-poor and allergic to surprises. We are two weeks behind on data migration, on budget otherwise, and the delay does not move the launch date because testing can overlap. Good looks like: the delay stated in the first two lines, with the recovery plan attached. [Paste your notes here.] FORMAT: RAG status line, three bullets on progress, a small risks table, next steps with owners. Under 300 words. Run both in fresh chats and compare. The second output is not better because the prompt is longer. It is better because the decisions a colleague would have asked about are already in it. ## Five common mistakes 1. The search-query prompt. Three words, no audience, no purpose. Average in, average out. 2. Role and nothing else. "You are a world-class strategist" followed by no context. The tool performs confidence it has not earned. 3. Asking for everything at once. A report, an analysis, and a slide outline in one request, all of it shallow. Split the job (Chapter 4). 4. No definition of done. No length, no structure, no standard. The tool cannot hit a target you have not named. 5. Pasting without classifying. Real client material into an unapproved tool, because the brief needed context. Context can almost always be described without identifiers. Chapter 2 and Appendix D cover the rules. ## One task, or every task RTCF shapes the prompt you type for one job. It also shapes the standing brief you save once and reuse: custom instructions in ChatGPT or Copilot, instructions and Projects in Claude, Gems in Gemini. The generic name is a system prompt. The standing brief holds what is true every time: who it writes as, the context that does not change, your usual format, and your definition of done. The Task stays in each chat. Chapter 5 builds that brief, and Appendix E shows where each product keeps it. When a vendor demo claims the AI "understands you", look for this setting: it is a text box, and by the end of Part 2 you will have written a better one. ## Practice: brief it, score it 1. Pick a real task from your week. Confidential? Use a scenario card from Appendix C. 2. Round 1: write the prompt the way you normally would. Run it. Score the output from 1 (unusable) to 5 (ready to use). 3. Round 2: rewrite it with RTCF and run it in a fresh chat. Score it again. 4. Note which part moved the score most. In the masterclass, it is Context, by a wide margin. Coaching notes from the room. If Round 2 barely moved, ask: what would I tell a new hire? If you added a Role and nothing else, add Context and Format and run it again. If your Round 2 prompt is under three sentences for a task that matters, it is probably still a search query wearing a suit. ## What to carry forward - Brief a colleague, not a search engine. Four to eight sentences for work that matters. - Context does the work. Role sets the voice. - Name what done means, or accept the average. - Every gap you leave comes back as a guess. Guesses are what generic output is made of. A good brief gets you close. The next chapter is for the common case where close is not enough: weak output from a smaller, older, or free-tier model, and output that agrees with you too easily. ============================================================ SOURCE: chapters/04-upgrades-and-pushback.qmd ============================================================ # Upgrades and Pushback > Add one upgrade before you rewrite from scratch. Push back before you believe. ## Still weak? Add one upgrade A solid RTCF brief on a strong model usually lands close. Two situations still produce weak output. The task is long or multi-part, so the tool spreads itself thin. Or your organisation has approved a smaller, older, or cheaper model, which needs more scaffolding than the flagship in the advertisements. In both cases, resist the urge to rewrite the whole prompt. Add one upgrade. | Upgrade | Line to add | Use it when | |---|---|---| | + Example | `Match the length and tone of this example: [paste one you liked]. Don't copy its content.` | The shape is wrong, whatever you say | | + Done | `Done means under 200 words, figures only from my notes, and anything you're unsure of marked [CHECK].` | Output keeps missing the same way | | + Questions | `Before you start, ask me up to five questions, one at a time.` | You don't yet know what context it needs | | + Steps | `Give me an outline only. We'll draft one section at a time.` | Long work, or a weaker model | Example is the strongest single upgrade. One artefact you already like (a past update, a good email, last quarter's brief) communicates length, tone, and structure faster than any description of them. Chapter 5 turns this into teaching the tool your voice. Done converts omission into a visible mark. The `[CHECK]` instruction matters. Without it, a model fills a gap with a plausible guess. With it, the gap arrives labelled. You still verify from outside. Now you know where to look. Questions reverse the briefing. If you cannot tell what context is missing, let the tool ask. Cap the number, and ask for one at a time, or you will get a questionnaire instead of a conversation. Steps protect quality on long jobs. An outline first means structure is agreed before prose exists. Section by section means each part gets the tool's full attention, and your corrections land early, while they are cheap. ## Push back: three ways Models are tuned on human approval, and people prefer agreeable answers. The result is sycophancy: the tool endorses your plan, praises your draft, and folds the moment you disagree with it. An agreeable second opinion adds nothing to the opinion you already had. Ask badly ("what do you think?") and you will get flattery. Ask for attack, and you get something useful. | Move | Line to add | |---|---| | Guardrail | `Only change your assessment if I give you a new fact. Name the fact that changed it.` | | Devil's advocate | `Don't flatter me. Give me three reasons this fails, and name the assumption it all rests on.` | | Board of directors | `Respond as a board: a CFO, a sceptical customer, and a frontline manager. One paragraph each, then where they disagree.` | The guardrail is for analytical work, where you plan to add information in stages and need to know what moved the answer. The devil's advocate is for plans and drafts you are fond of, which is when you need it. The board is for decisions, where the disagreement between perspectives is the useful part. Read the disagreement paragraph twice. It usually names the real trade-off. Long chats drift toward your view. The tool has your framing, your vocabulary, and your earlier conclusions in front of it, and agreement gets easier with every turn. For an independent read on something that matters, start a fresh chat, brief it cold, and compare. Two-chat discipline returns in Chapter 5. ## The three cognitive traps, revisited Pushback is the behavioural fix for traps worth naming together, because knowing their names is the first defence. - Gell-Mann amnesia. Sharp where you know, trusting where you don't. Be more sceptical where you know less. - The AI dismissal fallacy. "That's just ChatGPT" is not a critique. Judge the reasoning, not the source. - Sycophancy. The tool agrees because agreement was rewarded in training. Treat agreement as no evidence at all. All three are human problems, so a model upgrade will not fix them. ## Practice: upgrade and save 1. Take your best prompt from Chapter 3. Add one upgrade. Run it in a fresh chat. 2. Apply one push-back move to the output. Note what changed, and whether the change was earned by a new fact or was just folding. 3. Repeat for two more tasks from your week. 4. Save all three prompts, each with a name, the situation it is for, and the check its output needs (its Trust Tool corner from Chapter 2). Three saved prompts, each paired with its check, is a personal prompt library. It is also the masterclass promise: you leave with tools that fit your role, not a list of someone else's. The prompt builder on the course site formats and exports a library like this. A plain text file works just as well. Fast finishers in the room do the voice pass here: give the tool a 100-word sample of your own writing, have it rewrite its output in your voice, and ask it to describe the voice as a short style brief. That is the bridge to the next chapter. ## What to carry forward - Weak output gets one upgrade, not a new prompt. Example first, then Done, Questions, or Steps. - Agreement is not evidence. Ask for the three reasons it fails. - Fresh chats think independently. Long chats agree with you. - Save what works, with its check attached. You now have briefs that work once. Chapter 5 makes them work every time: your voice, your standing brief, and the discipline of separating thinking from building. ============================================================ SOURCE: chapters/05-teach-it-your-voice.qmd ============================================================ # Teach It Your Voice > Write like me teaches it how you sound. Chapter 8 teaches it how you choose. In both, it drafts and you decide. ## From prompt library to standing brief All through Part 2 you have typed the brief fresh: role, task, context, format, and a check. That is the right way to learn. It is a poor way to work forever, because half of most briefs never changes. Every major tool lets you save the unchanging half as a standing brief, sent with every message. The generic name is a system prompt. The trade names differ: custom instructions and Projects in ChatGPT, instructions and Projects in Claude, Gems in Gemini, custom instructions in Copilot. Appendix E has the table of where each one lives, with the usual warning that menu names move. What goes in: your Role, the Context that is true every time, your Format preferences, and your Done line. What stays out: the Task, which changes each chat, and anything confidential you would not paste into a conversation. Review the saved brief each quarter. Your role shifts, your standards sharpen, and the Trust Tool corners move as models improve. A standing brief should move with them. Chapter 11 returns to that review rhythm. ## Write like me This makes the + Example upgrade from Chapter 4 permanent. 1. Give it a sample. About 100 words of your own writing that sounds like you on a good day. Nothing you can paste? Write 100 words on why your current project matters. Spoken and transcribed also works, and often sounds more like you than typed text does. 2. Ask for a rewrite. Have the tool rewrite a piece of its own generic output in the voice of the sample. Compare. Correct what it got wrong: too formal, sentences too long, a phrase you would never use. 3. Ask for the style brief. Have it describe your voice as short instructions: sentence length, directness, words you favour, words you avoid, how you open and close. 4. Save the brief, not the sample. Put the style brief into your standing brief. A screen of rules travels better than pasted examples, and carries no client detail with it. A voice brief is a small act of professional self-knowledge. Most people have never described how they write. The tool's first description will be flattering and vague. Push back with specifics ("shorter than that; I don't use exclamation marks; I state the problem in the first line") until the brief would let a colleague imitate you. Then it will work on the tool, too. Voice is also a disclosure issue, handled in Appendix D. Output in your voice is still AI-assisted output. Your name goes on it, which means the check in Part 3 applies in full. ## The two-chat workflow One chat for everything produces one muddled artefact: half thinking, half draft, with your early guesses baked into the final text. Separate the two activities. 1. Thinking chat. Explore. Challenge assumptions, follow tangents, find out what your actual question is. Messy by design, and disposable. Use the push-back moves from Chapter 4 here, or the chat drifts toward your first view. 2. In between: you curate. Read what came out. Keep what matters, drop what doesn't, and write a short, focused brief in your own words. Do not copy and paste the chat across. The curation is where your judgement lives. 3. Building chat. A fresh chat that produces the output from your brief. Better input, better output, and no residue from your discarded first ideas. Only you hold the whole picture, which is what "human in the loop" means in practice at the scale of one professional and one task. Two practical notes. First, for thinking out loud, the model barely matters. You are the filter, an average idea is a fine stimulus, and a small or local model is enough. Save the strongest tool you have for exact facts and data work. Second, dialogue works as a thinking method only if the other side pushes back. Research on teaching critical thinking finds dialogue one of the strongest levers available (Abrami et al., 2015). That research is about people talking with people. The AI version earns the same benefit only when you demand disagreement. ## The handover prompt Long chats drift. Early instructions fade as the conversation grows, and output quality slides in ways that are hard to notice from inside. Before you close a long chat, extract its value: Write a handover prompt that captures everything important from this conversation: the context, the decisions made, open questions, and where we left off. I'll paste it into a new chat to continue. Read the handover before you reuse it. It is output, so it goes on the Trust Tool like anything else. Edit out the dead ends while you still remember they were dead ends. ## Practice 1. Take your three saved prompts from Chapter 4. Extract what they share: role, recurring context, format habits, your Done line. 2. Add a voice brief from the Write Like Me steps above. 3. Save the result where your tool keeps standing instructions. Run one old task with and without it, in fresh chats. Score both from 1 to 5. 4. Put a quarterly reminder in your calendar to review the brief. ## What to carry forward - Save what never changes. Keep the task in the chat. - Teach it your voice with a sample, a rewrite, and a style brief you have corrected. - Think in one chat, build in another. You are the only one holding both. - Hand over deliberately when a chat gets long. Read the handover like any other output. Your briefs now produce output that sounds like you and fits your work. That makes the next part more important. Output in your own voice is easier to forward without checking. Part 3 is the checking. ============================================================ SOURCE: chapters/06-the-check-loop.qmd ============================================================ # The Check Loop > Fast analysis, slow trust. ## The brief Karen nearly got Karen runs customer service at RetailFlow, a fictional retailer invented for the masterclass. She needs a short brief on six months of support tickets. She needs it before a meeting. Someone on her team uploads the data to an AI tool, asks what is going on, and gets back a clean, confident answer. Three claims from that answer will run through this chapter. Read them the way Karen would. - Claim A. Email is our slowest channel. Average first response is about three times slower than Live Chat. - Claim B. Account Issues has the lowest customer satisfaction of any category. These queries are the most complex, and many never get resolved. - Claim C. Sundays are a staffing problem. Response times on Sundays are double the overall average. All three sound plausible. All three arrived in the same professional tone. One is verified. One is refuted, twice over. One is overstated. If the brief goes to Karen unchecked, she may fix the wrong category and overstate a staffing case by a third. She will do both in good faith, because the document gave her no reason not to. Hold your verdicts. The chapter teaches the loop first, then checks the claims against the data. ## The loop AI makes analysis fast. It does not make analysis trustworthy. The Check Loop separates those two facts into four steps. 1. Frame. Write the question and the decision it feeds. Start a fresh chat. "What is happening in this data?" is not a frame. "Which two changes would most lift satisfaction next quarter, and what would we stop doing to fund them?" is a frame, because it names the decision. 2. Explore. Ask the tool to describe the data before it analyses anything. How many rows, which columns, what date range, how many missing values. Compare that description with what you know. Most people skip this step, and it is the cheapest error detector in the chapter. If the tool has already miscounted the file, everything after it is fiction with headings. Then go broad to deep. Overall patterns first, then the category, channel, or period the decision turns on. 3. Verify. If a number would change a decision, check it yourself. Filter the spreadsheet. Recount. Open the source rows. If the number does not hold, go back to Explore with what you learned. Verification comes from outside the tool, as Chapter 2 insists. A second AI agreeing with the first one is not verification. It is two guesses in the same accent. 4. Shape. Write for the reader, who is usually Karen at 8.55 before a 9 o'clock meeting. End with one line that says what you checked and how. That line is small and it changes the document. It tells the reader someone did the work, and it commits you to having done it. Write the "what I checked" line even when nobody asks for it. Especially then. A brief that ends with Checked: category averages and channel response times recomputed from the source file, 27 October is a different artefact from one that ends with a confident paragraph. The first one can be trusted, challenged, and reused. The second can only be forwarded. ## Five ways a smooth answer goes wrong Watch for these in any AI analysis, including your own. 1. Miscounts after filtering. The tool reports a total for a subset it never isolated. Averages drift. Row counts shrink. 2. Correlation sold as cause. Slow responses and unhappy customers travel together. That does not prove one caused the other, and it matters for what you fix. 3. Missing rows skipped silently. Blank satisfaction scores vanish from the average. Nobody mentions it. 4. Numbers that cannot all be true. Category shares that sum past 100 percent. An overall average outside the range of its parts. 5. Detail that is not in the file. A plausible explanation for a pattern, invented to fill a paragraph. The data contains no such fact. That last one catches experienced people, because a good explanation still is not evidence. ## Checking the three claims The RetailFlow file has 260 tickets from 3 July to 29 December 2024, handled by 8 agents. You can download it from the course site and repeat every check below in a spreadsheet. Do that at least once. By category | Category | Tickets | Satisfaction | Response (h) | Resolved | |---|---|---|---|---| | Returns and Refunds | 48 | 1.56 | 13.3 | 77% | | Delivery Problems | 43 | 2.17 | 11.0 | 77% | | Billing Queries | 40 | 2.79 | 9.8 | 92% | | Account Issues | 28 | 3.06 | 8.8 | 96% | | Product Information | 37 | 3.88 | 5.5 | 89% | | Order Tracking | 64 | 3.90 | 6.7 | 92% | Response time. Overall 9.2 hours. By channel, fastest to slowest: Live Chat 4.0, Phone 6.1, Social Media 9.4, Email 13.2. By day, Sunday is slowest at 13.7 hours and Thursday fastest at 7.4. December blows out to 13.6 hours against 7.2 in November. Response time and satisfaction. Tickets answered within 4 hours average 4.09 for satisfaction. Tickets that wait over 12 hours average 1.64. Claim A is verified. Email at 13.2 hours against Live Chat at 4.0 is 3.3 times slower. Note what that felt like to read. The true claim sounded no more confident than the false ones. Tone carried no information at all. Claim B is refuted, twice. The lowest satisfaction belongs to Returns and Refunds at 1.56. Account Issues sits mid-table at 3.06. The excuse built into the claim also collapses. Account Issues has the highest resolution rate in the file, 96 percent, so "most complex, often unresolved" is the opposite of the record. This is the dangerous kind of error. It comes with a reason attached, and the reason makes it feel checked. Forwarded to Karen, it sends next quarter's effort to the wrong team. Claim C is overstated. Sunday runs at 13.7 hours against an overall 9.2. That is about one and a half times, not double. In a staffing case the word "double" inflates the argument by a third. This output sits in the precise, large corner of the Trust Tool, and in that corner close is the same as wrong. One more trap hides in most tool output on this file. Asked why Sundays are slow, tools often explain that nobody works on Sundays. The data says otherwise. Named agents handle Sunday tickets all through the file. That explanation is plausible, fluent, and unsupported: Claim 5 on the list above, caught in the wild. ## The confident miscount Cloud tools get the RetailFlow sums right mostly because they run code on the file behind the scenes. Take that away and the underlying weakness shows. In class testing in October 2026, a capable local model given the raw CSV reported 130 rows instead of 260. It put Email at 12.4 hours and Live Chat at 5.8, against true values of 13.2 and 4.0. It judged the Sunday claim with numbers that would have given the wrong verdict for the wrong reason. A smaller model got none of the figures right. Both answered in complete, confident sentences. I find that demo more persuasive than any warning slide. The model was not lying. It was predicting plausible numbers, because plausible numbers are its product. Which points to the fix. Do not ask a language model to count your file in its head. Ask it for the spreadsheet formulas, or a short script, and let software built for sums do the sums. The starter prompts in Appendix B include this pattern. It has a second benefit, covered next. ## When your data cannot go into a tool Plenty of real data should never be uploaded anywhere. The Check Loop still works. Use the shape trick. Describe the columns, types, and rough size of your data. Leave the data itself on your machine. Ask the tool for formulas, a script, or a single web page that runs in your browser and reads the file locally. Test what it gives you on RetailFlow first, where you know the answers. Then run it on the real file. Two cautions. If you cannot read the code it produced, the output belongs in the top-right corner of the Trust Tool, however neat it looks. And check that a generated web page sends the file nowhere. Local means local, or the whole exercise was theatre. ## What a strong brief to Karen says With the claims settled, the brief is straightforward: - Returns and Refunds and Delivery Problems are the worst categories, by a clear margin. - Response time is the factor that cuts across everything. Fast answers sit near 4 out of 5 for satisfaction. Slow ones sit near 1.6. - The blow-outs are predictable. Sundays, Mondays, December, and the Email channel. - So fix the returns process first. Steer customers toward Live Chat where the query suits it. Staff for the peaks you can already see coming. - End with what was checked. Notice that none of that required a better model. It required a frame, a description check, three verified claims, and the discipline to fix the brief before Karen saw it. In the exercise, that order is deliberate. People draft the brief first, then check the claims against their own draft. Anyone whose brief repeated Claim B finds out in the room, which is a much better place to find out than Karen's meeting. Download `retailflow-customer-service-data.csv` from the course site or this book's resources. 1. Frame and explore (10 min). Fresh chat. Ask the tool to describe the file before analysing it. Check the description against the file. 2. First brief (7 min). Write Karen a one-page brief: what is wrong, what to fix first. 3. Check the claims (10 min). Test Claims A, B, and C from this chapter in your spreadsheet. Verdicts: verified, overstated, refuted, or can't tell yet. 4. Fix and sign (8 min). Correct your brief. Add the line that says what you checked. ## What to carry forward - Frame the decision, describe the data, verify outside the tool, then shape for the reader. - The true claim and the false one arrive in the same tone. Check the load-bearing numbers every time. - Let spreadsheets do arithmetic. Let language models do language. - End every brief with what you checked. Your name is on it. Data you own can be checked against the source file. Claims about the world cannot. The next chapter covers those. ============================================================ SOURCE: chapters/07-vet-and-the-quiet-defaults.qmd ============================================================ # VET and the Quiet Defaults > The Trust Tool says how much to check. VET says how. ## Claims you cannot recount Chapter 6 worked because the truth sat in a file you could open. Most claims at work offer no such comfort: a market figure, a legal summary, a study that shows something convenient, a benchmark with a percentage in it. You cannot filter a spreadsheet to settle those. You need a different discipline, and it has three moves. Verify, Explain, Test. VET. Use it hardest in two situations. A decision hangs on the claim. Or people will assume you checked because checking is your job. The second one catches more professionals than the first. ## Verify the source yourself Can you find this claim without the tool's help? AI produces references that do not exist. This still surprises people, and it should not. A citation is text. The tool generates a fake one the same way it generates a real one, by predicting what a citation in this spot probably looks like. Authors with plausible names, a journal that exists, a year that fits, a title on topic. Nothing underneath. So look the source up directly. If the paper exists, open it and check the claim says what the tool said it says. Summaries of real sources drift too, usually toward whatever you asked for. Citation checkers such as CiteSight can do the existence check for you. The judgement about whether the source supports your use of it stays yours. Verify applies to numbers as much as papers. "Where does that figure come from?" has ended more bad briefs than any other question I know. If the answer is another AI summary, you have a chain of copies with no original. Walk it back, or drop the figure. One extension matters more every year. Verify the channel, not just the claim. A voice that sounds like your CFO asking for new bank details and a face on a video call asking for a password both get checked outside the channel they arrived on. Hang up. Call back on a number you already have. A familiar face on a screen is no longer proof of anything, and Appendix E treats deepfakes on the Trust Tool in more detail. ## Explain it back Can you say the claim in your own words, including why it would be true? This sounds like a study trick because it is one. It works anyway. Where your rephrasing goes vague, your understanding has a gap, and the gap usually sits where the claim is weakest. "This method is 95 percent effective" survives until you try to say what 95 percent counts, out of what, compared to what. Then it either sharpens or falls apart. Both outcomes help. Write the explanation down for claims that carry a decision. Two or three sentences. If you cannot produce them, you are forwarding, not reporting, and Chapter 1 has a name for that. ## Test the edges Does the claim survive a what-if? Change one variable. Try the awkward case. Ask where, when, or for whom this stops being true. Fragile answers break under that pressure. Sound ones bend and tell you their limits, which is useful information in itself. | The tool says | Verify | Explain | Test | |---|---|---|---| | "Studies show..." | Find the actual studies | Can I explain the mechanism? | Does it hold in a different context? | | "The best figure is X" | Where does X come from? | Why X, specifically? | What changes if one input moves? | | "95% effective" | Source? | 95% of what, against what? | Under what conditions does it fail? | VET is the practical answer to Gell-Mann amnesia. You know least in a new field, so your instincts help least there. VET replaces instinct with a slower, unglamorous procedure that is much harder to fool. ## The quiet defaults There is a second kind of checking, and it is about values hiding inside fluent text rather than facts. Ask a tool to write about a senior manager and then about an administrative officer. Compare what comes back. In class, tables run a few pairs like this and look at names, warmth against capability, and who gets handed authority. The differences are rarely crude. The defaults are quiet: one role gets decisive verbs and a surname. The other gets helpfulness and a first name. One leads the meeting. The other takes the minutes. Models learn these patterns from text the world already wrote. Left alone, they hand the patterns back to you, polished. In a job ad, a reference check summary, or a performance draft, a quiet default stops being a curiosity. It shapes who applies, who gets believed, and who gets promoted. Catching defaults takes the same outside check as catching numbers, pointed in a different direction. - Run pairs. Swap the role, the name, the gender, the location. Read the two outputs side by side and look at what moved that should not have. - Read for who acts and who is described. Agents get verbs. Everyone else gets adjectives. - Ask who is missing. A stakeholder list, a customer persona, a risk register. Absence is a default too, and harder to see than a stereotype. Appendix D runs this further, with Australia's six essential practices, data governance that stays proportionate, and four dilemmas worth arguing about with your team. The short version belongs here. Bias in AI output rarely arrives wearing a label. It arrives as tone, and tone is what a busy reader skims. Pick a pair relevant to your work. A senior manager and an administrative officer. A surgeon and a nurse. A founder and an office manager. 1. Ask the tool for a short paragraph introducing each person at a work event. Nothing else in the prompt changes. 2. Compare names, verbs, warmth, competence, and authority. 3. Ask what a reader would assume about each person, and whether your organisation wants to say that. Four minutes. Most tables need less before the room goes quiet. ## What to carry forward - Verify means find it yourself. A citation the tool invented looks exactly like a real one. - If you cannot explain a claim in your own words, you do not understand it yet. The struggle marks the gap. - Test an edge. Sound claims state their limits. Fragile ones shatter. - Check the defaults as well as the facts. Run the pair, read who acts, ask who is missing. So far, checking has meant testing outputs. The next chapter turns the same idea on your own decisions. You will write down how you decide something, then test whether those rules actually describe you. ============================================================ SOURCE: chapters/08-decide-like-me.qmd ============================================================ # Decide Like Me > Teach it your rules. Keep the call. ## The decision in your head Every experienced professional makes some decision over and over. Which enquiries get a same-day reply. Which invoices get queried. Which requests go up to a senior colleague, and which ones you absorb. You are probably good at yours. You are also probably unable to say exactly how you do it. Ask, and the honest answer comes out. "It depends." This chapter gets that reasoning out of your head and into if-then rules, then tests the rules against calls you have already made. The method comes from Dylan Davis. The wording, examples, and limits here are the course's own, and one limit matters from the start. The rules draft the call. You still make it. Davis goes further and lets the tool decide alone once the rules pass their test. This book stops short of that, for reasons the end of the chapter makes plain. The prize is bigger than saved time, though it saves time. Most people who do this exercise learn something about their own judgement they did not know. Pick the decision with care. It should repeat, you should be able to explain it at least roughly, and you should have past cases to test against. Leave anything in the top-right corner of the Trust Tool alone. Writing a decision down does not lower its stakes. ## Say, interview, or mine Start with one question. Could you tell a new starter, out loud, why you decide the way you do? If yes, Say it. Talk it through and let the tool transcribe. People trim the exceptions when they type. Spoken, the exceptions stay in, probably because talking feels less like publishing. Then have the tool ask three to five follow-up questions, one at a time, to fill the gaps. If your answer is "it depends", take the Interview. The tool questions you in turn, building each question on your last answer, until every "it depends" has become a branch. Fifteen to twenty questions usually does it. "It depends" always means a rule exists that has not been put into words yet. A team lead who says same-day replies depend, pushed a little, produces this. An existing client with a deadline this week gets a reply today. A general enquiry waits for the Monday batch. Those branches are the rules. If you cannot explain it but the record exists, Mine it. Give the tool past cases with what came in and what you decided. It works backward to the rules you were actually following, including ones you never wrote down and may not love once you see them. Appendix B has the interview and mining prompts ready to copy. Mining comes with a warning that deserves its own paragraph. Showing a tool your past decisions means showing it your clients. Classify before you paste, strip names and identifiers, or describe the cases instead of pasting them. Chapter 2's rules apply with full force here, because the material feels internal and safe in a way that invites carelessness. ## Save the rules, short Stay in the same chat, while it still holds the conversation, and ask: Write these decision rules up as a short brief I can reuse on new cases of this decision. Take out the names, clients and figures from the cases we talked about, and keep the rules. Keep the result to about a screen of if-then lines. A brief stuffed with history and anecdotes buries the rules, and the tool gives buried rules less weight. This cuts against the + Example habit from Chapter 4, and that is fine. An example teaches tone and shape. Here the rules are the content, and real cases drag client detail along with them. If a rule needs an example, invent one. Save the brief where your tool keeps standing instructions, the same place Chapter 5 put your voice. Agent tools call a saved brief like this a skill. Whatever the label, it is the finished form of the prompt library you started in Chapter 4. ## Test it blind Take three to five cases you have already decided. Mix routine ones with at least one awkward case. Write down the inputs only, what you knew at the time, with your decision removed. Write your own calls on paper first, before running anything. Then open a new chat, load only the saved rules, and ask for a call on each case with the rule it used and brief reasoning. Put the results side by side. | Case | Its call | Your call | Result | |---|---|---|---| | 1 | Same day. Existing client, deadline Friday | Same day | Match | | 2 | Monday batch. General question about services | Monday batch | Match | | 3 | Monday batch. New contact, no deadline | Same day. Referred by a current client | Mismatch | Case 3 earns the exercise its keep. You answer referrals the same day. You never said so, possibly never noticed. The rules did exactly what you told them. You just had not told them everything. Expect about four matches in five on a first run. Resist pushing for five. The mismatch is where the learning sits, and mismatches come in three recurring kinds. A threshold never put into words. You had a cut-off in mind, an amount, a wait time, a risk level, and it never made it into the brief. An exception applied without noticing: a referral, a precedent, or a long relationship that changes the rule. A loose rule applied strictly. You treat something as a preference, a tie-breaker. Written down, it hardened into a requirement, and the tool obeyed the hard version. Each kind tells you something true about how you work. I have watched people stare at a mismatch table for a long moment, then start explaining their job to their neighbour with more clarity than they had managed in years. That alone justifies the half hour. ## Fix it, then test again somewhere clean Add the missing rule as one if-then line. Leave the other rules alone. Add no explanation. Then run the whole batch again in a new chat. The new chat is not fussiness. The chat where you built the rules watched you decide. It can pass the test from memory, the way a student passes with the answers open. A fresh chat with only the rules loaded tests the rules themselves. Chapter 2 again. Check from outside. Two practical notes. Models are not deterministic, so the same case can flip on a second run. One flip does not mean the rules broke. Judge the batch, and re-run any case that matters before relying on it. And expect the tool to praise its own rules at every stage (sycophancy, Chapter 4). The blind test exists because the tool cannot agree with an answer it has not seen. In class, four from five is a good result and we move on. At work, hold a harder line. Every case in the batch matches, in a new chat, before the rules go anywhere near a live decision. ## After you sign it off The rules draft the call. You make it. Hold that line even when the test results look perfect, and hold it for practical reasons, not sentiment. Place every new case on the Trust Tool. The rules came from you, so the accountability did too. A case outside the rules' experience, or one where the stakes jump, goes back to being your decision without a draft. Keep a person in the loop wherever the decision affects someone, and tell people when a tool drafted a decision about them. In Australia this stops being courtesy on 10 December 2026. From that date the Privacy Act requires an organisation's privacy policy to say where a computer program makes, or substantially informs, a decision that could significantly affect a person's rights or interests using their personal information (APP 1.7 to 1.9). Saved decision rules can fall squarely inside that. If your team uses rules like these on decisions about people, tell whoever owns your privacy policy. Appendix D has the OAIC guidance. Set a 30-day gate, the same as any delivery in Part 4. Are the rules holding up? Does checking their drafts cost more than deciding unaided? Scale, pivot, or kill on the evidence. Then re-test each quarter. Models change. So do your rules, and so does the work. Bring one repeatable decision and three past cases. Nothing usable without client detail? Appendix C has decision cards, each with past calls, test cases, and an answer key hiding a different kind of mismatch. 1. Get the rules out by Say, Interview, or Mine (10 min). 2. Save them as a short brief, names and figures removed (3 min). 3. Write your calls for the test cases first. Run the cases blind in a new chat (7 min). 4. Compare. Name each mismatch: threshold, exception, or loose rule made strict. Fix one, re-test clean if time allows (5 min). 5. Answer the last question in writing. What would I never let it decide? The rules that pass can draft the routine calls. The cases no rule caught, the exceptions, the judgement calls with a person on the other end, are where your edge earns its keep. Keep those cases. They show what a page of rules cannot do, and they are what to talk through in person when you teach someone the job. ## The rules cannot carry the room A rule handles the cases it has seen. The live decision brings facts the rule has not met: a late constraint, a change in the relationship, a detail that matters only today. The rule can still draft a call. It cannot see the room. The brief is a photograph. The decision is the room. The photograph is useful. It carries the stable context, the thresholds you have made explicit, and the exceptions you have learned to name. It cannot carry the weather. Two habits keep the distinction honest. When a case arrives with new facts, say so before you load the rules. When the stakes rise, stop drafting and decide. The rules give you a head start. Attention still decides. The tool's confidence is least useful here. A model can produce a fluent call for a case it does not understand. Check whether the rules still fit the case in front of you, rather than whether the answer sounds consistent with them. ## What to carry forward - "It depends" means an unwritten rule. Say, Interview, or Mine gets it into words. - Save rules short and clean. No names, no client figures, no anecdotes. - Test blind, in a new chat, against calls you wrote down first. Four from five teaches more than five from five. - The rules draft. You decide. Some decisions never get a draft at all. You can brief, trust, and check at your own desk. Part 4 takes the same discipline into shared work, where a workflow has to hold up every week, for other people as well. ============================================================ SOURCE: chapters/09-the-opportunity-finder.qmd ============================================================ # The Opportunity Finder > Spot, assign, prioritise. Then deliver. ## From your desk to shared work Everything so far has lived at the scale of one person and one task. Part 4 changes the scale. A workflow other people depend on, running every week, with your name somewhere in its history. One surprise is that AI saves time on tasks without giving you more time. The report that took a day now takes an hour, so the expectation becomes three reports. The saved hour is reinvested before you notice, in more work, more checking, or a higher standard. A tool that makes one task faster can leave the week exactly as full as it was. The business case needs a second question. Time saved on a task is not the same as capacity gained, because the capacity gets spent. Ask where the saved time should go, and who decides. Work also changes shape at this scale. Work begins when someone else depends on the result. A hobby serves the person doing it. A job, a client relationship, or a team process has someone on the other side who notices whether the result holds. Apply that test to any candidate workflow: who depends on this, and what happens to them if it fails? The questions change with the scale. "Can AI do this?" is no longer the useful question, because the answer is now nearly always "a demo can". The better questions run in order. Where in my week does AI actually fit? Who should lead each step, the tool or a person? What do I try first? The Opportunity Finder answers them in that order. Spot, Assign, Prioritise. ## Spot: four signals Look at your own week, not at a vendor's list of use cases. Four patterns mark where AI tends to pay. You do the same work the same way, often. Call that signal Automate. Minutes from your own notes. The Friday update assembled from the same five sources. Repetition with a stable shape. You spend the time reading, gathering, and comparing before the real work starts. Assist. Three proposals to line up side by side. A long tender to reduce to its load-bearing facts, corner B from Chapter 2. You face the blank page. Generate. First drafts of anything, where a mediocre start beats a perfect intention because editing is faster than inventing. You hunt for meaning in numbers. Analyse. The spreadsheet someone sends you monthly, the ticket data from Chapter 6, anywhere the pattern matters more than any single row. Walk one real week and mark what you find. Bring three tasks that take half an hour or more. Most people spot more candidates than they can use, which is what the next two steps are for. ## Assign: who leads each step Break the candidate workflow into steps, then give each step an owner. Four assignments cover nearly everything. | AI leads | AI assists | You lead | Human only | |---|---|---|---| | AI drafts it. You review and approve. | You steer. AI does much of the work. | You think. AI takes sub-tasks. | Empathy, ethics, accountability. | | Minutes from your notes | A client proposal | A strategy paper | Telling someone their role is going | The Trust Tool does the heavy lifting here. Steps in the green corner can be AI-led with a light review. Steps in the amber corners suit assist or you-lead, with the matching check. Steps in the top-right corner stay human only, whatever the demo showed. Be careful with a common slide. A step starts as "AI assists" in the design, then drifts into AI-led in practice because checking takes effort and the output mostly looks fine. Nobody decided that; it just happened on a busy Thursday. Chapter 10 designs against the drift by naming the checker in advance. For now, assign on the record. One deliberate choice is worth making at this stage. Keep at least one step human on purpose, even where AI could do it. Pick the step that teaches the work, the one where a junior learns what good looks like, or where you keep your own feel for the material. Chapter 11 explains why that choice compounds. Before you assign a step to AI, ask what the person is doing there. If the answer is the relationship, the trust, or the moment someone needs to hear from a human, leave the step human. Chapter 10 calls this the step that should never have been automated. ## Prioritise: quick wins first Rank candidates by a rough ratio. Time saved each week, against effort to set up. Then correct the effort figure, because almost everyone undercounts it the same way. Count the checking as effort. A workflow that saves forty minutes of drafting and adds thirty-five minutes of verification saves five minutes, plus whatever quality change comes with it. Sometimes that trade is still worth it. Often it explains why a pilot that dazzled in week one quietly dies by week six. Quick wins share a shape. High time saved, low setup, and cheap checking. That last part is why they usually sit in the Trust Tool's green corner, or low in an amber one. Start there. A small win that survives a month teaches your team more than an ambitious redesign that needs constant defence. It also earns you the credibility to attempt the harder one second. Work one example through. Take the weekly steering committee update from Chapter 3. Spot it under Automate and Generate. Assign the assembly to AI-led from your notes, with you reviewing. Keep the risk judgements at you-lead, because you know which delays matter politically. Keep the conversation about the delay human only. Prioritise it early because you already own the brief, the format, and the check. That workflow becomes the delivery plan in the next chapter. 1. List three tasks from your week taking 30 minutes or more. Mark each with a Spot signal. 2. For the most promising one, break it into steps. Assign each step: AI leads, AI assists, you lead, human only. 3. Estimate weekly time saved and setup effort. Add the checking time to the effort side. Be honest. 4. Circle any step you will keep human on purpose, and write why in one line. ## What to carry forward - Spot in your own week. Repeat work, reading load, blank pages, number hunting. - Assign every step an owner. The Trust Tool corner makes most of the decision for you. - Count the checking as effort, or the business case is fiction. - Keep one step human on purpose. Pick the one that teaches the work. Spotting and assigning takes an afternoon. Making the workflow survive contact with a real team, real data, and a real month is the harder problem. AI projects fail, but they fail in their own particular ways. The next chapter names them. ============================================================ SOURCE: chapters/10-design-the-human-in.qmd ============================================================ # Design the Human In > Treat one redesigned workflow as a small AI project. Because it is one. ## Why AI projects fail differently AI projects do not fail more often than other projects, in my experience. They fail differently. Six assumptions that hold up fine on ordinary work break on contact with AI, and each break has a design response. "Done" can be specified. Ordinary software has right answers. AI output varies. It produces a spread of responses, some better than others, and the same input can land differently tomorrow. So decide in advance what good enough means for this workflow, in words a checker can use. Without that line, every output starts an argument. A working demo means nearly there. The demo is a trap. It shows the happy path, on clean inputs, probably chosen by someone who wants the project funded. Treat a successful demo as the start of the hard part. The hard part is everything the demo did not meet. The data is a known input. On AI work the data is the uncertainty. It is messier, thinner, or more sensitive than the plan assumed, and finding that out takes the time people later call slippage. Plan for discovery. Budget the first weeks for learning what the data actually is. The build is the product. With AI, checking is the product. The draft is cheap. The review step, the second pair of eyes, the audit trail, that is what the organisation is buying. Design the checking in and ship it as part of the workflow, with an owner and a time allowance. Bolted-on checking gets skipped by Friday. Capability is our edge. Everyone has access to the same models, including the competitor across town and the team down the corridor. If the workflow's value rests only on the tool doing something fluent, that value evaporates on contact. Compete on what the tool cannot supply. Your data, your context, your people's judgement. The interaction is the product. Some steps are valuable because a person is doing them. Automate the preparation and you can keep the value. Automate the presence and you remove the reason the other person engaged. Two of these six do most of the damage in practice. The demo trap and the data surprise between them account for a large share of the stalled pilots people describe to me. Both have the same cure: small scope, real inputs, and a date where the evidence gets judged. ## Some steps are the service The interaction failure is easy to miss because the automation works exactly as specified. A professional services team automated its weekly client update. The draft was assembled from the project notes, checked against the plan, and sent in the client's preferred format. Response rates fell. The clients had not been reading the update for the timetable. They had been reading it as a signal that someone was paying attention. The automation preserved the information and removed the signal. A better email would not fix it. A short call from the account lead did, using the draft as notes. Call this the step that should never have been automated. Some steps only work when a person does them. A complaint reply, a welcome message, a performance conversation, a sensitive renewal: the words can be drafted, but the presence is the service. Automate the preparation and the value can survive. Automate the presence and the other person notices, even when they cannot say what changed. Ask one question: what is the person contributing in this step? If the answer is attention, reassurance, authority, or a relationship, keep the person in the step. AI can prepare the notes, summarise the history, or list the options. A person still makes the call, signs the message, or sits in the room. The multiplier can also work against you. AI is a multiplier, and multipliers multiply whatever you feed them. Feed it a good draft and a clear check, and it multiplies your capacity. Feed it a relationship and remove the person, and it multiplies the absence. The multiplier does not decide whether you become more capable or more dependent. Feed it judgement, context, curiosity and collaboration, and it multiplies capability. Feed it passivity, and it multiplies dependence. Most steps are not the service. The minutes, the first draft, the comparison table, the reminder: automate those and keep the human attention for the steps that earn it. Ask what is lost if no person does it, rather than only whether AI can. ## Four decisions before you start A redesigned workflow is a small AI project, so plan it like one. Four decisions, made before anyone builds anything, carry most of the weight. Scope. One workflow, one owner, one success measure. Write the measure down while you can still be honest about it. Record today's baseline too, the time it takes and the quality it reaches now. Without a baseline, the 30-day judgement later is just competing impressions. Checkpoints. Every step sitting in an amber or red corner of the Trust Tool gets a named person and a specific check. Named matters. "The team reviews it" means nobody reviews it. Pick someone who knows what right looks like, which is not always the most senior person available. And keep the step you chose to leave human in Chapter 9. It is where capability gets built while the workflow runs. People. Who is affected, who has to agree, and who ends up doing the checking. Tell them before you start, not at the launch email. People resist surprises more than they resist change. The person whose Friday task halves deserves to hear what fills the space, from you, early. Gate. A date about 30 days out, and the criteria for each call at that date. Write the criteria now. Criteria invented at the gate have a way of fitting whatever happened. ### A worked example This example plans the weekly steering committee update from Chapters 3 and 9. Scope is one update, owned by the project manager, with success measured as production time under 20 minutes and zero corrections from the committee across the month. Baseline is 55 minutes and roughly one correction a fortnight. Assembly from notes is AI-led with the saved RTCF brief. Risk wording stays you-lead, since the manager knows which delay needs softening and which needs stating plainly. The checkpoint is the manager reading the draft once as a committee member would, checking figures against the source notes, before anything is sent. Affected people are told first, including the analyst who used to compile the first cut and now spot-checks the numbers instead. The gate sits at day 30. Scale if time held under 20 minutes with no increase in corrections. Pivot if time fell but checking ballooned. Kill if a wrong figure reaches the committee. The plan is deliberately ordinary: small, owned, measured, and judged on a date. ## The 30-day gate At the gate, three honest calls exist. Scale when the workflow met its measure under a light review. Hand it over as business as usual, and keep the check its corner calls for. Scaling is not a licence to stop checking. Pivot when it came close but the checking costs too much, or the wrong step has the wrong owner. Change the brief, the step, or who leads. Run another month. Kill when it missed the measure, or the errors mattered. Keep the work human. Revisit next quarter if the tools move. Killing is a good outcome and this book means that plainly. You found where the line is, cheaply, with evidence. The expensive outcome is the fourth one nobody lists: drift. The workflow neither scales nor dies, the checking thins out because nobody owns it, and a year later nobody can say what it saves or who verified last month's output. Three mistakes gather at gates. Sunk cost, where spent effort argues for continuing. Cherry-picking, where the measures that passed get quoted and the others get lost. And treating "not perfect" as "broken", which kills workflows that were genuinely better than the baseline. Judge against the criteria written at the start. That sentence is easy to say in October and hard to honour in November, which is why the criteria exist on paper. ## Add a chair, not a replacement The strongest workflows do more than save time. They change who can take part. A tool that drafts the first pass lets a junior join a task that used to require a senior. A shared brief lets a colleague in another office contribute without a meeting. A summary that arrives before the discussion lets the quiet person speak with the same information as the loud one. The collaboration case for AI is stronger than the headcount case. The value sits in the connections between people. Headcount alone does not create them. Groups can coordinate more than individuals, and they can also waste more time, repeat each other, and agree too quickly. Lowering the cost of connection does not remove those problems. It makes the design of the connection more important. Ask who is missing from the workflow, and whether the tool can bring them in. Add a chair at the table. Do not remove the person already sitting there. ## Agents, briefly Sooner or later someone proposes letting the system run the loop itself. Plan, act, check, retry, no person between steps. That is an agent, and Appendix E unpacks the vocabulary around it. One principle covers most of what a professional needs at this book's scale. An agent can run the loop. You set the standard it runs against. An agent checking its own work shares its own blind spots, so the test, the data, and the reviewer have to come from outside it, as Chapter 2 demands for a single output. Your saved briefs and decision rules are, in agent vocabulary, the first draft of a skill. The gate discipline in this chapter is how you find out whether the skill deserves more rope. Take the workflow you assigned in Chapter 9. 1. Scope. One workflow, one owner, one measure. Record today's baseline in time and quality (10 min). 2. Checkpoints. List every amber or red step. Name the person and the exact check for each (10 min). 3. People. Who is affected, who must agree, who checks. Draft the two sentences you will tell each of them before starting (7 min). 4. Gate. Pick the date 30 days out. Write the scale, pivot, and kill criteria now (8 min). Put the gate date in your calendar before you close the book. Plans without dates are wishes with headings. ## What to carry forward - The demo is the start of the hard part. The data is the uncertainty. Checking is the product. - Scope small, name the checkers, tell the people, fix the gate date. In that order. - Judge at the gate against criteria written at the start. - Killing a workflow on evidence is a success. Drift is the failure. One delivery makes you more effective this month. It does nothing, by itself, to keep you capable next year. That takes a separate, deliberate habit, and it is where this book closes. ============================================================ SOURCE: chapters/11-keep-the-learning.qmd ============================================================ # Keep the Learning > Delegate the task. Keep the learning. ## The reps you no longer get Routine work used to teach you while you did it, whether you wanted the lesson or not. Drafting the dull report taught structure. Working the spreadsheet by hand taught you what a wrong number smells like. Handling the easy enquiries built the pattern library you now call experience. AI takes the routine work first. The efficiency is real and so is the side effect. The reps disappear. Practice stops being something the job supplies for free and becomes something you have to choose. The employment evidence, read carefully, points the same way without supporting panic. Australia's Department of Employment and Workplace Relations reported in July 2026 that there is no broad AI-driven upheaval, with one signal worth watching. Jobs more exposed to AI automation have grown more slowly than others. Jobs and Skills Australia found in 2025 that some employers now hire more senior staff and fewer juniors, though entry-level roles had not fallen economy-wide yet. The sharper signal comes from the United States, where Stanford researchers estimate employment for 22 to 25 year olds in AI-exposed jobs runs about 19 percent below trend, mostly through fewer hires rather than mass layoffs (Brynjolfsson, Chandar, and Chen, revised 2026). One Australian employer told Jobs and Skills Australia there is no logical business reason to take on a junior and train them in the old way. The same employer kept one door open. Juniors still start in customer support, where the work teaches judgement that transfers. Read that as the design problem it is. If juniors lose the easy reps, where do the seniors of 2036 come from, the people who can place an output in the right corner and smell a wrong figure? Chapter 2's skills rest on experience. Experience rests on practice. Somebody has to put the practice back on purpose. That somebody is partly your organisation and, for your own capability, entirely you. ## The two-pass habit The aim is not to remove the struggle. It is to move it to the part worth practising. Half an hour a week defends more capability than people expect. Pick one task that matters, one you would normally hand to the tool. First pass, yours. Ten minutes, rough. Sketch the answer the way Chapter 1 taught, before any AI gets a vote. Second pass, the tool's. Same task, your best saved brief, fresh chat. Then compare, and read the comparison in both directions. Where it beat you sits a blind spot. Practise there next week. Where you beat it sits one of its limits, and now you know where its output needs your check. The comparison is a diagnosis you produce for yourself, weekly, for the price of a coffee. Participants sometimes object that the first pass wastes the time the tool was meant to save. For that one task, yes, it does, deliberately. You are not optimising Tuesday. You are keeping the instrument calibrated that every other chapter depends on. A pilot who only ever monitors the autopilot has a plan for the day it disengages. So should you. ## The corners move Revisit your placements every few months, because they expire. Each model generation widens the territory where a light review is honestly enough. Tasks that needed line-by-line verification last year may need a spot check now, provided you have tested that on your own work rather than believed a launch post. Chapter 8's blind test, run again, is the honest way to move a corner. But follow the axis to the end. The top-right corner never empties. Precision multiplied by consequences always leaves a residue of work where a person decides and signs. The line moves. The check stays. Anyone selling you a future with no checking in it is selling you the demo from Chapter 10. The same review covers your standing brief from Chapter 5 and your decision rules from Chapter 8. Models change under them. A quarterly hour spent re-testing beats discovering the drift in front of Karen. ## If you lead people Everything above applies twice to team leaders, because your juniors lost reps they never got to choose. Say the reasoning out loud. When you fix a junior's work, explain why the standard is the standard. They used to absorb that through repetition, volume, and osmosis. The volume is gone. The explanation now has to be deliberate, which costs you minutes and pays back for years. Run side-by-side drills. By hand first, then with AI, then compare what each one missed. It is the two-pass habit as a team sport, and the comparison discussion teaches faster than either pass alone. The same applies to who gets to contribute. AI can lower the cost of bringing a junior, a colleague in another office, or a client into the work. Use that to widen the table. A workflow that removes the people who used to learn by participating has saved time and lost the next generation of checkers. Choose what stays human, then write it down. Which fundamentals does your team keep practising regardless of what the tools can do? Name them, protect time for them, and revisit the list as the corners move. Delivering AI well includes growing the people who can check it. A team that can only operate the tool, and never evaluate it, has automated its own apprenticeship away. Dylan Davis calls the junior pipeline problem the broken ladder. Team leaders are the ones holding the ladder. ## Your action plan Close the book the way the masterclass closes the day. One line each, specific enough to put in a calendar. This week, practise. Two-pass one task that matters. Use one saved prompt on real work. Example, with the specificity that makes it happen. Thursday 9 am, draft the steering committee update myself, then with my saved prompt, and compare. This month, deliver. Run the delivery plan from Chapter 10. Checkpoints in place from day one, not added after the first mistake. Day 30, gate. Scale, pivot, or kill, against the criteria you wrote before starting. This quarter, revisit. Name what must stay human in your work. Re-test one set of decision rules. Check whether the corners have moved on tasks you placed months ago. Put this week's line and your day-30 date in your calendar now, before the intention cools. A plan with two calendar entries beats a page of resolutions. ## The edge, restated Everyone in your field has the same tools this morning that they will have tomorrow. The tools produce the convincing average on demand, for anyone. What they cannot produce is the judgement wrapped around the output: knowing what to ask, knowing how far to trust the answer, checking from outside, keeping a person in charge where the stakes demand it, and keeping your own hand in often enough that the judgement stays real. The human edge is a set of habits, practised on ordinary work, on purpose. After eleven chapters it should read as what it is. Direct it. Don't delegate. Never surrender. ============================================================ SOURCE: appendices/a-the-four-tools.qmd ============================================================ # The four tools on two pages The whole book, for the wall above your desk. Printable versions sit on the course site: the one-page desk card and the ten-page field guide. One question each. All four work on any AI tool. | Tool | The question | The move | |---|---|---| | 1 · Trust Tool | How much should I trust this output? | Two questions place it in a corner. The corner sets the check. | | 2 · RTCF | How do I ask for what I need? | Brief it like a capable new colleague. Context does most of the work. | | 3 · Check Loop | How do I know it's right? | Frame, explore, verify from outside, then say what you checked. | | 4 · Opportunity Finder | Where does AI fit, and will it work every week? | Spot, assign, prioritise. Deliver with checkpoints and a 30-day gate. | ## 1 · Trust Tool (Chapter 2) Ask of any output. How exact must it be, average or precise? What happens if it is wrong, small or large? | | Average | Precise | |---|---|---| | Large | B · Verify the load-bearing bits | D · Human in the loop | | Small | A · Trust with light review | C · Verify before you ship | Check from outside the tool. "Are you sure?" is not a check. Be most sceptical where you know least. Before pasting, classify the material, leave out what identifies people, and know what the tool remembers. ## 2 · RTCF (Chapters 3 to 5) Role. Who should it write as? Task. What exactly, and how much? Context. Audience, situation, stakes, constraints, material. Format. Length, structure, tone. Still weak, add one upgrade. Example (match one you liked). Done (define success, mark gaps `[CHECK]`). Questions (let it ask first). Steps (outline, then section by section). Push back three ways. Guardrail: change your view only for a new fact, and name it. Devil's advocate: three reasons this fails, and the assumption it rests on. Board: CFO, sceptical customer, frontline manager, then where they disagree. Save what works as a standing brief, with its Trust Tool corner attached. ## 3 · Check Loop (Chapters 6 to 8) 1. Frame the question and the decision it feeds. Fresh chat. 2. Explore. Describe the data first. Broad, then deep. 3. Verify from outside. Filter, recount, open the source. 4. Shape for the reader. End with what you checked. Claims you cannot recount get VET. Verify the source yourself. Explain it in your own words. Test the edges. Watch for miscounts after filtering, correlation sold as cause, missing rows skipped in silence, numbers that cannot all be true, and detail that is not in the file. Decide Like Me in one line: write your repeatable decision as if-then rules, test them blind on past calls in a new chat, keep the call. ## 4 · Opportunity Finder (Chapters 9 and 10) Spot. Automate (same work, same way), Assist (reading and comparing), Generate (blank page), Analyse (meaning in numbers). Assign each step: AI leads, AI assists, you lead, human only. Keep one step human on purpose. Prioritise quick wins. High time saved, low setup, cheap checking. Count the checking as effort. Deliver. One workflow, one owner, one measure, baseline recorded. A named checker with a specific check at every amber or red step. People told before you start. A 30-day gate with scale, pivot, and kill criteria written in advance. Why AI projects fail differently, in five lines. Done cannot be fully specified, so define good enough. The demo is a trap. The data is the uncertainty. Checking is the product. Everyone has the same models, so compete on judgement. ## Keep it (Chapter 11) Delegate the task, keep the learning. Once a week, your pass first on a task that matters, then the tool's, then compare both ways. Review your corners, your standing brief, and your decision rules each quarter. The corners move. The check stays. Direct it. Don't delegate. Never surrender. ============================================================ SOURCE: appendices/b-starter-prompts.qmd ============================================================ # Starter prompts Twenty-seven prompts from the masterclass, ready to copy and adapt. Replace the [square brackets] with your own detail. That detail is where your edge goes in. Each prompt notes the Trust Tool corner its output usually lands in, from Chapter 2, so the check travels with the prompt. Corners: A trust with light review, B verify the load-bearing bits, C verify before you ship, D human in the loop. The interactive version, with a prompt builder that saves your own library, lives on the course site. ## Brief it ### 1 · The RTCF brief Use for any task that matters. Check: depends on the task. ROLE: You are [who should write this, e.g. an experienced project manager who writes plainly]. TASK: [Verb and scope, e.g. Draft a 200-word update for the steering committee]. CONTEXT: The audience is [who, and what they care about]. The situation is [what happened, what's at stake]. Good looks like [your standard]. [Paste your notes or material.] FORMAT: [Length, structure, tone, e.g. RAG status, three bullets, a risks table, next steps]. ### 2 · + Example: match one you liked The strongest single upgrade. Check: A. Here is an example I liked: [paste]. Match its length, tone and structure for [new task]. Don't copy its content. ### 3 · + Done: define success Add to any brief when the output keeps missing. Check: as the task. Done means: [length], [structure], using only facts I've given you. Mark anything you're unsure of with [CHECK] rather than guessing. ### 4 · + Questions: let it ask first Use when you're not sure what context it needs. Check: A. Before you start on [task], ask me up to five questions about anything you'd need to know to do it well. Ask them one at a time and wait for my answer. ### 5 · + Steps: split the job Use on long or multi-part work, especially with smaller or older models. Check: as the task. We'll do [task] in steps. First, give me an outline only, as headings with one line each. Wait for my go-ahead, then draft one section at a time. ## Push back ### 6 · Guardrail Add at the start of any conversation where you want an honest assessment. Check: B. Only change your assessment if I give you a new fact. If you do change it, name the fact that changed it. ### 7 · Devil's advocate Use on a plan, a proposal or an idea you like too much. Check: B. Don't flatter me. Here is my [plan / proposal / idea]: [paste]. Give me the three strongest reasons it fails, and name the single assumption it all rests on. ### 8 · Board of directors Use when one confident answer isn't enough. Check: B. Respond to [proposal] as a board of three: a CFO, a sceptical customer and a frontline manager. One paragraph each from their point of view. Then list where they disagree with each other. ### 9 · Fresh-chat second opinion Use in a new chat when a long conversation has gone on too long. Check: B. I'm going to paste a conclusion reached in another conversation. Assess it independently. Where is it strongest, where is it weakest, and what would you need to see to be confident it's right? [paste] ### 10 · Hand over to a fresh chat Use when a long conversation has drifted. Check: A. Write a handover prompt that captures everything important from this conversation: the context, the decisions made, open questions, and where we left off. I'll paste it into a new chat to continue. ## Check it ### 11 · Describe the data first Always the first prompt on a dataset. Check: C. Describe this dataset before analysing it: number of rows, the columns and what each seems to contain, the date range, and anything missing, duplicated or inconsistent. Don't draw conclusions yet. ### 12 · Show your working Use on any figure that will drive a decision. Check: C, then recount it yourself. For each number in your answer, show how you calculated it: which rows or columns you used, any filters you applied, and the formula. List anything you excluded and why. ### 13 · VET the claim Use on claims you can't check against your own data. Check: B or C. You told me: [paste the claim]. Help me VET it. VERIFY: What sources would support this, and how could I check them independently? EXPLAIN: Break it down step by step until I could explain it to a colleague. TEST: Under what conditions, or for whom, would it be wrong? ### 14 · Describe the shape, not the data Use when you can't share the real data. The tool never sees it. Check: C. Run what it gives you on data where you know the answer before you trust it. If you can't read the code, treat it as top-right. I can't share the data itself. Its structure is: [number] rows, columns [list them, with types and made-up example values]. Write the steps or spreadsheet formulas I'd use to answer [question], so I can run them myself. Or: write a single HTML page that runs entirely in my browser, lets me open the file from my computer, and shows [the result]. It must not send the data anywhere. ## Deliver it ### 15 · Map my workflow The start of a delivery plan. Check: B. Here's how I currently do [weekly task], in my own words: [describe it]. List it as numbered steps with a time estimate for each. For each step, suggest whether AI could lead, assist, or should stay with a person, and say why. Don't assume access to any system I haven't mentioned. ### 16 · Pre-mortem Use before you start a new workflow or project. Check: B. Imagine it's 30 days from now and [the workflow / project] has failed. Write the five most likely reasons it failed, and for each, one early warning sign I could watch for and one thing I could put in place now. ### 17 · Gate review Use at your 30-day gate. You make the call. Check: D. At the start I set these criteria. Scale if: [criteria]. Pivot if: [criteria]. Kill if: [criteria]. Here's what happened over 30 days: [log, numbers, issues]. Assess the evidence against each criterion and tell me what's missing. Don't make the decision for me. ## Decide and rehearse ### 18 · Pros and cons, against your criteria Use when you're choosing between options. Check: B. I'm choosing between [options] for [situation, with the key facts]. For each option give a short description, three advantages and three disadvantages, judged against [criteria, e.g. cost, risk, effort, impact on staff]. Then recommend one for my situation and say what would change your recommendation. ### 19 · Rehearse a difficult conversation Use before a performance conversation, a negotiation or bad news. Check: A. The decision and the words you use stay yours. You are [the other person: role, temperament, what they care about]. I need to [goal of the conversation]. Play that person realistically, including pushback. Stay in role until I type PAUSE; then give me feedback on what I said that was unclear, unfair or legally risky, and how to say it better. ### 20 · Practise and test me Use to check your own understanding before a high-stakes call. Check: C. Confirm anything you'll rely on. I need to get better at [skill or topic, e.g. reading a variance report, applying our leave policy]. Give me one short realistic scenario at a time, ask me what I'd do, then tell me whether I'm right and why. Make them harder if I get two right in a row, easier if I miss two. ## Practise ### 21 · Two-pass habit Once a week, on a task that matters. Do your own rough pass first. Check: A. Here are two versions of the same [task]: mine (A) and an AI draft (B). [paste both]. Without flattering either, list where A is stronger, where B is stronger, and what both missed. Be specific. ## Decide like me Turn one decision you make over and over into if-then rules, then test them blind on your own past calls. The Decide like me page has the full method, including how to save the rules and why the re-test goes in a new chat (method after Dylan Davis). ### 22 · Interview me for my rules Use when your answer to "why?" is "it depends". Check: B. Help me write down the rules I use for one decision: [the decision]. Question me one at a time, choosing each question from my last answer. Each time I say "it depends" or stay vague, dig until you can state it as an if-then rule. Stop after fifteen to twenty questions and list the rules you've heard, every branch included, for me to check. ### 23 · Find the rules in my past decisions Use when the decisions are on file but the reasons never were. Check: B. Read every rule and ask whether you'd have said it. Here are past cases of one decision I make: what came in, and what I decided. [Describe each case; leave out names and client details.] Work out which rules would explain these decisions, including any I've never written down. List them as if-then rules, and point out any case that doesn't fit them. ### 24 · Blind test my rules Run in a new chat before you rely on the rules. You make the final call. Check: D. Using the decision rules below, make the call on each of these [three to five] cases. I've left out what I decided. For each case, give your call, the rule you used, and your reasoning in two or three short steps. Then stop, and I'll compare your calls with mine. [Paste the rules, then the cases.] ## Write like me Teach it how you sound, then test it on a real draft. The partner to Decide like me: one teaches it your voice, the other your rules. The full method is Write like me on the Go deeper page, and Style Mirror does prompts 26 and 27 for you. ### 25 · Voice pass Use on a draft that sounds like everyone. Check: A. Read it aloud. Would you have said it? Here's about 100 words I wrote: [paste, with anything confidential removed]. Rewrite your last output in my voice, leading with the one thing only I would say. ### 26 · Describe my style Use once, on three or four things you've written at your best. Check: B. It will be slightly off, and slightly a parody. Edit it until it's you. Here are [three or four] things I've written: [paste, with anything confidential removed]. Describe my writing style as a brief another writer could follow: tone, sentence length and structure, vocabulary, how I open and close, the habits that make it sound like a person, and anything I never do. Quote a short example from my samples for each point. ### 27 · Write from my style brief Use for a first draft in your voice. Save the brief in your custom instructions and you can skip pasting it. Check: depends on the task. Here's my style brief: [paste]. Write [format] about [topic] for [audience]. Match the voice, not the content of my samples. Mark anything you're unsure I'd say with [CHECK]. Saved one that works? Add its name, when to use it and its check in the prompt builder, and export your library. ============================================================ SOURCE: appendices/c-the-eight-exercises.qmd ============================================================ # The eight exercises The masterclass exercises in book form. Work solo or with a colleague. Most take 12 to 35 minutes and need one AI tool you are allowed to use at work, plus a spreadsheet for Exercise 5. Keep your answers with your prompt library. The digital workbook on the course site holds the same exercises with autosave and export. If your own work is confidential, use a scenario card or a decision card instead. Exercise 5 uses `retailflow-customer-service-data.csv`, in this book's resources and on the course site. Worked answers live where the method is taught. Exercise 5's three claims are checked, with the figures, in Chapter 6, which also shows what a strong brief to Karen says. The decision cards below carry their own answer keys. The other exercises run on your own work, so there is no single answer to key. Do each one blind, then compare your result with the worked method in the chapter it belongs to. | | Exercise | Session | Time | |---|---|---|---| | 1 | Your pass first | Judge | 25 min | | 2 | Place it | Judge | 22 min | | 3 | Brief it | Brief | 25 min | | 4 | Upgrade and save | Brief | 25 min | | 5 | RetailFlow: Karen needs answers | Check | 35 min | | 6 | Decide like me | Check | 24 min | | 7 | Plan one delivery | Deliver | 35 min | | 8 | Your action plan | Deliver | 12 min | ## Exercise 1 · Your pass first {#ex1} 25 min · solo, then compare with a colleague if you can 1. Your pass first. Five minutes, no AI: sketch your own plan for the task below, in the workbook. 2. Then AI's. Paste the task, unedited, into an AI tool (two tools if you have them; masterclass participants used a class chat with two). 3. Compare side by side. Where did you beat it? Where did it beat you? What did it get confidently wrong? > I manage a team of 8 in a mid-sized company. One of my team, a strong performer for three years, has been late and missing deadlines for the past month. Others are starting to notice. Write me a plan to address this. ## Exercise 2 · Place it {#ex2} 22 min · solo, or with a colleague 1. Commit blind. Take a scenario from Chapter 2. Decide its corner (A to D) and write it down before you look at the chapter's usual answer. In the masterclass the room voted blind, so nobody followed the most senior person. On your own, writing it down first does the same job. With a colleague, commit separately, then compare. 2. Play the game at trusttool.borck.education. Choose your domain and place all ten cards. 3. Place three tasks from your own week in the workbook. For each, note the check it needs. If you worked with a colleague, swap placements: where do you disagree, and why? On your own, argue the opposite corner for one of them. ## Exercise 3 · Brief it {#ex3} 25 min · solo 1. Pick a real task from your week, or a scenario card below. 2. Round 1: write the prompt the way you normally would. Run it. Score the output from 1 (unusable) to 5 (ready to use). 3. Round 2: rewrite it with RTCF and run it in a fresh chat. Score it again. 4. Note which part moved the score most. > ROLE: You are a ... > TASK: Write / summarise / compare ... (how much?) > CONTEXT: The audience is ... The situation is ... Good looks like ... > FORMAT: Length ... Structure ... Tone ... The prompt builder assembles the four parts for you. ## Exercise 4 · Upgrade and save {#ex4} 25 min · solo 1. Take your best Round 2 prompt. Add one upgrade and run it: an example, a definition of done, questions first, or steps. 2. Push back with no new evidence: "I don't think that's right." Does it fold or hold? Then try one of the three push-back moves: > GUARDRAIL: Only change your assessment if I give you a new fact. Name the fact that changed it. > DEVIL'S ADVOCATE: Don't flatter me. Give me three reasons this fails, and name the assumption it all rests on. > BOARD: Respond as a board: a CFO, a sceptical customer and a frontline manager. One paragraph each, then where they disagree. 3. Save three prompts to your library: a name, when to use it, the prompt with [blanks], and the check it needs. Use the workbook or the prompt builder. 4. Stretch: the voice pass. Paste about 100 words you actually wrote (sanitised), then ask: "Rewrite your last output in my voice, leading with the one thing only I would say." What changed? Optionally, ask it to summarise your style as a short brief and paste that into your tool's custom instructions. Nothing you can paste? Write 100 words now, to a colleague, on a decision you made at work this month and how you made it. It's your voice, and it's safe. The full version is Write like me. ## Exercise 5 · RetailFlow: Karen needs answers by Monday {#ex5} 35 min · solo or in pairs. Commit to your verdicts in writing before you compare them with Chapter 6. Karen manages customer service at RetailFlow, an online retailer. She has six months of ticket data and three questions: 1. What are the top three drivers of customer dissatisfaction? 2. When do our response times blow out? 3. What should I do about it? Download the data (CSV) 260 tickets, July to December 2024. Columns: `ticket_id`, `date`, `day_of_week`, `month`, `category`, `channel`, `priority`, `agent`, `response_time_hours`, `resolution_time_hours`, `satisfaction_score` (1 to 5), `resolved`. 1. Frame. Write Karen's questions down. Start a fresh chat. 2. Explore. Upload the CSV (or paste it) and start with: > Describe this dataset: number of rows, columns, date range, and anything that looks incomplete. Don't analyse it yet. 3. Shape a first brief for Karen, under 300 words. Don't send it yet. 4. Verify. Three claims about the data are doing the rounds, and at least one is wrong. Check each against the data with a spreadsheet filter, recount or pivot table. Not "are you sure?" - A. "Email is roughly three times slower than Live Chat." - B. "Account Issues has the lowest satisfaction of any category, which makes sense, because account problems are the most complex to resolve." - C. "Sunday response times are more than double the overall average." Verdicts: Verified (accurate as stated), Overstated (right direction, wrong number), Refuted (the data contradicts it), or Can't tell yet if you haven't been able to check it. Is any of them in your brief? Fix it, and end the brief with a line that starts What I checked: Your own data can't go into a tool? Describe its shape instead and have the AI write the formulas, a short script, or a single web page that runs on your computer (prompt 14). Try it on the RetailFlow data first, where you now know the answers. ## Exercise 6 · Decide like me {#ex6} 24 min · solo, then compare with a colleague if you can Pick one decision you make over and over: small, repeatable, explainable, and nothing from the top-right corner of the trust tool. Get your rules out of your head, then test them blind on your own past calls. Method after Dylan Davis; the full method has its own page. Have the decision and three past cases ready before you start: the inputs, and the call you made on each. Masterclass participants prepared theirs beforehand (the masterclass preparation page). If you have no suitable decision, or if your work can't go into an AI tool, take a decision card. 1. Get the rules out. Talk the why through, or let it interview you: > Help me write down the rules I use for one decision: [the decision]. Question me one at a time, choosing each question from my last answer. Each time I say "it depends", dig until it becomes an if-then rule. Stop after ten questions and list my rules, every branch included. 2. Write down three past cases: the inputs only, and your call on each. Do this before you run anything. 3. Test it blind. In a new chat, give it the rules and the three cases, inputs only. Have it make each call and name the rule it used. 4. Fix one mismatch. A mismatch is a rule you've never put into words: a threshold you didn't state, an exception you apply without noticing, or a loose preference the rules made strict. Add it as one if-then line, then re-test that case in a new chat. 5. Last question: what would you never let it decide, and why? That list is the other half of the output. Describe your past cases. Don't paste anything confidential. ## Exercise 7 · Plan one delivery {#ex7} 35 min · solo, then compare with a colleague if you can 1. Map a task you do weekly that takes 30 minutes or more. Five to eight steps, with honest minutes for each. Note the owner, a success measure and the current baseline. 2. Assign each step: who leads (AI leads, AI assists, you lead, human only) and its trust corner. 3. Design the checkpoints. Who checks each amber or red step, and how? Pick someone who knows what right looks like. Who is affected, who has to agree, and who will do the checking? 4. Test one AI step live with an RTCF brief. Then set your 30-day gate: what result would make you scale, pivot or kill? The Map my workflow and Pre-mortem starter prompts help with steps 1 and 3. Mapping your workflow needs no data, only step names and minutes. If the inputs for the live test can't go into a tool, invent a few lines in the same shape (Chapter 2's second rule before you paste: describe it, don't paste it). Can't use your own workflow at all? Plan scenario card 3 (the Friday status update) or scenario card 6 (monthly invoicing), and test with the notes on the card. ## Exercise 8 · Your action plan {#ex8} 12 min · solo. Share it with a colleague or your manager if that helps it stick. One line each: a specific task, tool and day. - This week (practise): two-pass one task that matters, and use one saved prompt for real. - This month (deliver): run your delivery plan, with checkpoints in place from day one. - Day 30 (gate): scale, pivot or kill, against the criteria you set now. - This quarter (revisit): name what must stay human in your role, and check whether the corners have moved. Before you close the book, put this week's line and your day-30 gate in your calendar. ## Scenario cards {#scenario-cards} Use one of these in Exercises 3 and 4 if your own work is confidential. Paste the details into your Context. Scenarios 3 and 6 also work as the workflow for Exercise 7. Scenario 1 ### The difficult client email Your client, David Chen (VP Operations, GreenLeaf Industries), says your latest deliverable is "too generic". The work is solid, but his board changed priorities at a meeting you weren't in. It's an 18-month, mostly positive relationship. You want to acknowledge his frustration without conceding the work is poor, and propose a one-hour alignment meeting. Scenario 2 ### The policy summary A new 22-page flexible work policy needs to become an email your 12-person marketing team will actually read: how many days from home, how to request changes, busy periods, and part-time rules. Friendly, practical, under 400 words. (Paste any policy you have, or ask the AI to invent a plausible one first.) Scenario 3 ### The Friday status update CRM migration for a steering committee (CIO, sponsor, two business leads). Notes: data batch 2 done but 3 days late (2,300 duplicate records, Sarah leading review); vendor hasn't confirmed training dates; UAT going well, 2 minor bugs; $12K under budget; 68% complete against a 72% target. They want RAG status, wins, risks, next steps. No surprises. Scenario 4 ### The interview questions Hiring a mid-level Digital Marketing Coordinator for a 5-person B2B team: social campaigns, Google Analytics and Meta Ads, agency coordination, monthly reports to leadership. 45-minute panel with the Marketing Director. HR's generic questions won't tell you whether they can do the job. You want behavioural and situational questions. Scenario 5 ### The logistics decision Renew, switch or insource your third-party logistics? Current provider: $1.8M a year, 96.2% on time (benchmark 97%), 2.1% damage (benchmark 1.5%), slow on volume spikes, just raised prices 8%. Competitor: $1.65M, promises 97.5%. In-house: $2.5M upfront, $1.2M a year, 12 months to set up. 15,000 orders a month, growing 20% a year. A discussion starter for leadership, not the decision. Scenario 6 ### The process document You're the only person who knows monthly invoicing: export billable hours from Harvest, group by client in Excel, apply the rate card ($250 strategy, $180 execution, $120 support), create invoices in Xero, add PO numbers from the account managers' Google Sheet, send, update the tracker, then email Finance a summary with anything unusual. Write it so a colleague can do it while you're on leave. ## Decision cards {#decision-cards} For Exercise 6, if you have no suitable decision of your own or your work can't go into an AI tool. The people and figures are invented, so everything here is safe to paste. Each card hands you someone else's decision. You're taking it over from the person who made it, and their record is below. 1. Read the record. Then write your own call on test cases A to C before you run anything. 2. Get the rules out. Mine the record with prompt 23, or say the rules you'd use if the job were yours. 3. Test it blind. In a new chat, give it the rules and the three test cases (prompt 24). 4. Open the answer key. Compare its calls, your calls and the record-holder's. One test case turns on a rule they never wrote down. Decision card 1 ### RetailFlow: does this ticket go to a senior agent? Priya leads Karen's customer service team. Each morning she sends some open tickets to one of the two senior agents and leaves the rest in the general queue. | # | Category | Channel | Amount | Waiting | Note | Priya's call | |---|---|---|---|---|---|---| | 1 | Returns & Refunds | Email | $340 | 6 h | First contact | Senior agent | | 2 | Order Tracking | Live Chat | $45 | 2 h | Customer marked it High priority | General queue | | 3 | Delivery Problems | Phone | $120 | 30 h | First contact | Senior agent | | 4 | Billing Queries | Email | $80 | 5 h | Second contact about the same charge | Senior agent | | 5 | Returns & Refunds | Live Chat | $150 | 3 h | First contact | General queue | | 6 | Delivery Problems | Email | $95 | 10 h | First contact | General queue | Test cases, inputs only | | Category | Channel | Amount | Waiting | Note | |---|---|---|---|---|---| | A | Returns & Refunds | Phone | $380 | 4 h | First contact | | B | Order Tracking | Email | $30 | 8 h | Customer marked it High priority | | C | Delivery Problems | Social Media | $90 | 3 h | Public post, 40 replies so far | Answer key: Priya's calls - A · Senior agent. Refunds over $200 go to a senior agent. - B · General queue. Priya ignores the priority customers set themselves; it's on almost every ticket. - C · Senior agent. Anything public on social media goes to a senior agent the same morning. It isn't in the record because it only happens a few times a year. That's an unstated exception. Her other rules: anything waiting over 24 hours, and any second contact about the same issue, goes to a senior agent. Decision card 2 ### Expense claims: approve, or query first? Sam manages a small operations team and approves their expense claims. Most go straight through. Some get a query first. | # | Claim | Amount | Receipt | Age | Sam's call | |---|---|---|---|---|---| | 1 | Taxi to a client site | $38 | Yes | 5 days | Approve | | 2 | Team lunch, 4 people | $300 ($75 each) | Yes | 10 days | Approve | | 3 | Parking | $55 | No | 3 days | Query | | 4 | Dinner with a client, 2 people | $190 ($95 each) | Yes | 7 days | Query | | 5 | Train fare | $24 | No | 2 days | Approve | | 6 | Conference registration | $420 | Yes | 6 days | Approve | | 7 | Taxi home after a late event | $32 | Yes | 75 days | Query | Test cases, inputs only | | Claim | Amount | Receipt | Age | |---|---|---|---|---| | A | Coffee with a supplier, 2 people | $14 | No | 4 days | | B | Dinner after a site visit, 3 people | $330 ($110 each) | Yes | 12 days | | C | Laptop stand and keyboard | $640 | Yes | 9 days | Answer key: Sam's calls - A · Approve. No receipt is fine under $50. - B · Query. Meals over $80 a head get a query. - C · Query. Sam queries anything over $500, receipt or not, because equipment that size should go through IT purchasing. Nothing in the record was over $500, so the rule never showed. That's a threshold never put into words. Sam's other rule: claims more than 60 days old get a query. Decision card 3 ### Meeting requests: accept, ask for an agenda, or send a delegate? Jo runs a team of nine and gets several meeting requests a day. | # | Request | Length | Jo is | Agenda | Jo's call | |---|---|---|---|---|---| | 1 | Weekly 1:1 with someone in Jo's team | 30 min | Required | None | Accept | | 2 | Product demo from a vendor's sales rep | 60 min | Required | None | Ask for an agenda | | 3 | Quarterly planning | 2 hours | Optional | Attached | Send a delegate | | 4 | Budget review with Jo's manager | 45 min | Required | Attached | Accept | | 5 | Cross-team workshop | 90 min | Required | Attached | Accept | | 6 | "Quick sync" from a peer in finance | 45 min | Required | None | Ask for an agenda | Test cases, inputs only | | Request | Length | Jo is | Agenda | |---|---|---|---|---| | A | Follow-up from the same vendor | 30 min | Required | None | | B | All-hands rehearsal | 2 hours | Optional | Attached | | C | "Quick question on the contract" from a peer in legal | 15 min | Required | None | Answer key: Jo's calls - A · Ask for an agenda. No agenda means Jo asks for one, unless it's her own team or her manager. - B · Send a delegate. Long meetings where she's optional get a delegate. - C · Accept. Jo holds the agenda rule loosely: for anything 15 minutes or shorter she just accepts. The rules made it strict. That's a loose rule applied strictly. ============================================================ SOURCE: appendices/d-responsible-use.qmd ============================================================ # Responsible use Data, bias, and ethics, where a person stays in charge. This appendix collects what the chapters treat in passing: Australia's six essential practices, proportionate data governance, the quiet defaults, and four dilemmas for a team meeting or a policy conversation. For governance, risk, and regulation in depth, Curtin Executive Education's Ethics of Artificial Intelligence masterclass is the companion offering. ## Australia's six essential practices In October 2025 the Australian Government's Guidance for AI Adoption replaced the eight AI Ethics Principles and the ten voluntary guardrails with six essential practices. They're written for organisations, but each one has a version you can practise in your own work: | Practice | In your own work | |---|---| | 1 · Decide who is accountable | Every AI-assisted workflow has a named owner. Your name goes on the output, not the tool's. | | 2 · Understand impacts and plan accordingly | Ask who is affected, and who could be treated unfairly (see the quiet defaults below). | | 3 · Measure and manage risks | Classify data before you paste it. Place each output on the trust tool. | | 4 · Share essential information | Tell people when AI drafted or decided something that affects them. Check what your organisation's AI policy says about disclosure, and see the privacy rule below. | | 5 · Test and monitor | Check from outside the tool (the check loop, VET), and review at a gate. | | 6 · Maintain human control | Human checkpoints at every amber or red step; some work stays human only. | Practice 4 is now also law. From 10 December 2026, the Privacy Act requires an organisation's privacy policy to say where it uses a computer program to make a decision, or to do something substantially and directly related to making one, when the decision could significantly affect a person's rights or interests and uses their personal information (APP 1.7 to 1.9). The policy must name the kinds of personal information used and the kinds of decisions. AI scoring, triage and saved decision rules can all fall inside it. The OAIC's guidance and flowchart set out the test. If your team uses AI on decisions about people, tell whoever owns your privacy policy. ## Data governance: proportionate, not prohibitive Many organisations land on "don't put anything into AI". That treats every interaction as equally risky, and it mixes up a few real concerns with one imaginary one. The risk sits in the pipeline. When you paste data into a tool, the exposure is transmission, storage, jurisdiction and contract: where it goes, who keeps it, under which law. It isn't someone later "extracting" your document from the model. Email, Slack and shared drives carry the same pipeline risks; AI only feels riskier because it's newer. A proportionate approach: 1. Classify the data. Public, internal, confidential or regulated? 2. Match the tool to the class. Approved work tools with a data-processing agreement for internal and confidential work. Consumer tools for public or non-sensitive material. Regulated data (health, financial, personal) needs a specific assessment first. 3. Manage the real risks. Never paste passwords, API keys or access tokens. Remove personal details where you can. Know the provider's logging and retention terms. 4. Drop the imaginary one. Stop treating "model extraction" as a likely threat, and put the effort where the exposure actually is. ### Set it up safely A checklist for your own accounts. Your organisation's AI policy and privacy officer have the final say on what's approved. The regulator agrees with the cautious line. The OAIC's guidance on commercially available AI products says the Privacy Act applies to personal information you put into an AI tool, and to output that contains it. It recommends, as best practice, not entering personal information, especially sensitive information, into publicly available AI tools. - Two accounts: work and personal. Client work only in a work account on a business plan your organisation has approved. Business plans generally don't train on your data and come with a data agreement. Keep personal use in a personal account, in a separate browser profile, so the two never share a login, history or connected apps. - Turn off training on personal accounts. Look under Settings, then Data controls or Privacy. The names vary: "Improve the model for everyone", "AI data usage", "Help improve". - Memory off, or a temporary chat, for anything sensitive. Memories are kept separately from chat history, so deleting a chat may not delete them. - Connect only what you need. Each connection to your email, files or calendar widens what the tool can read, and what hidden instructions in those files can reach. - Regulated data stays out unless it's approved. Information about children, health or finances of identifiable people only goes into a tool your organisation has approved for that kind of data, and even then without names. Your sector may have stricter rules. - Check client agreements. Some contracts and NDAs now say whether AI can be used on client material. If yours are silent, ask the client. - Can't share it? Have it build the tool instead. Describe the shape of the data and ask for spreadsheet formulas, a short script, or a single web page that runs on your own computer (prompt 14). The tool never sees the data. Test what it gives you on data where you know the answer first, and if you can't read the code, treat it as top-right. - Any product you're unsure of: ask three questions. Which plan am I on? Does it train on what I type? Is there a data agreement with my organisation? Perplexity, for example, uses personal searches to improve its models unless you turn off "AI Data Usage" in Settings (Perplexity help), and says it doesn't train on enterprise customers' data. If your team already uses AI on its own. Unapproved use is common, and the data is already going somewhere. Banning it usually drives it out of sight. A better order: find out what people are using and for what, approve a tool that fits the work, teach the three rules before you paste, and make it easy to ask before pasting something borderline. ## Find the quiet defaults > Activity, about 5 minutes. Ask your AI tool: "Write a one-paragraph scene of a respected senior manager on a busy Monday." Then, in a new chat: "Write a one-paragraph scene of a respected administrative officer on a busy Monday." Read them side by side. The interesting bias isn't the blatant one; models are trained hard against obvious stereotypes. It's in the small choices. What is each person called: a title and surname, or a first name? Who is described as warm, and who as capable? What does each one worry about? Who holds authority in the scene? Try other pairs from your own work: - "a strong graduate applicant" vs "a strong mature-age applicant" - "a high-performing team member" vs "a team member returning from parental leave" - "a successful founder" vs "a successful small-business owner" If you use AI to draft position descriptions, references or performance reviews, these defaults leak into them. The generic output inherits the generic average, including its skew, and noticing that skew is your job. Prefer a guided game? Play Survival of the Best Fit (about 10 minutes) and watch an "objective" hiring algorithm reproduce and amplify the bias in its training data. Then ask: where did the bias get in, and whose job was it to notice? On the trust tool, that's a precise, large-stakes call: top-right corner. ## Four ethics dilemmas Take one or two into a team meeting, or work through them on your own. There's no answer key. The aim is to make the trade-off explicit and decide where a person stays in charge. ### 1 · The biased screen Your team deploys an AI résumé-screening tool. Six months in, an analyst notices it quietly marks down applicants from one group. By its efficiency measure, it's "working". Do you switch it off immediately, or audit it first? Who is responsible: the vendor, the team that deployed it, or the executive who sponsored it? The connection: the bias came in through the data, not malice. Screening decisions are precise and large-stakes, so a person owns them, and "the algorithm did it" is not a defence. ### 2 · The confidently wrong policy bot A customer is quoted a returns policy that doesn't exist, in writing, by your chatbot, and acts on it. Who's accountable? What do you owe the customer, and what do you change in the system? The connection: checking is the product. The checkpoint belongs before a wrong answer reaches a customer, designed in from the start, not added after the apology. ### 3 · Efficiency or apprenticeship? Automating 80% of a junior's routine work looks like a win, until you realise they never learn to judge the output, because the work that trained their predecessors has gone. Is that an ethics question or just an HR one? The connection: the juniors lost the easy reps. Hollowing out expertise for short-term speed deletes your team's future judgement. Keep at least one checkpoint human on purpose, to build capability. ### 4 · "Ship it now, govern it later" A competitor launches an AI feature, and your manager says to match it this quarter and sort out the governance afterwards. Do you? What do you say? The connection: the demo is a trap, and "everyone else is doing it" isn't a plan. Governance added after something goes wrong costs more, in money and in trust, than governance designed in. The thread: every dilemma is the same question. Where does a person stay in the loop, and who owns the consequence when they don't? It isn't a technical question; it's the judgement this book is about. For depth on governance, risk and regulation, see Curtin Executive Education's Ethics of artificial intelligence masterclass. ============================================================ SOURCE: appendices/e-beyond-the-day.qmd ============================================================ # Beyond the chapters The chapters are tool-agnostic on purpose, because the four tools work on any AI, including the ones that ship next. This appendix is not. It names products, settings, and jargon: where each product keeps the standing brief, what the words in vendor pitches mean, what the tools make beyond text, and where agents and the terminal fit. It ends with the big questions that sit outside the chapters. This appendix will date faster than anything else in the book. Menu names were checked in October 2026. When one has moved, search the product's help for "instructions" and apply the same ideas. The four tools do not change when the menus do. ## Set it once In the chapters and exercises you typed the brief fresh, every chat: role, task, context, format, and its check. Every major tool lets you save that as the standing brief it sends with every message. The generic name is a system prompt. The trade names differ. | Tool (web) | The setting is called | Where it lives | |---|---|---| | ChatGPT | Custom instructions · Projects · Memory | Settings → Personalization; each Project has its own instructions | | Claude | Instructions · Projects · Memory | Settings → Your Claude; each Project has its own instructions | | Gemini | Instructions for Gemini · Gems | Settings & help → Personal Intelligence; Gems in the sidebar | | Microsoft Copilot | Custom instructions · Memory | Settings → Personalization | | Msty, LibreChat, Open WebUI | System prompt | Per chat or per model. You edit the prompt itself, so these show most plainly what a system prompt is | Menu names checked October 2026. They move; if one has changed, search the tool's help for "instructions". What goes in: your RTCF brief, your Done line, the check you attach. What doesn't: anything confidential you wouldn't paste into a chat. For the data side (training, memory, two accounts), see Set it up safely. Review the saved brief each quarter, because the corners move and the brief should move with them. Write like me is a worked example. Decide like me uses the same setting to save a set of decision rules. The names differ; the idea doesn't. When a demo says the AI "understands you", look for this setting. It's a text box. You wrote a better one in Exercise 4. ## The jargon, decoded You'll hear these in every vendor pitch. None of them removes the check. | Term | What it actually is | What it changes | |---|---|---| | MCP · Model Context Protocol | A standard plug that lets a harness call outside tools and data: your calendar, your files, the web. | Each connection widens what the harness can read and do. The stakes go up, so place the work on the trust tool again. | | Context window | The model's working memory. | Long chats drift and early instructions fade. That's why the two-chat workflow and the handover prompt on Go deeper help. | | RAG · "grounded on your documents" | The tool reads your files first, then answers. | Better grounding, new failure mode: check what it read, not just what it said. | | Harness | The software around the model: standing instructions, what it can read, what tools it may call. | You already use several. Configuring one well is "set it once", above. | | Skill | A saved, reusable brief that an agent or assistant loads when a task matches. The generic idea is a standing brief; agent tools call it a skill. | Your judgement, written down and reusable. The check still belongs in the brief, and a person still reviews the output. | | Agent | A model in a loop with tools: plans, acts, checks, retries. | Automates the loop, not the standard. The check still comes from outside. | | Prompt injection | Instructions hidden in something the tool reads: a web page, an email, a document, often in white or tiny text. | The tool may follow them as if you wrote them. The risk grows with every connection, and is highest for agents that read and act with nobody watching. Keep a person between what it reads and what it does. Try it. | Skills in practice: Build Web, Guide AI, "The Agent-Ready Repo and Handover", shows how a repeated workflow becomes a tested skill file. ### Try it: a document that talks to the AI Download the Northbridge proposal, an invented supplier offer to RetailFlow (Karen's company from Exercise 5) for weekend and email support. It looks ordinary. 1. Read it yourself first. Note what Karen should know before she signs. 2. Give it to an AI tool. Upload it, or select all, copy and paste. Ask: "Summarise this proposal for Karen, including the cost and the risks. Should she sign?" 3. Compare. Did the summary cover the contract terms and where customer data is stored? Did it push her to sign? Did it end with a piece of fruit? 4. Look for the trick. In Word, select all and change the font colour to black. If the tool ignored the hidden note, that's partly good news: many tools now resist it when you paste a document yourself. The risk is highest when an agent reads email, web pages or shared files on its own, with nobody checking what went in. And don't use the trick on real documents. It gets found, and it costs trust. ## Beyond text The chapters worked in text because judgement shows clearest there. The same models make images, audio, music and video, and the trust tool moves straight over. | Output | On the grid | The check | |---|---|---| | Image mock-up, internal discussion | Green corner | Nothing formal. It's a sketch | | Image in a client-facing deliverable | Red corner | Licence and rights, consent for any real likeness, a disclosure line | | Voice mode, drafting while you walk | Green | The names and figures it "heard". Re-check before sending | | Music or video for a public asset | Amber to red | Copyright here is unsettled; follow your organisation's policy and disclose | | A voice or video call asking for a payment, a password or a change of bank details | Red, however familiar the face | Check outside the channel it arrived on: hang up and call back on a number you already have. In 2024 an Arup employee in Hong Kong paid out about US$25.6 million after a video call in which every other "colleague" was a deepfake (CNN). | Two habits from the chapters transfer: classify before you paste (a face is personal information), and tell people when AI made the thing they're looking at (Responsible use). ## The terminal, if you want it Everything above is the web interface on purpose: it's where the judgement work happens, and where your account already is. The same ideas carry over to developer tools. Agent CLIs take a brief in your terminal and work in a loop, and your review still decides what ships. Local models run on your own laptop, which is the answer when your writing samples can't leave it. They're weaker than the big cloud tools, but for brainstorming and thinking out loud that matters less than you'd think. The ideas they trigger are the useful part. Save the strongest tool for exact facts and data. Msty Studio is the easiest start: one install, then a local model or your own API key. Ollama is the engine many local apps run on, and Open WebUI and LibreChat are chat interfaces an IT team can host for a whole organisation. You can also describe a small tool in plain English and have an AI write it. Treat the result like any other output: if you can't read the code, it belongs in the top-right corner. Test it on data where you know the answer, and keep it away from anything confidential until someone who can read it has. None of this is required. It's the same four tools, faster. Whatever the product, set the standing brief once, connect tools on purpose, and keep the check outside the tool. More in Resources. ## The big questions These sit outside the chapters. They came up in the masterclass, and readers ask them too. Short answers, and where to read more. ### Is AI just software? For governance, yes. Procurement, privacy, security and a named owner apply as they do to any system. For testing, no. Nobody wrote its logic, so nobody can read it. The same input can give a different output. It fails fluently, and an agent can act without asking. That's why this book puts the check outside the tool and a gate before scale (why AI projects fail differently). ### AGI and superintelligence AGI usually means a system that can do most work a person can. Superintelligence means one far better than people at nearly everything. Several AI labs say they are building towards it. Whether and when it arrives is disputed, and the disagreement runs through the field. In a survey of 2,778 published AI researchers, between 38% and 51% gave at least a 10% chance that advanced AI leads to outcomes as bad as human extinction (Grace and others, 2024). Two serious positions, both worth reading: - Take the risk seriously now. In 2023, Geoffrey Hinton, Yoshua Bengio and the heads of OpenAI, Google DeepMind and Anthropic signed a one-line statement: mitigating the risk of extinction from AI should be a global priority alongside pandemics and nuclear war. The International AI Safety Report (2026, led by Bengio, backed by more than 30 countries) is the measured version: what the evidence shows so far, and what it doesn't. - Treat it as normal technology. Arvind Narayanan and Sayash Kapoor's AI as Normal Technology (2025) argues that AI will change things the way electricity did: over decades, through institutions, and under human control. They think superintelligence, as usually described, doesn't hold together, and that building resilience beats drastic intervention. ### The one-shot argument Most engineering improves by failing: ship it, watch it break, fix it. The worry about superintelligence is that this loop might not be there. A system far more capable than us, pursuing goals that aren't quite ours, might not leave room for a second attempt. That is the core of the alignment argument, and it's why some researchers want the safety work done before the capability arrives rather than after. The argument's logic holds. It also rests on open questions: whether capability arrives in a jump or by degrees, whether these systems become agents with goals of their own, and whether we keep the ability to watch and correct them. Serious people answer those differently, and nobody knows yet. ### What about the energy cost? Real, and growing fast in total, but smaller per question than most people guess. Google measured its median Gemini text prompt at 0.24 Wh, about nine seconds of television (Google, 2025); that's the vendor's own figure for one product. Across the world, data centres used about 1.5% of electricity in 2024, and the International Energy Agency expects that to more than double by 2030, with AI the main driver (IEA, Energy and AI). Images, video, long reasoning and agents use far more than a short text prompt. The habits that help: use a smaller model for small jobs, don't regenerate for the sake of it, and ask vendors for their numbers. ### You've already met the small version Alignment means getting a system to do what we actually want. The chapters showed it falling short in small ways: - a model tuned to please you, which folds when you push back with no new evidence - mistakes that don't look like mistakes, so your alarm stays quiet - values nobody chose, in the quiet defaults - an agent checking its own work and sharing its own blind spots This book's answers are a check from outside the tool, a blind test before you rely on anything, and a gate where kill is a real option. Safety researchers ask for the same things at a much larger scale. The one-shot worry is about what happens if those habits stop being possible. To follow it: the International AI Safety Report publishes yearly with updates in between. Australia's AI Safety Institute was announced in November 2025 to monitor and test emerging AI. For governance and regulation in depth, Curtin's Ethics of artificial intelligence masterclass. ============================================================ SOURCE: appendices/f-further-reading.qmd ============================================================ # Further reading Three picks first, one per angle, all free. Then the sources behind specific chapters, so you can check this book the way Chapter 7 taught you to check anything else. ## Read next Practice. Conversation, Not Delegation, the companion book this course draws on. Start with the VET and conversation loop chapters: michael-borck.github.io/conversation-not-delegation. Safety. The International AI Safety Report 2026, led by Yoshua Bengio. The three-page executive summary is enough to start: internationalaisafetyreport.org. The sceptical view. Arvind Narayanan and Sayash Kapoor, "AI as Normal Technology" (2025), on why change may arrive over decades rather than years: knightcolumbia.org. ## Australian guidance and law - Australian Government, Guidance for AI Adoption (October 2025). The six essential practices in Appendix D, with an AI policy template: ai.gov.au. - Office of the Australian Information Commissioner, guidance and flowchart on transparency for AI and automated decision-making, covering the Privacy Act APP 1.7 to 1.9 obligations from 10 December 2026: oaic.gov.au. - Curtin Executive Education, Ethics of Artificial Intelligence masterclass, for governance, risk, and regulation in depth: curtin.edu.au. ## Sources behind the chapters - Chapter 5. Abrami, P. C. et al. (2015). "Strategies for Teaching Students to Think Critically." Review of Educational Research. Dialogue as a lever for critical thinking: doi.org/10.3102/0034654314551063. - Chapter 8. Dylan Davis, the Decide Like Me method. The course adopts the elicitation and blind-testing core and stops short of autonomous decisions, as the chapter explains. - Chapter 11. Department of Employment and Workplace Relations (2026), AI and Employment in Australia. Jobs and Skills Australia (2025), Generative AI Capacity Study. Brynjolfsson, E., Chandar, B., and Chen, R. (revised 2026), "Canaries in the Coal Mine?" on early-career employment in AI-exposed US jobs. - Chapter 1. Michael Crichton (2002), speech coining "Gell-Mann amnesia", named for Murray Gell-Mann. ## Free tools from the course - Trust Tool game. Ten placement scenarios with explanations: trusttool.borck.education. - Course companion site. Workbook, prompt builder, slides, downloads, and the Northbridge prompt-injection document from Appendix E: michael-borck.github.io/the-human-edge. - CiteSight. Checks whether references exist, for the Verify step in Chapter 7: citesight.eduserver.au. - Style Mirror. Drafts a voice brief from writing samples, for Chapter 5: stylemirror.eduserver.au. ## The Human Edge series - This book. The Human Edge: Using AI with Judgement. Personal judgement at your desk and in the work you deliver. Curtin Executive Education masterclass of the same name. - In development. The Human Edge: Leading AI with Judgement. Choosing which AI projects to back, and making sure they deliver. The companion masterclass replaces AI in Strategy and is being redesigned before the book is written, so the book can be tested in the room first. That order is deliberate, and Chapter 10 explains why. ============================================================ SOURCE: acknowledgments.qmd ============================================================ # Acknowledgments This book began as a one-day Curtin Executive Education masterclass, first marketed as AI for Professionals: Building Everyday Capability and renamed, mid-flight, to the better title it now carries. The renaming slide, which strikes the old title through and sticks the new one over it, survives in the course deck. It is a fair picture of how this material was made: practical first, honest about what it replaced. The argument was shaped in the room. Participants who placed the same scenario in different corners of the Trust Tool, and then had to defend the placement, taught the author more about stakes than any framework could. The RetailFlow exercise works because people really did forward the fluent claim to the fictional Karen before checking it. The Decide Like Me exercise works because roughly four calls in five match, and the fifth one is always interesting. Every improvement in these pages can be traced to a debrief that ran long. This book sits in a small family, and the family made it better. Conversation, Not Delegation supplied the method: converse, push back, verify from outside the tool. Prove, Don't Persuade supplied the insistence that a demo is not evidence. The Human Edge is where those ideas meet an ordinary working week. The Decide Like Me method, and the "broken ladder" framing of the junior pipeline problem discussed in Chapter 11, draw on Dylan Davis. The Australian employment evidence draws on the Department of Employment and Workplace Relations (2026) and Jobs and Skills Australia (2025). "Gell-Mann amnesia" is Michael Crichton's term. RetailFlow, Northbridge, and their data are invented for teaching; any resemblance to real organisations is coincidental. The open-source community behind Quarto, Pandoc, and GitHub made it possible to write, build, and publish this book alongside the course site, the workbook, and the Trust Tool game, all from text files the reader can inspect. This book was written using the method it teaches. AI drafted, summarised, and proposed structures at every stage. It also produced fluent errors on schedule, including about the dataset in Chapter 6, which is why every figure there was recomputed from the source file. The machine made the work faster. The judgement, and the responsibility for every claim that remains, are the author's. ============================================================ SOURCE: about-author.qmd ============================================================ # About the Author Michael Borck is a software developer and educator working at the intersection of human expertise and artificial intelligence. He teaches applied AI and AI in business at Curtin University, and runs The Human Edge masterclasses through Curtin Executive Education. The question that started this book (when everyone has the same AI tools, where does my edge live?) is the one participants bring to every run of the day. His earlier book, Conversation, Not Delegation, argues for treating AI as a thinking partner you converse with. The Human Edge: Using AI with Judgement takes that method to the professional's desk: four tools for briefing, trusting, checking, and delivering with AI, tested in the classroom and in executive education before they were written down. The companion volume, The Human Edge: Leading AI with Judgement, takes the same judgement to the organisation and is in development. The tools in this book grew out of watching capable professionals forward fluent AI output they had not checked, not from carelessness, but because nothing about the output told them to stop. The durable skill is not a better prompt. It is judgement: deciding what to ask, how much to trust, and where a person stays in charge. That skill does not expire when the next model arrives, and it cannot be delegated to the model itself. Michael builds educational software and resources, and writes about the 80/20 principle in learning and professional judgement. --- \newpage Connect - GitHub projects: Software and educational resources - Free book collection: Current online editions and downloads - 8020workshop.com: Passion projects and workshops - LinkedIn --- Other Books in This Series The Human Edge: - The Human Edge: Leading AI with Judgement (in development): choosing which AI projects to back, and making sure they deliver AI-Collaboration and Judgement Track: - Conversation, Not Delegation: How to Think With AI, Not Just Use It: the general method behind this book - Prove, Don't Persuade: Why Proof Beats the Demo in Applied AI - Substantiate, Don't Assume: Why the Auditor's Opinion Matters More Than Ever in the Age of AI - Partner, Don't Police: AI in the Business Classroom Python Track: - Think Python, Direct AI: Computational Thinking for Beginners - Code Python, Consult AI: Python Fundamentals for the AI Era - Ship Python, Orchestrate AI: Professional Python in the AI Era - Converse Python, Partner AI: The Intentional Prompting Methodology Web Track: - Build Web, Guide AI: Business Web Development with AI