Prompt Engineering & Structured Prompting

AI-Augmented Analyst · independent branch · Node AI0.03 of 7 · ~14 focused hours · rubric gate ≥85%

Every output you will ever pull from a language model sits downstream of a prompt somebody wrote: a summarized filing note, a first-draft memo paragraph, a reformatted table, a sanity-checked thesis. Whether that output comes back useful, mediocre, or quietly wrong depends more on how the question was asked than on which model answered. AI0.01 taught you the machine underneath: a system that predicts the next plausible token from a corpus with a cutoff, with no built-in sense of "true." Nothing about that changes here. What changes is that you now learn the craft of aiming the plausible-token machine at something narrow, checkable, and useful for analyst work: the same way a well-built spreadsheet formula channels raw numbers into one specific, auditable answer instead of a guess.

This is a real, teachable, transferable skill, not folklore or luck. A vague, one-line prompt ("summarize this filing") reliably produces a vague, generic, hard-to-verify answer; a well-structured prompt reliably produces a narrower, more checkable one. The gap between the two comes from a small number of named techniques, not talent, applied deliberately in something close to a fixed order. State who the model should reason as and for whom. Hand it exactly the material it is allowed to use, say exactly what job it is doing, and specify exactly what shape the answer must take. Because you already know the model's plausible-not-true habit from AI0.01, every technique here ends the same way: a verification step that sends you back to a primary source before the output touches any real deliverable.

Over the roughly fourteen hours ahead you will build five techniques into instinct: role-context-task-format framing, few-shot teaching by example, decomposition into a checkable chain, demanding citations and honest uncertainty instead of manufactured confidence, and specifying structured output precisely enough to validate by eye or by script. Then you will assemble four of them into a reusable prompt-pattern library built for the jobs that fill an analyst's week. Those jobs are pulling a table out of a mess of prose, getting a plain-English read on a dense filing note, having a draft checked before it goes anywhere, and stress-testing your own thesis before someone else does it for you. Every pattern in the library ends with its own named verification step, because a fluent answer and a correct answer are not the same claim. Telling the two apart is the habit the whole library exists to build.

Learning objectives

Here is what you can do:

1. Write a complete Role–Context–Task–Format (RCTF) prompt for a real analyst task, and diagnose which of the four elements is missing when a prompt underperforms.
2. Use one or more worked examples (few-shot) to teach a model a format, a judgment call, or a house style, and explain when adding examples helps versus when it silently teaches the wrong lesson.
3. Decompose a multi-step analyst task into a chain of smaller, independently verifiable prompts, and explain why chaining reduces but never eliminates compounding error.
4. Write prompts that explicitly demand a cited source, a stated confidence level, and a named list of uncertainties, and explain why asking a model "how confident are you" does not, by itself, produce a trustworthy number.
5. Specify a structured output format (a JSON schema, a fixed-column table) precisely enough that a human or a script can check it mechanically, and handle a field the source does not support without letting the model invent one.
6. Apply the four analyst prompt patterns (extract-a-table, explain-this-filing-note, draft-then-critique, red-team-my-thesis) from memory, each ending in its own verification step.
7. Trace every prompted output back through the Primary-Source Guardrail (Trace, Match, Recompute, Date-check, Cite) before it is used in any real analyst deliverable.
8. Diagnose, from a short transcript alone, which common prompt-engineering mistake (a vague ask, a buried instruction, an unverified confidence figure, a leading question, an unchecked chain) is responsible for a bad output.
9. Build and maintain your own small library of reusable, analyst-grade prompt templates, and state, for each one, the by-hand skill you must still own before trusting it.

Prerequisites & connections

Builds on. AI0.01's mental model (next-token prediction, no built-in notion of true, fluent output that can still be wrong) is the reason every technique here ends in verification rather than trust. AI0.02 gave you the tool-evaluation rubric and the category map (chat assistant, coding copilot, research/agentic, and the rest); the assumption from here on is that you can already place a tool in a category, so the teaching now is what to actually type into it. Like every node in this branch, AI0.03 is independent of the eleven-phase Finance sequence: nothing here gates the accounting, valuation, or industry phases, and nothing outside AI0.01–AI0.02 gates entry here.

Feeds forward. AI0.04 (Retrieval & RAG) reuses the citation discipline built here directly: a grounded answer is only as good as the prompt that demanded the grounding, and "chat with a filing" is, underneath, an extract-a-table and explain-this-filing-note prompt aimed at a retrieval system instead of a single pasted excerpt. AI0.05 (agents) is built entirely out of prompts: every step of a plan-act-observe loop is itself a prompt, and a badly specified step is exactly where an agent starts to compound errors. The chaining discipline you build here is the seam. AI0.06, the branch's crown, assumes you already know what a well-formed prompt looks like, so that when an output is still wrong despite good prompting, you can tell that apart from an output that is wrong because the prompt invited it to be. AI0.07's capstone puts your prompt-pattern library to work across real analyst tasks. Nothing here requires code; nothing here requires a paid tool; every exercise runs in whatever tool you chose in AI0.02.

Core teaching content

Why prompting is a real lever, not a courtesy

A chat model is built to be cooperative: given almost any question, it will produce a fluent, confident-sounding answer, and it will rarely volunteer "I don't have enough information to answer that" unless the prompt explicitly invites it to say so. That single fact is why prompt quality matters as much as it does. A bad prompt does not fail loudly. It does not come back blank, or hedge visibly, or flag itself as unreliable. It comes back looking exactly as polished as a good prompt's answer, because fluency and formatting are products of the same next-token-prediction process regardless of whether the underlying content is right (AI0.01's payoff line, showing up here for the first of many times). There is no dashboard warning light distinguishing a well-grounded answer from a plausible improvisation: the only lever you have before the fact is how precisely you ask, and the only check you have after the fact is verification. What follows is entirely about the first half of that pair.

Every technique below leans on it by name, so here is the five-check Primary-Source Guardrail as a standing reference. Check 1 Trace: no figure is used until it is traced to a named primary source (or explicitly marked synthetic). Check 2 Match: figure, unit/scale, period, and entity all agree with that source. Under 3 Recompute, any number the model derived (a margin, a growth rate, a ratio) is re-derived by you from the raw inputs, never taken on the model's word. Under 4 Date-check, the source postdates the model's training cutoff where currency matters, and the model itself is never treated as the source. Last, 5 Cite: you record the exact location (page, note, line) so a reviewer can find what you found. AI0.01 introduces this idea and AI0.06 drills it to a crown-level gate. Every prompt pattern that follows points back to it.

RCTF: Role, Context, Task, Format

Four elements turn an open-ended request into a narrow, checkable one, and each does a distinct job.

Role sets the register and the lens: who the model should reason as, and often, for whom. "Write for a portfolio manager who has ninety seconds" produces a different shape of answer than "write for a first-year analyst learning the company," even from identical facts. What Role does not do, and this is the single most common misunderstanding of the technique, is grant the model real expertise it doesn't otherwise have. Telling a model to "act as a senior forensic accountant" does not mean it now correctly and reliably applies a specific accounting standard, holds any credential, or has checked its own reasoning against a rulebook. It shifts framing and emphasis only. The facts still come only from Context and from training data, and both still need verification exactly as if no role had been stated at all.

Context is the exact material the model is allowed to use (a pasted excerpt, a table, a set of notes), and, just as importantly, an implicit boundary on what it should not reach outside of. Stating this boundary explicitly ("use only the text below; do not use outside knowledge about this company") is cheap and matters: without it, a model will freely blend a pasted fact with a recalled one from training, and the blend is invisible in the output's tone, reading exactly as confident either way. This is the seam AI0.04 builds an entire module on; here, the discipline starts with one sentence.

Task is one unambiguous job, stated as an instruction, not left as an open question. "Tell me about this company's margins" is not a task; "state which segment's margin moved more, in percentage points, and name the driver the text gives for each" is. A prompt with a vague Task has, in effect, no wrong answer, because it never defined a right one, which also means it has nothing for a reviewer to check it against.

Format specifies the exact shape the answer must take: length, structure, headings, and, critical for anything you intend to verify, a shape narrow enough that a reviewer can tell in seconds whether the answer is complete. "A 120-word paragraph" is a Format instruction; "tell me about it" leaves length, structure, and emphasis entirely to the model's own defaults, which vary.

One ordering note worth internalizing early, because it prevents a specific and common failure covered again under Common Mistakes: when Context is long (several paragraphs or pages of pasted material), state the Task and Format instructions both before and after the paste, not only at the end. Models can under-weight an instruction buried in the middle of a very long block of text (the "lost in the middle" effect); repeating the instruction at both ends is cheap insurance, not redundancy. A minimal RCTF shape, with placeholders, looks like this:

Role: You are <who the model should reason as, and for whom>.
Context: Use only the material below; do not use outside knowledge. [paste here]
Task: <one unambiguous job, stated as an instruction>
Format: <exact shape — length, structure, what to do if a figure is missing>

{ "skill": "Turning a recurring ask into a reusable RCTF template", "use": "(a) Draft a first-pass Role-Context-Task-Format template for a task you repeat often (e.g., a weekly company-snapshot note), so you stop re-inventing the prompt from scratch every time.", "tools": ["Chat assistant — Claude, ChatGPT, Gemini (as of July 2026)"], "prompt": "Act as a <ROLE, e.g. buy-side analyst writing for a portfolio manager>. Using ONLY the material below Context, do the following Task: <state the one job in one sentence>. Return it in this Format: <exact structure, length, headings>. If any figure below is missing or ambiguous, say so explicitly instead of estimating it. Context: <paste your source material here>", "verify": "Mandatory: before this template's output touches any real note or memo, trace every figure and claim it produced back to the pasted Context or a named primary source (Guardrail 1-5) — a clean template does not exempt any single run from the check.", "diy": "You must already be able to write this note by hand from the same source material, including knowing which figures matter and roughly what a sane answer looks like — the template only removes re-typing, never the judgment of what to ask for." }

Few-shot prompting: teaching by example

Some judgment calls are easier to show than to fully specify in words: a house tone, a classification boundary, a table's exact column order. Few-shot prompting supplies one or more worked examples of the input-output pattern you want, letting the model learn the pattern by demonstration in addition to (or instead of) a written description.

The risk sits in the word "one." A single example teaches whatever happened to be true of that example, not necessarily the general rule you intended: the model can latch onto an incidental surface feature (a specific number, a coincidental phrase, even a specific verdict) rather than the underlying judgment. The fix is two things done together. First, use 2–3 varied examples, chosen so that the surface details differ (different names, different numbers, different phrasing) while the underlying judgment stays constant. Second, state the general rule in words alongside the examples, so the model has both the demonstration and the explicit description pointing at the same target. Few-shot teaches the model your judgment; it cannot manufacture a judgment your own team hasn't actually made yet, which is why the examples you supply should reflect calls you already trust.

Decomposition and chaining

A single prompt that asks for five things at once tends to shortchange whichever item lands in the middle of the list. The same lost-in-the-middle tendency that affects long Context also affects long, multi-part Tasks. The fix is decomposition: break the one large ask into a chain of smaller prompts, each with a single job, where the (verified) output of step N becomes the input to step N+1.

The word "verified" is doing real work in that sentence. Define a checkpoint as a defined point where a human looks at (or at minimum spot-checks) the intermediate output before it is allowed to feed the next step. Checkpoints matter because errors compound across an unchecked chain. If four independent steps are each correct 90% of the time and none are checked along the way, the chance that all four are right together is roughly 0.9⁴ ≈ 66%. That is noticeably worse than any single step's own accuracy, and worse than a careful reviewer might assume from "each step usually works." A checkpoint after each step re-anchors accuracy to (close to) 100% before the next step runs, which is exactly how a chain avoids becoming less reliable than one careful prompt rather than more. This is the same "reduces but never eliminates" honesty that runs through this whole program: chaining lowers the error rate versus one giant, unverifiable prompt, but it does not remove the need to look.

Citations, confidence, and uncertainty: asked for honestly

Ask a bare chat model (no live retrieval, no tools) for a citation and you will get one of two very different things, and the difference matters enormously. The first is a citation to your own pasted Context ("this figure appears in the paragraph beginning 'Segment revenue...'"), which is cheap to check because the source is sitting right there in the same conversation; always ask for this kind, every time. The second is a citation to an outside source recalled from training: a report, a paper, a filing the model did not see in this conversation. You cannot verify it without going and looking, and models are documented to fabricate such citations outright on occasion (a named failure mode drilled to a gate in AI0.06). Treat the two as categorically different: an in-context citation is evidence; a recalled-from-memory citation is a lead that must be run down before it is used.

Confidence language deserves the same skepticism. A model that says "I am 95% confident" is not reporting a calibrated statistic. It has no real introspective access to how often answers phrased this way turn out correct. The number is generated text shaped by the phrasing of your question, and models are documented to run uniformly overconfident: a stated 95% and a stated 60% carry roughly the same low evidentiary weight until something independent checks them. A bare confidence percentage is decoration. What actually helps is asking the model to name, specifically, which inputs it was not given directly (which figures it inferred, estimated, or recalled from general knowledge rather than read straight from your Context), because that produces a short, concrete checklist of exactly what to verify first. It is still generated text and still requires your own check; it is simply a more useful shape of generated text than a bare number.

State your confidence (low / medium / high) for each figure above, and separately list —
specifically — which inputs you were NOT given directly in the text above (i.e., you
inferred, estimated, or recalled from general knowledge). Flag these before I use them.

Structured output: JSON, schemas, and tables you can validate

Asking for structured output (a JSON object, a fixed-column table) earns its keep three ways. It is checkable at a glance or by script against a schema: right fields, right types, right row count. It forces the model to commit to discrete claims instead of hiding vagueness inside a paragraph. And it plugs straight into the tools you already use, whether a spreadsheet import, a script, or a database row.

Specifying the schema precisely means naming every field, its type, and its unit: "revenue_inr_crore" as a number, not "revenue" as a string that might be crore, might be lakh, might be raw rupees. The part beginners skip is stating explicitly what to do when the source doesn't support a field. Return null, never a guessed value, and never convert a unit you did not ask to have converted. State the expected record shape too ("one object per fiscal period found in the text; do not include a period that is not present; do not extrapolate a missing one").

The trap underneath all of this: valid JSON syntax is not evidence that the content is correct. A model can emit a perfectly well-formed object with an invented number sitting inside it exactly as easily as it can emit a wrong number in loose prose. Structured output narrows where you look; it does not replace looking. Guardrail 2 (Match) and Guardrail 3 (Recompute) apply to a JSON object exactly as they apply to a sentence.

{ "skill": "Extracting a pasted filing excerpt into a validated JSON table", "use": "(b) Convert a messy pasted paragraph or PDF-copied page of figures into a clean, typed JSON table you can import straight into a spreadsheet or script.", "tools": ["Chat assistant with long-context paste — Claude, ChatGPT, Gemini (as of July 2026)", "Spreadsheet — a plain paste of the returned JSON into a new sheet, or Power Query if the tool exposes one"], "prompt": "Extract the following fields from the Context below into a JSON array, one object per <fiscal period>: <field_1_name_unit>, <field_2_name_unit>, ... Use null for any field not stated in the text below -- never estimate or convert units I did not ask for. Do not include a period that is not present in the text. Context: <paste the excerpt>", "verify": "Mandatory: re-open the source excerpt and, cell by cell, confirm figure + unit/scale + period + entity all agree (Guardrail 2 -- Match), and confirm no row exists that is not literally present in the excerpt (Guardrail 1 -- Trace) -- valid JSON syntax is not evidence the content is correct.", "diy": "You must already know how to build the same table by hand -- read the note, copy the right cells, get the units right -- before you can tell a correct machine extraction from a fabricated one at a glance." }

The analyst prompt-pattern library

Four reusable patterns follow, each an RCTF shape purpose-built for one recurring analyst job. Memorize the shape and the reason for it, not the exact wording: adapt the placeholders to whatever is actually in front of you. Every one of the four ends with its own named verification step; none of the four is complete without it.

Pattern 1, extract-a-table, is what you reach for when unstructured or semi-structured prose (an MD&A paragraph, a pasted PDF page, an email) contains numbers that belong in a table.

Role: You are a meticulous data-extraction assistant. You must never infer, estimate, or
carry over a figure from outside knowledge.
Context: [paste the exact excerpt below, verbatim, with page/section marked]
Task: Extract the following fields, one record per <fiscal period found in the text>:
  - <field_1> (unit: <e.g. INR crore>)
  - <field_2> (unit: <...>)
Format: A JSON array of objects, one per period, using these exact keys. Use null for any
field not stated in the text. Do not include a period that is not present in the text.
Do not convert units unless explicitly asked.

Verify: re-open the source excerpt and confirm every extracted cell's figure, unit/scale, period, and entity all agree with the page (Guardrail 2: Match), and confirm no row exists that is not literally present in the source (Guardrail 1: Trace). A fabricated row (plausible, well-formatted, and absent from the source) is this pattern's single most common failure.

Pattern 2, explain-this-filing-note, is for a dense footnote or MD&A paragraph (a contingent-liability note, a related-party note, a segment note, a revenue-recognition policy) that needs a plain-English read plus a sense of what a red flag would look like in a note of this kind.

Role: You are a plain-English explainer. You only use what is in the pasted text below --
never outside knowledge about this company, its industry, or its filings history.
Context: [paste the exact note, plus one paragraph of surrounding text for orientation]
Task: (1) Explain in plain English what this note says and why a company would disclose it.
(2) Separately, describe -- as a GENERAL pattern, not a claim about this company -- what a
red flag would look like in a note of this type.
Format: A short paragraph for (1), a bulleted list for (2), and a final line stating:
"This explanation uses only the text provided above."

Verify: confirm the explanation never reaches for a "fact" about the company that was never in the pasted note. Background knowledge dressed as an explanation of the text is a hallucination even when it sounds informed (Guardrail 1: Trace). Then confirm any accounting standard or threshold referenced is appropriate to the filing's actual period, not a stale training-era assumption (Guardrail 4: Date-check).

Pattern 3, draft-then-critique, takes a memo paragraph, a summary, or a thesis draft and gives it a structured pass for weak logic, unsupported claims, or a missing counter-argument before a human reviewer sees it. It runs as two separate passes.

PASS 1 (drafter):
Role: You are drafting a first-pass <memo paragraph / summary> for a <named audience>.
Context: [paste source material]
Task: Draft <the specific deliverable> in no more than <length>.
Format: <the exact structure the audience expects>

PASS 2 (critic -- a FRESH conversation, not a continuation of Pass 1):
Role: You are a skeptical reviewer whose job is to find problems, not to be encouraging.
Context: The source material: [paste the same source material]. The draft to review:
[paste the Pass-1 output only -- not its working notes or justification].
Task: List every claim in the draft that is not directly supported by the source material,
quoting the specific sentence, and naming what is missing or wrong.
Format: A numbered list, most serious issue first; end with "issues found: <n>."

Verify: a critique pass is generated text too, not a guarantee: the human must still independently check the two or three highest-stakes claims (whatever the critique flagged, and especially whatever it didn't) against the primary source. "No issues found" proves only that this particular pass didn't surface anything; it is never, on its own, proof the draft is clean.

Pattern 4, red-team-my-thesis, runs before you commit to or present an investment or consulting conclusion, and surfaces the strongest possible case against it on purpose rather than leaving it to a client or a manager later.

Role: You are an adversarial <analyst / reviewer> whose only job is to break the thesis
below. Do not soften the language or hedge toward agreement.
Context: Thesis and key numbers/assumptions: [paste your thesis and its supporting figures]
Task: Name the 3-5 weakest assumptions, ranked by how much being wrong would change the
conclusion. For each, name the single data point or event that would falsify it, and sketch
a numeric bear case.
Format: A ranked list; each item ends with "what would resolve this: <...>"

Verify: exactly as with Pattern 3, any counter-fact the pass cites that is not present in what you pasted must be traced to a named primary source before you treat it as a real risk (Guardrail 1: Trace). A plausible-sounding, fabricated counter-argument is exactly as easy for this pattern to produce as a fabricated supporting figure would be for any other prompt, and being adversarial does not make a model's claims true.

{ "skill": "Stress-testing your own thesis before you present it", "use": "(c) Have the model argue the strongest case against a conclusion you are about to commit to, so weak assumptions surface on your own desk instead of in front of a reviewer or a client.", "tools": ["Chat assistant -- Claude, ChatGPT, Gemini (as of July 2026)"], "prompt": "You are a skeptical <analyst/reviewer> whose only job is to break the thesis below, not to be diplomatic. Thesis and key numbers: <paste>. List the 3-5 weakest assumptions ranked by how much they would change the conclusion if wrong, and for each, name the single data point that would falsify it. Do not soften the language.", "verify": "Mandatory: any counter-fact the red-team pass cites that is not present in what you pasted must be traced to a named primary source before you treat it as a real risk (Guardrail 1) -- a fabricated-but-plausible counter-argument is exactly as easy for this pattern to produce as a fabricated supporting figure.", "diy": "You must be able to construct your own bear case unaided first -- the five questions, the competitive threats, the base-rate check -- before red-teaming; the pass is a supplement that catches what you missed, never a substitute for having done the analysis." }

Common mistakes & how experts think differently

1. The vague, role-less, formatless ask. "Summarize this" or "tell me about X" leaves the audience, the allowed material, the actual question, and the answer's shape all undefined. The beginner treats this as saving time; the expert recognizes that an undefined ask has no wrong answer because it never defined a right one, which means there is nothing left to verify against. The first fix for almost any disappointing output is to check whether Role, Context, Task, and Format were all actually stated, rather than assumed.
2. Burying the instruction under a wall of pasted context. Paste six pages of a filing and add one line of instruction at the very end, and the model frequently defaults to a generic, full-document gloss instead of the narrow thing you actually asked for: the lost-in-the-middle effect. The expert states the Task and Format both before and after a long paste, treating the repetition as cheap insurance rather than redundancy.
3. One-shot overfitting. A single worked example teaches whatever happened to be true of that example (a specific number, an incidental phrase, even a specific verdict) rather than the general judgment intended. The expert uses 2–3 varied examples and states the general rule in words alongside them, so the one constant across the set is the judgment, not any single surface detail.
4. Treating a stated confidence number as a calibrated statistic. "I am 95% confident" sounds precise and is not. The model has no real introspective access to how often answers phrased this way turn out correct, and models are documented to run uniformly overconfident regardless of a claim's true reliability. The expert asks instead for a named list of what was not directly given, and verifies the underlying figure regardless of any confidence language attached to it.
5. Trusting valid JSON as proof of correct content. A perfectly well-formed, schema-matching JSON object can still contain an invented figure: syntax validity and factual correctness are entirely different properties. The expert always instructs null-on-missing explicitly, and still checks every value in a structured output against its source exactly as if it had arrived as loose prose.
6. The leading or loaded question. "Isn't it obvious that…" or "wouldn't you agree that…" presupposes the answer and primes a model toward sycophantic confirmation rather than fair analysis. The expert asks neutrally for what the source actually supports, explicitly permits a "the source doesn't say" answer, and reaches for draft-then-critique or red-team-my-thesis whenever a conclusion needs a genuine stress test instead of a friendly nod.
7. Skipping verification because the output looks polished. Fluent phrasing, clean formatting, and a confident tone are outputs of the same next-token-prediction process regardless of whether the underlying content is right (AI0.01's root cause, showing up again). That is exactly why every pattern in this library ends with a named verification step rather than "if it reads well, it's probably fine."
8. Chaining without a checkpoint. Stringing four or five prompts together and only glancing at the final output loses track of which step introduced an error. Errors compound: four independently 90%-correct steps land right together only around two-thirds of the time if none are checked along the way. An unchecked chain can therefore end up less reliable than one careful prompt, not more. The expert defines a checkpoint after every step whose output feeds the next, and treats skipping one as a deliberate risk decision, never a convenience.

Worked examples

Worked example 1: Sahyadri FoodWorks Ltd: RCTF turns a vague ask into a checkable one (India, ₹, synthetic)

Start with Sahyadri FoodWorks Ltd (synthetic, India, ₹ crore), which reports: "Revenue grew 11% to ₹1,240 crore. Snacks segment revenue rose 6% to ₹740 crore with EBIT margin easing from 14.2% to 12.6% on higher input costs. Beverages segment revenue rose 19% to ₹500 crore with EBIT margin improving from 9.8% to 11.4% on a favourable mix shift toward premium variants and lower freight cost per case." A vague prompt ("Tell me about this company's margins") states no audience, no allowed material, no specific question, and no output shape; it would likely produce a rambling restatement of both segments with nothing precise enough to check.

Solution. The RCTF version instead names all four elements. The Role is a sell-side analyst writing for a portfolio manager with sixty seconds. The Context is the excerpt above, and nothing else. The Task is to state which segment's EBIT margin moved more, in percentage points, year-on-year, and to name the driver the text gives for each. The Format is exactly two lines: "Bigger mover: …" and "Drivers (Snacks: …; Beverages: …)." Working it by hand: Snacks moved 14.2% → 12.6%, a change of −1.6 points; Beverages moved 9.8% → 11.4%, a change of +1.6 points: a tie in magnitude, opposite direction, a detail a rambling summary would very likely bury. Correct answer: "Bigger mover: tie (Snacks −1.6 pts, Beverages +1.6 pts). Drivers (Snacks: higher input costs; Beverages: favourable mix shift and lower freight cost per case)."

Verification (Guardrail 1: Trace, Guardrail 3: Recompute): both margin figures and both drivers appear verbatim in the excerpt; recomputing by hand, 12.6 − 14.2 = −1.6 and 11.4 − 9.8 = +1.6, confirms the arithmetic before either figure goes into a note under your name.

Read it. The facts available to answer the vague prompt and the RCTF prompt were identical: what changed was whether the ask was specific enough to produce a checkable claim. "Tell me about margins" has no wrong answer because it never defined a right one; "state which segment moved more, in points, and cite the driver" has exactly one, which is the entire reason to write prompts this way for anything that will be verified before use.

Worked example 2: Harbor Point Software Inc.: few-shot teaches a renewal-risk judgment call (US, $, synthetic)

The problem at Harbor Point Software Inc. (synthetic, US SaaS) is classifying customer-account notes Low/Medium/High for renewal risk in a consistent house style, a judgment call easier to demonstrate than to fully specify. A one-shot version supplies a single example ("Account: overdue invoice, champion left → High") and risks anchoring the model to those two literal signals alone, mis-classifying an account with equally serious but different signals as Low. A better three-shot version varies the signals across the range: Low (on-time payment, expanding seats, no tickets), Medium (flat usage, one open ticket, on-time payment), High (overdue invoice, champion departed). It states the rule in words as well: "Risk reflects estimated likelihood of non-renewal in the next 90 days, based on the signals present in the note, not any single keyword."

Solution. New account to classify: "Payment on time, but weekly active-seat usage fell 40% last quarter, and the account has filed two data-export requests in the last month." Under the one-shot version, a model anchored to "overdue invoice / champion left" might under-flag this as Low, since neither literal phrase appears. Under the three-shot version plus the stated rule, the expected read is Medium-to-High: a usage collapse and export requests are exactly the kind of signal the Medium and High examples trained the model to weigh, even though neither example used those exact words.

Verification (Guardrail 1: Trace): confirm the two cited signals actually appear in the note fed to the model, and independently sanity-check that a usage collapse plus export requests are signals your own team already treats as pre-churn behavior. Few-shot teaches the model your judgment; it cannot create judgment your team hasn't already made.

Read it. The difference between the two prompts was variety, not length. One example teaches "matches this exact case"; three examples spanning the label range, with the rule stated in words too, teach the actual axis being judged. Whenever a classification or formatting task feels hard to describe in a sentence, that is the cue to reach for a small, deliberately varied few-shot set rather than three more paragraphs of instructions.

Worked example 3: Nilgiri Textiles Ltd: decomposing one ask into a checkable chain (India, ₹, synthetic)

The single ask: "Build a 3-year revenue and gross-margin trend table for Nilgiri Textiles Ltd (synthetic, India, ₹ crore) from the pasted excerpts, flag any year with a margin move bigger than 3 points, and write a 2-paragraph note for a credit committee." Source: FY23 revenue ₹1,050 cr, gross margin 21.4%; FY24 revenue ₹1,180 cr, margin 22.1%; FY25 revenue ₹1,340 cr, margin 17.6%.

Solution. Step 1 (extract-a-table): produce the JSON table from the excerpts only. Checkpoint: confirm all three rows against the source: they match. Step 2 (fed the confirmed table): "Flag any year where gross margin moved more than 3.0 points versus the prior year, stating the move." Expected: FY24 vs FY23 = +0.7 pts (no flag); FY25 vs FY24 = −4.5 pts (flagged). Checkpoint: recompute 22.1 − 21.4 = 0.7 and 17.6 − 22.1 = −4.5 by hand: both confirmed. Step 3 (fed the confirmed table and confirmed flag): "Write a 2-paragraph committee note; paragraph 2 must state explicitly that the FY25 cause is not given in the data provided and must be obtained separately."

A single giant prompt asking for all three at once risks narrating "margins were roughly stable with a dip in FY25" without ever stating the precise −4.5-point move a credit committee actually needs, and gives no natural place to catch an extraction error before it flows into the narrative. The chain forces the precise figure, forces an independent recompute, and forbids the final note from inventing a cause the source never stated.

Verification (Guardrail 1, Guardrail 3): performed at each checkpoint above, and not only at the end. Catching an error where it enters, before it propagates, is what the chain design buys you.

Read it. Three short prompts with two checkpoints did more real work than one long prompt would have, because each step had exactly one job and a defined place to catch an error before it propagated. If you cannot say in one sentence what a single prompt's one job is, it is a chain, not a prompt.

Worked example 4: Cascade Robotics Inc.: unmasking a manufactured confidence figure (US, $, synthetic)

Asked about Cascade Robotics Inc.'s (synthetic, US industrials) competitive position from a pasted competitor-comparison paragraph, a model answers: "Cascade Robotics has a durable moat based on switching costs, and I am 90% confident this assessment is correct."

Solution. The 90% is not evidence. Nothing in the prompt gave the model a way to compute a real probability that its own qualitative judgment is right, so the figure is generated text dressed as a statistic. Models' documented tendency toward uniform overconfidence means a stated 90% and a stated 60% carry roughly the same low weight until independently checked. A better prompt asks two things instead of a score: "(1) Which specific sentences in the pasted text support a 'switching costs' read: quote them. (2) What would you need to see that isn't in the pasted text to be more sure: name it specifically." A useful re-run answers: (1) quotes a sentence about long-term multi-year service contracts and proprietary calibration software; (2) names customer retention rate over the last 3–5 years and price increases accepted without switching as the two things it would want but does not have.

Verification (Guardrail 1, Guardrail 5: Cite): confirm the quoted sentence is real and says what it's claimed to (it does), and record exactly which named source you would need next: customer retention data, if it exists, comes from the company's own disclosures or a named industry dataset, never from asking the model again.

Read it. A bare confidence number invites false comfort; a named list of "what I don't have and would need" invites you to go get the one or two things that would actually move your judgment. The second is strictly more useful, and costs nothing but a slightly different question.

Worked example 5: Malabar Logistics Ltd: a structured extraction catches its own unit trap (India, ₹, synthetic)

Extracting a four-quarter working-capital note for Malabar Logistics Ltd (synthetic, India) into JSON with fields period and net_working_capital (unit: INR crore). Source: "Q1 net working capital stood at ₹42 crore… Q2 at ₹38 crore… Q3, working capital needs rose sharply to ₹3,90,00,000 on festive-season inventory build… Q4 eased to ₹45 crore."

Solution. A naive extraction might return Q3 as 39000000, sitting beside Q1/Q2/Q4's two-digit crore figures: an obvious scale break in the same column. Applying Guardrail 2 (Match): ₹3,90,00,000 in Indian digit-grouping is 3 crore 90 lakh, i.e., ₹3.9 crore, nowhere near either a bare 39 or a bare 39,000,000 reading. Recording it correctly as 3.9 reveals something odder still: ₹3.9 crore is a sharp fall from Q1/Q2's ~₹40 crore level, the opposite of what "rose sharply" in the source sentence claims. A number that contradicts its own sentence is itself the loudest possible red flag.

Verification (Guardrail 2, Guardrail 1): when the extracted figure and the sentence's own qualitative claim disagree, that disagreement is the finding. Treat the Q3 figure as unresolved and re-read the original filing page directly rather than guessing among "39," "3.9," or some other reading. No script and no fast skim resolves an internally contradictory sentence; only a human reading the actual source page does.

Read it. Indian lakh/crore grouping and Western thousand-grouping intuitions collide constantly in cross-border extraction work, and a model asked to fill a single "crore" column can silently pick the wrong reading. Never trust an extracted number in isolation: check it against the sentence's own qualitative claim and the neighboring periods, and when the two disagree, treat the disagreement as the signal, not a nuisance to smooth over.

Worked example 6: Union Square Retail Inc.: red-teaming a thesis catches a fabricated counter-fact (US, $, synthetic)

A draft thesis on Union Square Retail Inc. (synthetic, US) reads: "Private-label penetration grew from 18% to 27% of sales over three years, expanding gross margin by an estimated 260 basis points; we expect the trend to continue." Fed to the red-team-my-thesis pattern, an illustrative response returns three points. Point (1): private-label growth "typically slows past ~30% penetration in grocery/general retail", a linear-extrapolation risk worth checking against the last four quarters, not just the three-year average. Point (2) quotes a statistic of its own: "industry-wide private-label penetration reportedly fell to 24% last year amid a branded-goods promotional push," which undercuts the assumption that the trend is durable. And point (3): the 260-bps margin estimate is not shown as computed from the 18%→27% figures given, so check the assumed margin spread behind it.

Solution. Points (1) and (3) are usable as written: (1) correctly flags decelerating-growth risk as a general pattern worth a more current data cut, and (3) correctly flags an unshown Recompute step (Guardrail 3) you should have caught yourself. Point (2), though, cites an oddly precise statistic ("fell to 24% last year") that appears nowhere in the pasted thesis or notes. Per Guardrail 1 (Trace), that figure is unverified until it turns up in a named primary source: a trade-association report, a peer's own disclosure. If nothing turns it up, discard the number as likely fabricated. Keep the underlying question ("is industry-wide private-label penetration actually declining?") as legitimately worth checking for real, since a fabricated number can still be pointing at a real question.

Verification (Guardrail 1, Guardrail 5): trace point (2)'s figure to a named source or drop it, and record where you looked either way, so a reviewer can see the check happened.

Read it. Red-teaming your own thesis is genuinely valuable: points (1) and (3) here are exactly what a friendly first read tends to miss. But the pass is an idea-generator, not a truth-generator. Treat every counter-argument as a lead to check, never as a fact to cite.

Practice set

Work each problem before reading its solution. Companies and figures are illustrative/synthetic unless stated otherwise.

P1 (guided). Vague-to-RCTF rewrite. Rewrite this into a complete RCTF prompt: you have pasted a segment note and want a plain analyst read on which segment drove a margin change. Vague version: "Tell me about this company's margins."

Solution. Role: "You are a sell-side analyst preparing a note for a portfolio manager who has 90 seconds." Context: "Use only the segment note pasted below; no outside knowledge about this company." Task: "Identify which segment's margin moved the most year-on-year and state the single largest driver named in the note." Format: "One paragraph (≤120 words), then one line: 'Driver: <text>.'" The four elements are now unambiguous, unlike the vague version, which left audience, allowed material, the actual question, and the answer's shape all undefined: a model answering it could reasonably produce several different kinds of response, none provably wrong and none easy to check.

P2 (guided). Confidence-figure diagnosis. A model extracts a growth rate and adds, "I am 93% confident in this figure." A colleague wants to skip re-checking it because 93% sounds high. What do you say, and what should the prompt have asked for instead?

Solution. The 93% is generated text, not a calibrated statistic. The model has no real access to how often figures phrased this way turn out correct, and models run uniformly overconfident, so a high number carries no more evidentiary weight than a low one. The prompt should instead have asked the model to name which specific inputs it was not given directly (inferred, recalled, or estimated), producing a concrete checklist of what to verify first, and the growth rate itself still gets checked against the source table regardless of any number attached to it.

P3 (guided). Few-shot example design. A model must classify ten customer-renewal notes Low/Medium/High in a consistent style. Someone supplies one example where the answer is "High" and the reason is "late payment." Design a better few-shot set and explain the one-example risk.

Solution. One-example risk: the model may latch onto that example's incidental features (the label "High," or the specific reason "late payment") rather than the general judgment, over-predicting High or over-weighting late-payment language regardless of a new note's actual content. Better: three varied examples (one Low, one Medium, one High) with different companies, different reasons (late payment, a support-ticket spike, a champion departure), and different phrasing, so the only constant is the underlying judgment. State the rule too: "risk = likelihood of non-renewal in the next 90 days, based on the signals present in the note."

P4. Decomposition of a multi-part task. Break this into a 3-step chain with checkpoints: "Build a 3-year revenue and margin trend table from the pasted filings, flag any anomalous year, and write a 2-paragraph committee summary."

Solution. Step 1 (extract-a-table): produce the table from the filings only. Checkpoint: confirm every row against the source. Step 2: using the confirmed table, flag any year-over-year move past a stated threshold, citing the specific cells. Checkpoint: recompute the flagged move by hand. Step 3: using the confirmed table and confirmed flag, produce the 2-paragraph summary in an exact specified format. A single giant prompt risks shortchanging whichever item lands mid-list, and an unchecked chain risks an unnoticed Step-1 error flowing straight through to the committee's summary.

P5. JSON schema with null-handling. Write the Format instruction for extracting revenue, EBITDA margin, and a stated one-time item from a footnote, when the one-time item might not be mentioned in a given period.

Solution. {"period": "<FY label>", "revenue": <number or null>, "revenue_unit": "<e.g. INR crore>", "ebitda_margin_pct": <number or null>, "one_time_item": <string or null>}, with the explicit instruction: use null for any field not stated in the text for that period; do not estimate a one_time_item if none is named, and do not write "none" or 0 for margin: both quietly assert something the source never said. null is the only honest way to represent "not present in what I gave you."

P6. Pattern-matching exercise. Match each scenario to its best-fitting pattern and state that pattern's verification step: (i) a 400-word contingent-liabilities note needing a plain-English read; (ii) a one-page memo that needs checking before it reaches a manager; (iii) three paragraphs of MD&A prose containing quarterly figures; (iv) an "undervalued" conclusion about to be presented, needing the strongest case against it first.

Solution. (i) explain-this-filing-note: verify the explanation reaches for nothing outside the pasted note (Trace) and that any referenced standard is period-appropriate (Date-check). (ii) draft-then-critique: verify the highest-stakes flagged (or unflagged) claims independently; "no issues found" is not proof. (iii) extract-a-table: verify every cell's figure/unit/scale/period/entity against the prose (Match) and confirm no invented row (Trace). (iv) red-team-my-thesis: trace any counter-fact not in your pasted material to a primary source before treating it as real (Trace).

P7. Lost-in-the-middle fix. A learner pastes a six-page excerpt, then adds one line at the very end: "Only look at the retail segment and answer in a table." The model's answer mixes segments and returns prose. Diagnose and fix.

Solution. A short, late instruction after a very long paste gets under-weighted relative to the bulk of the context, so the model defaults to a generic full-document read. Fix: state the Task and Format both before the long paste and again after it: "Using ONLY the retail segment figures in the text below, produce a table with columns X, Y, Z. [paste]. Reminder: retail segment only, table format." The repetition is deliberate insurance, not redundancy.

P8. Leading-question fix. Neutralize: "Isn't it obvious that this segment's margin decline is temporary and will bounce back next year?"

Solution. The original presupposes the conclusion, priming agreement rather than analysis: a textbook sycophancy setup. Neutral version: "Based only on the pasted note, what does management state about the cause of the margin decline, and does the note itself call the cause temporary or structural? If the note doesn't say, state that explicitly rather than inferring an outlook." This asks what the text supports, not validation of a pre-decided view, and explicitly permits "it doesn't say."

P9. Recompute check on a derived figure. A model's extraction states: revenue = ₹840 crore, EBITDA = ₹176 crore, ebitda_margin_pct = 24.3. Check this.

Solution. 176 ÷ 840 = 0.2095 = 20.95%, not 24.3%: the stated margin does not recompute from the stated revenue and EBITDA, a Guardrail 3 (Recompute) failure whether from an arithmetic slip or a blended-in figure from another period. Corrected figure: 20.95% (≈21.0%). Always re-derive any ratio the model states from the raw figures it also gave you; never take the ratio on its own say-so.

P10. Fabricated counter-fact in a red-team pass. A red-team pass argues: "Industry-wide capacity utilization fell to 61% last quarter, undercutting your pricing-power assumption." Nothing about capacity utilization appears anywhere in your pasted thesis or notes. What do you do?

Solution. Treat the 61% as an unverified claim regardless of how specific and plausible it sounds: Guardrail 1 applies to a red-team pass's own output exactly as to any other claim. Find a named primary source for industry capacity utilization before deciding whether the counter-argument has weight; if none turns up that figure, discard it as fabricated, but keep the underlying question ("what is happening to industry capacity utilization?") as legitimately worth checking for real.

P11. Blind-critique structuring. Rewrite this draft-then-critique pair to reduce rubber-stamping: Pass 1 produces a memo and its own reasoning notes in one message; Pass 2, in the same conversation, is asked "do you see any issues with your answer above?"

Solution. Two problems: the same conversation (the critic can lean on its own prior reasoning) and a self-referential ask that invites self-defense more than review. Fix: run Pass 2 in a fresh conversation with no memory of Pass 1's reasoning; give it only the source material and the finished draft, not the drafter's working notes; instruct it as a third-party reviewer ("you did not write this; find what is wrong with it"); require a quoted sentence per issue rather than a general verdict.

P12. Outside-knowledge leak in explain-this-filing-note. An output for a pasted related-party-transactions note adds: "Companies in this sector typically disclose such transactions at arm's length, so this is likely standard practice." Diagnose.

Solution. This sentence uses outside, generic industry knowledge instead of anything stated in the pasted note: the exact failure this pattern exists to prevent, since "typically" smuggles in an unverified generalization dressed as an explanation of the text in front of you. Fix: reinforce the instruction ("use ONLY the text provided; if the note doesn't state whether the transaction was at arm's length, say so explicitly"), and treat any sentence containing "typically," "usually," or "companies like this" as a reliable tell that the model has left the pasted text (Guardrail 1).

P13. Unit/scale trap across a chained table. A four-year extraction returns unit_display: "INR crore" for every period, but one period's raw figure is 4,250,000 while the others are two-to-four-digit numbers like 840, 910, 1,050. What's the likely error and the fix?

Solution. The outlier is almost certainly reported in the source at a different scale (₹ lakh, or raw rupees) and was pasted into a "crore" column without conversion. Do not guess which conversion applies: return to the source page for that one period, read the unit actually printed there (Guardrail 2: Match), convert explicitly, and re-state the figure with its corrected unit shown alongside it, never silently.

P14. FY/CY mixing across a chain. Step 1 extracts figures labeled FY24/FY25; Step 3, several prompts later, refers to "2024" and "2025" without saying fiscal or calendar, and the final summary compares a partial calendar year to a full fiscal year. Identify the error class and where a checkpoint would have caught it.

Solution. A period-definition error (FY vs CY), treated exactly as seriously as a unit error in this program, crept in because a later step re-labeled the same data without carrying the original period definition forward. A checkpoint right after Step 1, requiring the exact period label (not a bare year number) to be carried verbatim through every later prompt, would have caught this before Step 3 ran. Any mid-chain relabeling of a period, currency, or scale is itself a checkpoint-worthy event, never a cosmetic rewording.

P15. Full pattern construction from scratch. Using explain-this-filing-note, write a complete RCTF prompt for a warranty-provision note from a synthetic US manufacturer's 10-K, and state the verification step.

Solution. Role: "You are a plain-English explainer restricted to the text provided; no outside knowledge about this company or industry." Context: "The warranty-provision note pasted below, plus the paragraph before and after it." Task: "(1) Explain what this note discloses and why a manufacturer carries this provision. (2) As a general pattern only, not a claim about this company, describe what it would look like if a warranty provision were being used to smooth earnings." Format: "One paragraph for (1); a 3–5 bullet list for (2); a final line: 'Based only on the text provided above.'" Verification: Guardrail 1 (confirm no fact about the company beyond the pasted note) and Guardrail 4 (confirm any standard referenced matches the filing's actual period).

P16. Reflection. In 2–3 sentences, explain why "the model sounds confident" is never sufficient evidence on its own, and name the one discipline every pattern in this library shares.

Solution. A model's fluency and confident tone are products of the same next-token-prediction process regardless of whether the content is right or wrong (AI0.01: it optimizes for plausible, not true). There is no visible difference in polish between a well-grounded answer and a smooth fabrication. The one shared discipline: every pattern in this library ends with a named verification step that traces the output back to a primary source or the pasted material; none of the four is complete without it, however good the output looks.

Applied mini-project

Build your own four-pattern prompt library. Pick one recurring task from your own analyst work (a weekly company-snapshot note, a monthly variance memo, a due-diligence checklist read, anything you do more than once a month), or, if you don't yet have real material you're allowed to use, adapt the six synthetic scenarios used here. For each of the four patterns (extract-a-table, explain-this-filing-note, draft-then-critique, red-team-my-thesis):

1. Write your own complete RCTF prompt for that pattern, with your own placeholders filled in for a specific task, not a bracket-swapped copy of the template above.
2. Run it in an AI tool of your choice, chosen honestly against AI0.02's evaluation rubric (what it is, what it's good/bad at, where the data goes, how to verify it, cost/offline).
3. Perform that pattern's own verification step by hand against a primary source (a real document you may use, or the synthetic excerpts used here) and record, in one or two sentences, what you found: confirmed as stated, needed a correction, or caught a fabrication.
4. Log any deviation the model made from exactly what you asked for: a missing field, an invented row, an ignored Format instruction, an uninvited assumption. If you genuinely find none, write down how you checked rather than simply noting "none found."

Deliverable. Four short write-ups (one per pattern): your prompt, a representative excerpt of the output, and your verification note, plus a closing 150–300 word reflection naming which pattern most changed how you'll work, and one specific, concrete way you will adapt it next time (not general praise).

Rubric (self-score; pass at 8/10, no zero on any line):

• (a) All four RCTF prompts are complete and clearly your own: Role/Context/Task/Format each identifiable and adapted to a specific task, not a bare template copy. 2 pts
• (b) Each pattern's own verification step was actually performed and the result recorded, for all four patterns. 2 pts
• (c) At least one genuine model deviation is caught and logged in writing, or an explicit, specific note of what was checked if none occurred. 2 pts
• (d) At least one write-up uses real material, or an honest note that only synthetic material was available and why. 2 pts
• (e) The reflection names one specific, concrete adaptation for next use, not a generic statement. 2 pts

Reading & resources

Primary technique guides (free, current at time of writing):

• Anthropic, "Prompt engineering overview" (docs.anthropic.com) and the interactive prompt-engineering tutorial (github.com/anthropics/prompt-eng-interactive-tutorial): a hands-on walk-through of RCTF-adjacent structure, including a financial-services exercise. [Free] [Beginner–Intermediate]
• OpenAI, "Prompt engineering" guide (platform.openai.com/docs/guides) and the OpenAI Cookbook: task-oriented worked patterns, including structured-output specifications. [Free] [Intermediate]
• Google's Gemini prompting guide, and DeepLearning.AI × Andrew Ng's short course "ChatGPT Prompt Engineering for Developers": a fast, example-led primer covering few-shot and structured output. [Free] [Beginner–Intermediate]

Going deeper:

• Vanderbilt University's "Prompt Engineering" specialization (Coursera): the most thorough single treatment of advanced patterns, including chaining and self-critique framings. Free to audit; paid for a certificate. [Free-audit / Paid-certificate] [Intermediate–Advanced]

(As of 2026-07, verify current: provider documentation URLs and exact course names shift with product changes. The technique names (RCTF-style framing, few-shot, decomposition, structured output) are the durable content here and will outlast any specific guide's current title or address.)

Every pattern in this library is a template you have to run yourself, not a spell that works on its own. The only way any of it sticks is running your own real (or realistic) task through it, catching what the model got wrong, and writing down what you'd change next time. Before AI0.04 asks you to chat with an actual filing, spend at least one working session running your own draft prompt-pattern library end to end.

Teach it back & journal

Feynman prompt. Explain to a colleague who has only ever typed "summarize this" into a chat window why a well-structured prompt is not about being polite to the model or using fancier words. It is about turning an unanswerable question into a checkable one. Use Worked Example 1 (Sahyadri FoodWorks): show them the vague prompt, the RCTF prompt, and ask them to predict which one would let a reviewer catch a wrong answer in ten seconds. If they can explain, unprompted, why Format is doing as much work as Task in that comparison, you understand the deepest idea here.

Journal prompt. Pick one AI interaction from the last week where the output disappointed you (vague, generic, wrong, or unverifiable). Rewrite the prompt you actually used into full RCTF, decide which of the four analyst patterns (if any) it should have been, and name the specific verification step you skipped the first time. Then write a paragraph on this: every one of the four patterns ends the same way, with a named check against a primary source. Which pattern do you reach for most in your own work, and what is the one habit (stating Format explicitly, using 2-3 varied few-shot examples, inserting a chain checkpoint, or tracing every citation) that would most change the reliability of your own AI use this month?

This module's flashcards and mastery quiz are wired into the app: see the node's Quiz and Reviews.