You already use AI. Maybe it drafts your inbox replies. Maybe it writes your notes while you talk. Maybe it is just the chatbot you quietly ask when a presentation does not fit the illness script. Either way, the technology arrived in your workflow before anyone trained you on it.

Think about how you learned every other tool you trust. Ultrasound came with a course. The ventilator came with supervision. Even the EHR, for all its flaws, came with onboarding. AI came with a login.

This book is the onboarding that never happened.

It is not a textbook. Textbooks about AI are outdated before the ink dries, and this field changes monthly. It is not vendor material. Nobody selling you a tool will lead with how it fails, and how it fails is exactly what you need to know first. Every clinical application in this book ends the same way: how this breaks in the wild, and what the break costs.

You do not need to learn to code. You need four competencies, and you already use all four every shift. Deciding what to hand off and what to keep: you do that every time you assign a task to a resident. Communicating exactly what you want: every consult you have ever called. Judging what comes back: every result you have ever interpreted. Owning the outcome: every note you have ever signed. This book calls them Delegation, Description, Discernment, and Diligence. They are the spine of everything that follows.

The book is organized by yield, not by topic hierarchy. HY-3 concepts will cost you something this week. HY-2, this quarter. HY-1 is context, not crisis. If you have one hour, read the HY-3 spreads and stop. They are marked.

Read it front to back once. It is short on purpose. After that it is a reference: the spread you need, the week you need it.

The tools will keep changing. The four competencies will not. Learn the spine, and every new tool is just a new rotation.

The Map

Six sections, in dependency order.

Getting Started. You are here. Three spreads, then you are oriented.

Substrate. How the technology actually works, in five spreads, none of which require math. This is the pathophysiology. Skip it and the rest of the book becomes rules you memorized instead of behavior you can predict.

The 4D Core. The operating framework. Twelve spreads across four decisions: Delegation (what to hand off), Description (how to ask), Discernment (how to judge what comes back), Diligence (owning the result). This is the spine.

Legal. PHI, HIPAA, liability, consent, FERPA. Short, because the rules are short. The consequences are not.

Clinical Applications. The tools already in your hospital: scribes, decision support, sepsis models, patient chatbots, inbox drafting. Each one gets the same treatment, including the part the vendor left out.

The Builder Track. For when using and configuring stop being enough. Whether to build at all, then memory, skills, and tools, and the evals that catch what you built when it quietly breaks.

After the six sections, a short Glossary sits as back matter — not a spread, just a lookup for the vendor and IT terms nobody stops to define.

The Spread Anatomy

Every spread follows the same shape. Learn it once, navigate by it forever.

1. Title + yield badge.
2. Bottom line. One sentence. The whole spread compressed. If you stop here, you still got the point.
3. The concept. Plain language. Any jargon gets defined in the same sentence it appears.
4. Clinical anchor. One scenario from the ED, the clinic, or the inbox. Concrete.
5. What to do. The protocol.
6. How it fails. On every spread, no exceptions. The failure mode in the wild and what it costs.
7. Cross-refs. Where to go next.

The Yield System

HY-3 will cost you something this week. These are the spreads where the failure mode is already in your workflow today, whether you have noticed or not.

HY-2 will cost you something this quarter. Important, not urgent.

HY-1 is context. It makes the HY-3 and HY-2 material make sense, but it will not hurt you on its own.

If you have one hour: read every HY-3 spread, front to back, and stop. That is a complete, defensible baseline.

How It Fails

Readers treat this book like a textbook: read once, shelve, trust memory. That works for anatomy. It does not work for a field that ships updates monthly. The tools described here will change. The failure modes are more durable than the features, which is why the failure modes are the organizing principle. When a spread and reality disagree, check the version number on the cover against the changelog, then trust reality.

The Concept

That sentence is the whole technology. Five minutes to unpack it.

It predicts. A large language model is a pattern completion engine trained on enormous amounts of text. Given everything written so far, it produces the most plausible next word, then the next, then the next. There is no database lookup, no reasoning module, no fact checker underneath. When the output reads like thinking, the model is predicting what thinking looks like in text.

It only sees the window. The model works inside a context window: the block of text it can see at this moment. Your prompt, the conversation so far, any documents you attached. That is the entire universe. It has no memory of your last session, no knowledge of your patient, no access to your hospital's protocols unless those things are in the window right now.

Plausible is not the same as true. Because the engine is prediction, the output is always fluent and always confident. A correct answer and a fabricated one arrive in identical prose. Confidence is a property of the text, not evidence about accuracy.

You hold one lever. You cannot reach into the model. The only control surface is the input: what you put in the window and how you ask. Input quality determines output quality. Fully.

That is the model. Everything else in this book is the clinical application of those four facts.

Clinical Anchor

What To Do

1. Before you ask, ask yourself: is everything the model needs in the window? If you have not provided it, the model does not have it.
2. Treat fluency as zero evidence. Judge the output the way you judge a test result, not the way you judge a colleague's tone of voice.
3. When output disappoints, fix the input first. It is the only lever you have, and it is usually the problem.

How It Fails

Clinicians map the chatbot onto things they already trust: a search engine, a reference text, a colleague. It is none of these. A search engine retrieves. A reference is curated. A colleague knows when to say "I'm not sure." The model predicts, always, with the same confidence, whether the window holds everything or nothing. The cost of the wrong mental model is misplaced trust, and misplaced trust is the root of nearly every failure mode in this book.

The Concept

There are four things to understand. Everything else is a named pattern built from these.

Prediction. The model's only job is to predict the most likely next token given everything before it. There is no reasoning engine, no database, no logic system underneath. It is extraordinarily sophisticated pattern completion over language. When it seems to think, it is predicting what thinking looks like in text.

Context. The model exists entirely inside a context window: the block of text it can see at any given moment. It has no memory between sessions. It does not know your patient, your institution, or your last conversation unless you put that information in front of it. The context window is the room. Everything the model knows is whatever is currently in the room.

Tokens. Everything is broken into tokens, roughly three-quarters of a word each. All cost, speed, and capacity limits are denominated in tokens. Token limits are the reason you cannot paste an entire chart and expect a complete summary.

Prompt. You have no access to the model's internals. The only surface you can touch is what you put in front of it. Instructions, examples, context, constraints: all of it is prompt. Input quality determines output quality, fully and without exception.

Clinical Anchor

What To Do

When an output disappoints, run through the four primitives before blaming the tool:

1. Prediction problem? The task may be outside what pattern completion can reliably do. Judgment calls, novel synthesis, and decisions requiring facts the model was never trained on are prediction-limited.
2. Context problem? Is the relevant information actually in the window? If you did not put it there, it is not there.
3. Token problem? Is the input too long, the output getting cut off, or the window too small? Trim the input or break the task.
4. Prompt problem? Are the instructions specific? Is the output format defined? Are there examples? Vague input produces confident, generic output.

Most failures are context problems. Knowing this is worth knowing.

How It Fails

Clinicians assume the model knows things it cannot know. They ask about their patient without describing the patient. They ask about their hospital's protocol without providing it. They ask follow-up questions as if the model remembers the last session. It does not. The output arrives fluent and confident either way. Fluency carries no information about accuracy. The model predicts what a correct-sounding answer looks like, not whether the answer is correct. This is not a flaw to be patched in the next version. It is the mechanism.

The Concept

The industry calls it hallucination. The better clinical word is confabulation: confident, coherent, fabricated detail produced without any awareness of the fabrication. Like a Korsakoff patient telling you about the breakfast he did not eat, the model is not deceiving you. It is completing a pattern.

The mechanism matters. The model generates the most plausible next word given the window. When the true answer was common in its training data, the most plausible continuation is usually also the correct one. When the true answer is rare, absent, or specific to your patient, the model does not stop. It cannot stop. It produces what a correct answer would look like: a citation with a real journal name and a fabricated page range, a drug interaction that sounds right, a statistic with one decimal place of false precision.

The output quality is identical in both cases. That is the trap. There is no change in tone, no hedge, no flag. The fabricated citation is formatted exactly like the real one because both were produced by the same process: predicting what citations look like.

Confabulation concentrates at the edges. Common knowledge is reproduced reliably. Specifics fail first: exact doses, exact citations, exact numbers, recent events, rare diseases, your institution's protocols.

Grounding reduces it, nothing eliminates it. Giving the model the source document to work from (see D7) cuts fabrication sharply, because the right answer is now in the window. It does not cut it to zero.

Clinical Anchor

What To Do

1. Verify every fact the model produced that you did not supply. Citations, numbers, doses, named studies. Every one, not a sample.
2. Expect fabrication where specifics meet rarity. The more precise and less common the claim, the higher the prior that it is confabulated.
3. Ground when you can. If a source document exists, put it in the window and ask the model to answer from it.
4. Never use absence of hedging as reassurance. The model hedges when hedging is the plausible pattern, not when it is uncertain.

How It Fails

Clinicians learn about hallucination, catch one fake citation early, and conclude they can spot them. They cannot, and neither can anyone else, because there is nothing to spot. The fabrication is constructed from the same patterns as the truth. Detection by inspection fails by design. The only reliable detector is checking the claim against something real. The cost of believing you have a feel for it is the fourth citation, the one you did not check, in the manuscript with your name on it.

The Concept

A model learns during training, once, on a fixed corpus of text. After that, its weights are frozen. Using the model does not teach it anything. Your conversations do not update it. The next version of the model is a new training run, not your model having learned.

Three properties of that snapshot matter clinically.

It has a date. Every model has a knowledge cutoff, typically six to eighteen months before you are using it. A guideline revised after the cutoff does not exist for the model, and the model will not tell you that. Asked about current recommendations, it confidently produces the recommendations that were current when its data ended.

It is uneven. The training corpus is the internet plus licensed text. Common conditions, US-centric practice, and well-published topics are densely represented. Rare diseases, local practice patterns, and non-English literature are thin. Where the data is thin, prediction degrades and confabulation rises. The model's competence map does not match the textbook's table of contents, and there is no legend telling you which regions are thin.

It absorbed the disagreements. The corpus contains contradicting guidelines, outdated practices, and confident wrong answers. On settled questions, the average is fine. On contested ones, you can get either side of the argument depending on how you phrase the question.

The fix for all three is the same: anything time-sensitive, local, or contested goes in the window. Current guideline, your protocol, the actual paper. The window overrides the snapshot.

Clinical Anchor

What To Do

1. Know the cutoff of the tools you use, the way you know a reference book's edition year.
2. For anything guideline-driven, supply the guideline. Do not ask the model what is current; tell it what is current and ask it to apply it.
3. Treat rare-disease and niche-topic output with a higher index of suspicion. Thin training data is where fabrication concentrates.
4. Remember the model does not learn from you. The correction you gave it yesterday is gone. If a correction must persist, it belongs in your standing instructions (D6).

How It Fails

The failure is silent staleness. The model never says "my information may be outdated" unless that phrase happens to be the plausible pattern, and a stale answer reads exactly like a current one. Clinicians who would never quote a 2019 guideline will accept a chatbot answer without asking what edition it was trained on. The cost arrives when practice has moved and the model has not, on exactly the kind of question where you reached for the tool because you had not kept up either.

The Concept

Almost no clinical AI product is a model. It is a wrapper around one: a layer of software that takes your input, adds its own instructions and context, sends the package to a general-purpose model, and formats what comes back.

What the wrapper controls is exactly the list of things that determine output quality.

The hidden instructions. Every product front-loads the window with a system prompt you never see: the tone, the guardrails, the format, the things it refuses to do. Two products on the same model behave differently because their hidden instructions differ.

The context plumbing. The wrapper decides what else enters the window: the transcript from the room mic, the last three messages of the patient thread, a retrieved chunk of your formulary. When a product "knows" something, the wrapper put it there.

The model behind the curtain. Vendors swap underlying models for cost or capability, often silently. The product that performed one way in the demo may be running different machinery by go-live, or by next quarter.

The update cadence. Wrapper updates change behavior too: a new feature, a new default, a reworded hidden prompt. The tool you validated is a moving target.

None of this is scandal. It is how the industry works. But it means your trust should attach to a product version at a point in time, not to a brand name. A vendor who cannot answer "what model is this and what gets sent to it" has told you something.

Clinical Anchor

What To Do

1. For any tool touching patient care, find out what it sends, where, and to which model. This belongs in procurement questions, not fine print.
2. Date your trust. "This tool was reliable on my cases as of version X" is a real statement. "This tool is reliable" is not.
3. Watch for behavior drift after updates, and treat drift as a signal to re-verify, not a quirk to ignore.
4. When a tool behaves strangely, remember you can only see your input, not the full window. The hidden instructions may be fighting your request.

How It Fails

Trust gets attached to the brand and then auto-renews. The tool earned confidence in month one, and that confidence silently extends across model swaps, prompt rewrites, and feature changes, none of which were announced in any channel a clinician reads. The cost is a validated workflow that is no longer the workflow you validated, discovered only when the output quality drops far enough to be visible, which is far past where it started to matter.

The Concept

Prediction does not mean picking one fixed answer. At every word, the model holds a probability distribution over what comes next, and most products sample from it. A setting called temperature controls how adventurous the sampling is. You usually cannot see or set it in clinical products.

The consequence: the same prompt, run twice, can produce different outputs. Usually the differences are cosmetic. Sometimes they are not. A borderline judgment call can land on different sides on different runs, because the underlying distribution was genuinely split and the sampler broke the tie differently each time.

Three clinical implications:

A single output is a single draw. You saw one sample from a distribution, not the model's verdict. If the question is consequential and the answer surprising, asking again is cheap and informative. Wide variation across runs is the closest thing the model has to telling you it is uncertain.

Reproducibility is not guaranteed. The output you verified yesterday is not binding on the output generated today, even with an identical prompt.

Variation compounds with everything else that moves. Sampling variability sits on top of model swaps and wrapper updates. A workflow can drift for three different reasons that all look the same from the outside.

The mitigation is structural. Templates, standing instructions, and grounding documents narrow the distribution by constraining the window. The tighter the input, the less room the sampler has to wander.

Clinical Anchor

What To Do

1. For consequential, borderline questions, run the prompt more than once. Agreement across runs is mild reassurance; disagreement is a flag that the question is underdetermined or contested.
2. Never cite a single chatbot output as "the AI's answer" in a clinical discussion. It is one sample.
3. For anything you reuse, freeze the output, not the prompt. Verify a specific text once and save that text. Regenerating is re-rolling.
4. Constrain when consistency matters: templates, examples, source documents in the window.

How It Fails

The failure is treating the model as an oracle with one answer per question. A clinician verifies an output, trusts the prompt that produced it, and shares the prompt with colleagues as if it were the verified artifact. Each colleague now generates their own unverified draw and attributes the original verification to it. The cost is a department full of people who believe they are using a vetted tool, holding outputs nobody vetted.

The Concept

When you hand a task to AI, you are making four consecutive decisions whether you realize it or not.

Delegation. Should this go to AI at all, and in which mode? Not every task belongs there. Of the ones that do, some should be automated with verification, some require you and the model working together, and some should never run without you in the loop at every step.

Description. What exactly are you asking for, and does the model have everything it needs to do it? This is the prompt, plus the context behind it. Most clinicians start here. It is the third most important decision.

Discernment. Is what came back actually correct? Fluent is not accurate. Complete-looking is not complete. Appropriate for a generic patient is not appropriate for yours.

Diligence. You own the output the moment you use it. Verification scales with stakes. Your name on a document means you are accountable for every sentence in it, regardless of who or what drafted it.

The three modes of delegation:

• Automation. AI does it, you verify. Fast, appropriate for low-stakes reversible tasks.
• Augmentation. You and AI iterate together. Right for anything patient-facing or clinically consequential.
• Agency. AI acts in loops on your behalf with minimal check-ins. Earned, never assumed. Reserved for tasks you understand deeply enough to audit at any point.

Mode determines how much scrutiny the other three Ds require. Pick the wrong mode and the rest of the framework fails.

Clinical Anchor

What To Do

Before you open the tool, answer two questions:

1. Can I verify this output against something real?
2. Do I own the consequence if it is wrong?

If both answers are yes, you are in the right place. Now pick your mode. Patient-facing clinical content defaults to augmentation until you have characterized how the tool performs on your patient population.

When you prompt, put the patient in the window. Not the generic patient. This one: age, relevant history, the actual follow-up plan that exists, the thing they need to understand to stay safe.

How It Fails

Clinicians treat Description as the whole framework. They learn to write better prompts and assume that solves the problem. It improves the output. It does not replace the other three decisions. The published AI harms in medicine are not mostly prompting failures. They are Delegation failures (wrong mode, wrong task) and Diligence failures (signed without verification). The prompt was often fine. The decision around it was not.

The Concept

Delegation is the first decision and the one most often skipped. The tool is open, the task is annoying, so the task goes in. That is not a decision. That is a reflex.

What models do well maps to a short list: transformation (this format into that format), summarization, drafting, pattern recall, translation between registers. The common thread is that the source material exists and the output can be checked against it.

What you keep is non-negotiable: final clinical judgment, anything you cannot verify, anything you would not sign.

The screen is two questions.

Can I verify this output against something real? Not "does it look right." Verify, against the chart, the source document, your own knowledge, a reference. If no ground truth exists for you to check against, you cannot discern (D8), which means errors pass through you untouched. A task you cannot verify is a task you cannot delegate, no matter how good the tool is.

Do I own the consequence if it is wrong? If yes, the task can still go to the model, but the verification burden is yours and it scales with the stakes (D2). If you are tempted to delegate specifically because you do not want to own the output, stop. That is the clearest contraindication there is.

The screen sorts by verifiability, not difficulty. Some easy-feeling tasks fail the screen. Some hard-feeling ones pass.

Clinical Anchor

What To Do

1. Run the two-question screen before you open the window: can I verify it, do I own it.
2. If you cannot verify, do not delegate the answer. You can still delegate the legwork around it: summarize the relevant guideline you provide, draft the consult question. Keep the judgment.
3. If the reason you want to delegate is fatigue with the consequence, treat that as a red flag, not a use case.
4. Passed the screen? Now pick the mode (automation, augmentation, agency) using stakes and reversibility (D2).

How It Fails

The dangerous tasks are the ones that feel verifiable but are not. A summary of a chart you have not read feels checkable; checking it requires reading the chart, which is the work you delegated away. Fluent output masks unverifiable content, and "I would have caught it" goes untested because nothing forces the catch. The cost is errors that read as polished, passing through a clinician who believed they were the safety check while doing none of the checking.

The Concept

Once a task passes the delegation screen (D1), the question becomes how much supervision it runs under. Two axes answer it.

Stakes. Who gets hurt if this is wrong, and how badly? Internal scaffolding sits low. Anything patient-facing sits high, automatically.

Reversibility. Is the output a draft you will review before it becomes real, or a committed action? A drafted message is reversible until sent. A sent message, a signed note, an order placed: committed.

Cross them and the modes assign themselves:

• Low stakes, reversible: automation. Let the model run, verify on review. This is where the time savings live.
• High stakes, reversible: augmentation. You and the model iterate; the draft never becomes real without your full review. Patient-facing content lives here.
• Low stakes, committed: automation with a sampling audit. Fine until volume makes errors compound.
• High stakes, committed: the danger quadrant. If an AI output becomes a committed, patient-affecting action without a human between draft and commitment, you have built a machine that acts in your name without you. Augmentation only, full verification, or do not do it at all.

Tasks move. Re-run the grid when anything changes, especially the tool itself.

Clinical Anchor

What To Do

1. Place the task on the grid before picking a mode. Two questions: who gets hurt, and is there a review between output and reality?
2. Default patient-facing content to augmentation, regardless of how reliable the tool has been.
3. Audit your committed-action surfaces. List every place an AI output can become real without your eyes on it. That list should be short, deliberate, and known to you.
4. Re-run the grid after every tool update. Read the release notes for one thing only: did anything move from draft to auto?

How It Fails

Tools quietly move your tasks between quadrants. A draft feature becomes an auto-send feature in an update. A suggestion becomes a default. A default becomes an action. Each step ships as convenience, each is individually small, and the sum is a committed pipeline where there used to be a checkpoint. The cost is a committed action you never reviewed, discovered after it reached a patient, with your name attached because the toggle was in your settings.

The Concept

A prompt is a one-off conversation. A pipeline is a saved, repeatable workflow: the same instructions, the same input format, the same checks, run every time the task comes around. The third time you find yourself reconstructing the same prompt from memory, you have found a pipeline candidate.

The upgrade buys three things: consistency (the prompt that worked is frozen), quality (you tune the instructions once, properly), and a defined verification point (the pipeline has one step, named in advance, where a human checks output against ground truth).

The agentic version goes further. An agent runs a loop: plan the step, act, observe the result, feed it back into the window, repeat. Understand what the loop does to error: each cycle's output becomes the next cycle's input. A small mistake in step two is the foundation everything after it was built on. Loops amplify whatever they are given.

Clinical Anchor

What To Do

1. Apply the rule of three: third recurrence, save it as a pipeline. Write the prompt down, fix the input format, store both where you will find them.
2. Name the verification step when you build it, not after. Decide what gets checked against what, every run.
3. Schedule re-validation. Monthly pipelines get a quarterly deep check against ground truth.
4. Before granting any tool an agentic loop, ask whether you could audit it mid-run. If you cannot tell a healthy run from a sick one, you are not ready to delegate the loop.

How It Fails

Pipelines fail by succeeding. The workflow runs clean for six months, the verification step starts feeling like ritual, and it gets skipped. Then a model update or a source change degrades the output, silently, and nobody is watching a thing that "already works." The cost is weeks of bad numbers with your name on them, discovered from the audience, not from you.

The Concept

The model has no memory of your patient, your last session, or your institution. It does not know what specialty you practice, what your formulary covers, or what you meant yesterday. The context window is the whole universe: your prompt, the conversation so far, whatever you attached. If a fact is not in the window, for the purposes of this output, the fact does not exist.

Clinicians find this hard to internalize because every other entity they consult has standing context. The pharmacist knows the formulary. The consultant can pull up the chart. The colleague remembers last week. The model has none of that, every single time, and gives no sign of the absence. Asked a question with missing context, it does not say "I'd need to know her creatinine." It assumes a creatinine, silently, and answers for the patient it assumed.

The skill is context engineering: deciding what goes in the window. Four components, every time:

• The question. What you actually want, stated as the thing it is.
• The relevant facts. This patient, not the generic one. The values, the history, the constraints of the real situation.
• The constraints. What must be true of the answer: reading level, formulary, your institution's pathway, what to do when uncertain.
• The format. What the output should look like.

Context engineering is selection in both directions: putting in what matters, leaving out what does not. More context is not always better context. Information buried in the middle of a long context window is processed less reliably. Generic out usually means generic in, but a chart dump fails for the opposite reason.

Clinical Anchor

What To Do

1. Before sending, audit the window: could a brilliant stranger answer correctly with only what is on this screen? If not, the gap becomes an assumption in the output.
2. Load the four components: question, relevant facts, constraints, format.
3. Select, do not dump. The relevant labs, not the chart. The pathway section that applies, not the binder.
4. Start a fresh session when the topic changes. A long conversation full of dead ends is a heavy window.
5. When output goes generic, fix the window before blaming the model. Generic out usually means generic in.

How It Fails

You assume it remembers. It does not. The clinician who described the patient thoroughly on Tuesday asks a follow-up on Wednesday, in a new session, and gets an answer for nobody. Or the same failure inside one session: the conversation drifted long, the early details fell out of the window, and the model is now answering from a digest it never announced it was making. The cost is the same: advice generated for a generic patient, applied to yours.

The Concept

You have been trained in exactly this skill. A good consult request names who you are, who the patient is, what you need, and by when. A bad one is "patient in 12, can you take a look?" The consultant's quality matters less than the quality of the question, and every clinician learns this in the first month of residency.

A prompt is a consult to a colleague with two specific impairments: total amnesia and no access to the chart. Structure the call accordingly. Five parts:

• Role. Who the model should be: "You are reviewing this as an EM attending writing for a patient with a sixth-grade reading level." Role sets register, depth, and what gets assumed versus explained.
• Context. The patient, the situation, the documents. Everything from D4. This is the bulk of a good prompt.
• Task. The specific ask, as a verb: draft, compare, extract, translate, critique. "Thoughts on this?" is not a task. Consultants hate that question and the model handles it worse.
• Constraints. The hard rules: formulary, length, reading level, what to exclude, what to do with uncertainty ("if information is missing, ask rather than assume").
• Output format. What the deliverable looks like: a table with these columns, a paragraph for the chart, a list ordered by urgency.

Two principles govern all five. Specificity beats length: ten precise lines outperform forty vague ones. And examples beat adjectives: "warm but direct, like this: [example]" outperforms three sentences describing the tone you want.

Clinical Anchor

What To Do

1. Build the prompt in five parts: role, context, task, constraints, format. Out loud or on the screen, same order every time, until it is automatic.
2. Replace adjectives with examples wherever output quality matters. One sample of the format you want is worth a paragraph describing it.
3. Add the uncertainty constraint to anything clinical: "if you are missing information you need, ask me instead of assuming."
4. Read your prompt back as if you were the consultant receiving it. If you would page back with questions, the model needed those answers too.

How It Fails

Vague prompts return confident, generic answers, and the confidence gets mistaken for quality. The clinician gets a fluent reply to a lazy prompt, concludes the tool works fine, and never learns what the strong version would have produced. There is no error message for a weak consult. The cost is generic medicine dressed as tailored advice, delivered to a specific patient, indefinitely.

The Concept

Every serious AI tool has a place for persistent instructions: custom instructions in the chatbot, project files, system prompts. Whatever the name, the mechanism is the same. The contents get loaded into the context window at the start of every session, before you type anything. It is the one exception to "the model remembers nothing": not memory, but a protocol sheet taped to the inside of the door.

Three categories belong in the file:

• Your role. Who you are, what you practice, who you write for. "EM attending, academic site, writes patient materials at a sixth-grade level." Every output calibrates against this without being told.
• Your defaults. Format and style preferences: concise over thorough, tables for comparisons, generic drug names, US units.
• Your hard rules. The non-negotiables: never include patient identifiers, flag uncertainty explicitly instead of guessing, cite a source or say there is none, ask before assuming missing clinical values.

The payoff is consistency under fatigue. At hour ten of a shift you will not remember to add "flag your uncertainty" to a prompt. The file does not get tired. Keep it short: a page of rules you mean beats five pages of rules you copied.

Clinical Anchor

What To Do

1. Watch your own prompts for a week. Anything you type more than twice goes in the file.
2. Write three sections: role, defaults, hard rules. Keep it under a page.
3. Write safety rules in imperative, testable language. "Flag uncertainty with [VERIFY]" is enforceable. "Be careful about accuracy" is decoration.
4. Test the rules on purpose. Paste a fake identifier, ask an underdetermined question, and watch what happens.
5. Re-read the file quarterly. Your defaults drift, and stale instructions conflict with new habits.

How It Fails

Instructions silently conflict with a specific request, and the model picks one without telling you. Worse, a sufficiently insistent prompt can override "always flag uncertainty," and nothing announces the override. The cost is a rule you thought was enforced, was not, discovered only when the output it should have caught gets through. Standing orders reduce reliance on vigilance. They do not retire it.

The Concept

By default, the model answers from its training snapshot: vast, stale, and uneven (F3). Grounding changes the source. You put the authoritative document in the window and the model answers from that.

The manual version you already know: attach the guideline, ask the question about the guideline. The automated version is RAG, retrieval-augmented generation. A retrieval step searches your document library for passages relevant to your question, injects the best matches into the context window, and the model answers from what was injected.

Why it works: confabulation is prediction without grounding (F2). When the correct answer is sitting in the window, the most plausible continuation is overwhelmingly the text that is actually there. Fabrication drops sharply. Recency solves itself, because the document is as current as you keep it.

But grounding does not give the model loyalty to the source. If retrieval pulls the wrong document, an outdated version, or nothing at all, the model answers anyway from training memory, in exactly the same voice. Grounded and ungrounded answers are indistinguishable on the surface.

Clinical Anchor

What To Do

1. For any question with an authoritative source, ground it. Attach the document; do not trust memory, the model's or yours.
2. Instruct the citation discipline: "answer only from the attached document, quote the relevant section, and say so explicitly if it does not cover the question."
3. Spot-check the quotes. A quoted passage you can find in the source in ten seconds is the cheapest verification in this book.
4. Curate the library. Retrieval is only as good as what it retrieves from: one current version of each document, old versions deleted.
5. When a grounded tool answers something your documents do not cover, treat that as an alarm. Something answered, and it was not your library.

How It Fails

Retrieval pulls the wrong document, the outdated version, or nothing, and the model answers anyway from training memory without flagging the switch. The 2022 pathway that never got deleted from the library is the canonical case: retrieval found it, the model quoted it faithfully, and the output cites a source, your source, lending institutional authority to a recommendation your institution retired. The system's credibility makes the error harder to catch than a bare chatbot's would have been.

The Concept

The model does not know what it does not know. More precisely: it has no way to flag that a critical piece of context was missing, because from its position, the context window was complete. It had everything you gave it. It answered accordingly.

The harder failure is context blindness. The model answered correctly for a patient it assumed. That patient was not yours. The output looks right because it is right, for someone. Discernment is the work of determining whether that someone is the patient in front of you.

Clinical Anchor

What To Do

Three moves, in order.

1. Verify everything you did not provide. Every number, every dose, every named fact the model generated without you supplying it first. Not sampled. Every one. The model's confidence carries zero information about accuracy.
2. When the output doesn't match your expectation, say so. Give the model your reasoning and ask where it diverged from yours: "I would have dosed this at X given her renal function. What did you assume, and does that change your answer?" The model will usually surface exactly what it was missing.
3. Calibrate over time. Track how the tool performs on your actual cases. A tool that performs well on general medicine prompts may perform differently on your patient population. You will not know until you have checked enough outputs against enough ground truth.

How It Fails

Verification gets sampled. The first few outputs were right, so the checking becomes lighter. Volume compounds this. The other failure is subtler: clinicians interrogate the model only when the output surprises them. If the output matches their prior, they move on. But the cases where the model's assumption aligns with yours are exactly the cases where shared blindness is possible. You both assumed the same wrong thing. Neither flagged it. Discernment is not a feeling that something looks right. It is a check against something real.

The Concept

Clinicians quit AI tools at exactly the wrong moment: after the first mediocre output. The first output was never going to be the deliverable. It is diagnostic information about what your instructions failed to convey, and reading it that way is the core operating skill.

The loop is describe, judge, re-describe. What separates skilled iteration from flailing is knowing what to change, and the order is fixed because the failure rates are not equal.

Context first. Most misses are context misses (D4). The output is generic, or it answered for the wrong patient. Fix: put the missing facts in the window. Not a rephrase. Facts.

Task framing second. The model did the wrong job well: you wanted a critique and got a summary. Fix: restate the task as a sharper verb with a clearer deliverable (D5).

Constraints last. Right job, right patient, wrong shape: too long, wrong register, buried lead. Fix: add the specific constraint with an example.

Know the stop rule: three iterations without convergence is not a prompting problem. It means the task was mis-delegated. Stop polishing. Go back to D1 and re-triage.

Clinical Anchor

What To Do

1. Read a bad output as a differential, in order: missing context, wrong task framing, missing constraints. Fix the one you find, not all three at once.
2. Make corrections specific and concrete. Name what was wrong and what right looks like.
3. Count your iterations. At three without convergence, stop and re-run the delegation screen (D1).
4. When an output is wrong in a surprising way, interrogate before re-rolling: "what did you assume about X?" The answer usually names the missing context.

How It Fails

Iteration becomes negotiation. You came in with a plan, the output disagrees, and you keep regenerating until the model produces the answer you already had. With enough iterations it always will; it is a prediction engine, and your increasingly leading prompts are the pattern it completes. The cost is the model converted into a yes-machine: a fluent second opinion that is actually your first opinion in a different font, now carrying the false weight of independent confirmation.

The Concept

Diligence reduces to one rule, and the rule was not invented for AI. You have always been accountable for what you sign. The intern's note, the templated macro, the dictation you skimmed: your signature has always meant "I stand behind this." AI changes only the volume and the polish of what arrives for signing, and both changes push in the dangerous direction.

"Human-in-the-loop" is the industry's phrase for the safety architecture, and it is worth being precise: the human in the loop is not a system feature, a workflow checkbox, or a compliance abstraction. It is you, reading the thing. A loop with an inattentive human in it has the safety properties of a loop with no human in it, plus a signature certifying otherwise.

Verification scales with stakes, exactly as the D2 grid laid out. The inbox draft gets a careful proofread: is this what I would say, is anything wrong or missing? The clinical note gets line-verification: every exam finding, every dose, every statement of fact checked against what actually happened. The discharge instruction gets read as if the patient's outcome depends on it, which it does. What never appears on this scale is zero. There is no stakes level at which signing unread is a defensible act.

The honest tension: verification costs time, and the tool was adopted to save time. Resolve it honestly. The tool drafts faster than you; you verify faster than you draft. The net is still positive. A workflow whose economics only work if you skip verification is not a time-saver. It is a liability with good throughput.

Clinical Anchor

What To Do

1. Read before signing. As if you wrote it. Not for grammar, for facts: every finding, every value, every claim checked against what actually happened.
2. Hunt the silences. AI-drafted notes confabulate hardest where the input was quiet: undone exam elements documented as normal, unasked questions documented as answered. Check what the note claims happened against what happened.
3. Scale the depth by the D2 grid, never to zero. Proofread the low-stakes draft. Line-verify the clinical record.
4. Decide your daily AI-output volume by what you can actually verify, not by what the tool can produce. Throughput that outruns your reading is unread signing with extra steps.

How It Fails

Automation bias compounds with volume. The first hundred outputs were fine, so the hundred-and-first goes through on the pattern of the hundred before it. The skipping is not a decision; it is an erosion, invisible from the inside because every skipped verification is rewarded with saved time and no consequence, until the one that matters. The cost is your license defending a sentence you never saw, and the discovery that "I always review them" stopped being true months before you stopped saying it.

The Concept

Ownership. Legally and professionally, the analysis is short. You are the licensed professional. The tool is an instrument. When a chart entry is wrong, the question is never "was the software accurate," it is "did the clinician meet the standard of care." Vendors reinforce this in writing: every clinical AI contract carries language stating the tool does not practice medicine and the clinician retains responsibility for all decisions. Their lawyers settled the ownership question before you ever logged in. Their answer was you.

Attribution. What to document about AI involvement sorts into three bins. Required: whatever your institution's policy and your state's rules say. Wise: a brief note when AI drafted something consequential and you materially reviewed it. Noise: disclaiming every spell-check and autocomplete. Over-disclosure buries the disclosures that matter.

The deposition lens. The cleanest test for any documentation question: imagine explaining it under oath. Every answer that survives that room has the same shape: "I used a tool, I reviewed its output against the facts, I corrected what needed correcting, and I signed what I verified." Workflows you would describe differently under oath than to a colleague are workflows to fix now.

Clinical Anchor

What To Do

1. Learn your institution's AI documentation policy and your state's disclosure requirements.
2. Document material AI use the way scribe use is documented: briefly, factually, once. "Note drafted with ambient AI scribe; reviewed and edited by me."
3. Never document a review that did not happen. An attestation contradicted by the audit log is worse than no attestation.
4. Run the deposition lens over your standing workflows once a quarter: could I describe this process under oath without flinching? Fix the ones where the answer is no.

How It Fails

Ownership gets assumed to sit elsewhere: with the vendor, because they built it; with the institution, because they bought it; with informatics, because they configured it. Every one of those parties has a document establishing the opposite, and none of them will be named on the chart. The assumption survives because it is never tested in ordinary practice. The cost is discovering the true answer at the worst possible moment, in front of a lawyer, when the vendor's indemnification clause, the institution's policy, and your signature all point at the same person.

The Concept

Protected health information is the combination that matters: information about health or healthcare, linked to something that could identify the person. Either half alone is fine. A creatinine of 4.2 belongs to nobody. A name with no clinical content is a phone book. Together, they are PHI, and everything in HIPAA attaches to them.

HIPAA names eighteen identifier categories, and the de-identification standard requires removing all of them. The ones clinicians forget:

• Dates. All dates tied to the person: admission date, procedure date, date of death, any date more specific than the year. "Presented on March 14th" is an identifier.
• Ages over 89. "A 94-year-old" is an identifier by itself.
• Geography smaller than a state. The hospital name, the town, "our small community ED in [county]."
• The long tail. MRN, account numbers, device serial numbers, photos, license plates, IP addresses.
• The catch-all. Any other unique identifying characteristic. The circus performer with the unusual injury is identifiable to everyone who heard about the case, no name required.

The clinical habit that matters: rare combination equals identification. A diagnosis, an age, a date, and a town can pin a person precisely when the combination is unusual, and unusual combinations are exactly what makes a case interesting enough to type into a chatbot.

Clinical Anchor

What To Do

1. Learn the categories that bite: names, dates, geography below state level, ages over 89, unique circumstances. Audit every prompt against them before sending.
2. De-identify by abstraction, not deletion: "a man in his 60s, several days after a crush mechanism." Keep the clinical physics, drop the fingerprints.
3. For rare presentations, abstract harder. The more interesting the case, the more identifying its details.
4. When the clinical question genuinely requires the specifics, that is not a de-identification problem. That is a "use the institutionally covered tool" problem (L2).

How It Fails

De-identification gets equated with anonymization-by-name-removal. The other seventeen categories ride through in prompts, presentations, and posts, and the combination does the identifying. The failure is invisible at the moment of disclosure; nothing bounces, nothing warns. It becomes visible when the patient, the family, or the compliance office recognizes the case. Cost: a breach investigation centered on a prompt you cannot recall and the tool retained.

The Concept

Strip HIPAA to the parts that govern your AI use and three concepts remain.

Covered entities and the chain of trust. You and your institution are covered: bound to protect PHI. A vendor handling PHI on your behalf must be bound into the same chain by a business associate agreement — a contract making the vendor legally responsible for safeguarding what you send. The BAA is the entire dividing line between tools. The enterprise AI scribe your hospital deployed has one. The consumer chatbot on your phone does not. Identical model, possibly the same company; the legal status of typing a patient's details into each could not be more different.

Consumer tools are not covered, and their terms say so. Free-tier chatbots may retain your prompts, use them for training, and have humans review them, per terms of service nobody reads. Sending PHI into one is disclosure to an uncovered third party. That it was convenient, well-intentioned, and clinically helpful changes nothing about its status as a breach.

Minimum necessary still applies. Even inside a covered tool, use the least PHI the task requires. The habit from L1 does not retire when the BAA appears. The BAA changes what is legal, not what is wise. Less PHI in the window is also better context discipline (D4). The law and the craft point the same direction.

What HIPAA does not do: care how good the tool is. There is no accuracy exception, no "it improved care" defense, no carve-out for tools everyone at the conference was praising. The analysis is plumbing, not merit: where does the data go, and is that destination bound to protect it?

Clinical Anchor

What To Do

1. Sort every AI tool you touch into two bins: institutionally covered (BAA, deployed for you, sanctioned for PHI) and everything else. If you do not know a tool's bin, it is in the second bin.
2. PHI goes only into the first bin. Strip and abstract per L1 for everything else.
3. The shadow-use trap is real and predictable: when the covered tool is worse than the consumer one, the gap fills with breaches. If the sanctioned tool is unusable, escalate that as the patient-safety issue it is rather than quietly routing around it.
4. Personal accounts on covered platforms do not count. The BAA covers the institution's tenant, not the same product with your personal login.

How It Fails

The breach does not feel like a breach. It feels like working late. The consumer tool is faster, better at the task, and one tab away. The prompt that crosses the line reads like every compliant prompt before it. Nothing alerts; the workflow rewards itself daily. Discovery comes later and sideways: an OCR audit, a vendor's training-data disclosure, a patient who finds their case described by a chatbot. By then the question is volume: how many prompts, over how many months, from how many clinicians who all reasoned the same way. Cost: a breach measured in patients, with your login on it.

The Concept

The legal landscape for clinical AI is unsettled at the edges and settled at the center. The center: malpractice asks whether a reasonable clinician would have done what you did. The tool's involvement does not change the question. It changes the evidence.

The vendor is shielded by design. Clinical AI contracts uniformly state the tool is informational, does not practice medicine, and leaves all decisions with the clinician. Courts have historically treated clinical software as a tool of the learned professional rather than a product that can commit malpractice, and the "learned intermediary" between the software and the patient is you. Suing the vendor is hard, slow, and rare. Suing the physician is the established path. Plaintiff's counsel takes the established path.

Liability cuts both ways, and that is the trap. Today, following the AI off the standard of care is indefensible: "the model recommended it" mitigates nothing. But the other edge is sharpening. As AI tools become standard equipment, ignoring an accurate AI flag becomes its own exposure: the sepsis alert that fired, was dismissed without documentation, and preceded a deterioration is already plaintiff-exhibit material. The defensible position is not "always trust" or "always ignore." It is documented judgment: engaged with the flag, reasoned about it, decided, recorded why.

The record is the battlefield. Audit logs preserve what fired, what you saw, how long you looked, what you overrode (D11). Cases will be reconstructed from that scaffolding. Undocumented reasoning, in that reconstruction, is indistinguishable from no reasoning.

Clinical Anchor

What To Do

1. Treat AI output as information you weigh, never as cover. "The tool said" has no defensive value; "I considered the flag, checked it against X, and concluded Y" has all of it.
2. Document overrides of AI recommendations with one line of reasoning, especially for alerts that later prove right. The undocumented dismissal is the discoverable one.
3. Know which tools in your workflow are FDA-regulated devices versus unregulated informational software. It changes institutional duties and, increasingly, what the standard of care assumes you had available.
4. Apply the D1 screen with liability eyes: never delegate to AI a judgment you could not defend independently, because independently is exactly how you will be asked to defend it.

How It Fails

Clinicians import a consumer intuition: when the product is defective, the manufacturer answers. It is how cars and toasters work, so the assumption transfers silently, and a quiet sense of shared responsibility creeps into daily decisions: lighter checks, faster accepts, the tool as a colleague who holds part of the bag. The tool holds none of the bag. The contract saw to it before deployment, and the discovery arrives at the deposition, where the vendor's lawyer is not in the room and the named defendant is. Cost: the standard of care applied to you alone, retroactively, on decisions made as if it were shared.

The Concept

Consent law for clinical AI is the least settled part of this section, so this spread separates the stable floor from the moving pieces.

The stable floor is ethical, not statutory. Informed consent has always covered the material elements of care, and a recording device in the exam room, an algorithm reading the imaging, or a chatbot answering the portal message can be material to a reasonable patient. The test that travels across every jurisdiction: would this patient be surprised to learn how this was done? Surprise after the fact is the failure state, legally sometimes, relationally always.

The moving pieces, in three bins. Recording tools (ambient scribes) sit in the strictest bin: two-party-consent states make unconsented recording independently illegal, and institutional policies almost universally require an explicit ask. Patient-facing generators (AI-drafted portal replies) sit in the fastest-moving bin: states have begun mandating disclosure when AI generates patient communications, and institutions are adding standing disclosure lines. Clinician-facing tools (CDS, drafting aids) sit in the quietest bin: generally no individual consent requirement, though institutional transparency obligations are growing.

Disclosure is a skill, not a form. The ask takes one sentence and lands best when it is concrete and revocable: "I use a program that listens and drafts my note so I can pay attention to you instead of the keyboard. I review everything it writes. Okay if we use it?" Patients overwhelmingly say yes when asked first. Refusals are typically about something specific and manageable, and honoring them cheaply buys durable trust.

Clinical Anchor

What To Do

1. Know your two governing layers: your state's rules (recording consent, AI-communication disclosure mandates) and your institution's policy. Where they differ, the stricter one is your floor.
2. For ambient scribes: ask every patient, every visit, in plain language, with an easy no. Document the yes the way your policy directs.
3. For AI-drafted patient communications: follow the disclosure mandate if your jurisdiction has one. Consider the standing disclosure line even if it does not. The cost is one sentence; the alternative is the anchor scenario.
4. Run the surprise test on any new tool: if this patient learned exactly how this was done, from someone else, would it cost trust? If yes, the disclosure should come from you.

How It Fails

Disclosure gets treated as the institution's problem: somewhere in the intake packet, page nine, a paragraph about technology in care. Legally that may even hold. Relationally it fails completely, because consent buried in boilerplate produces exactly the after-the-fact surprise the disclosure existed to prevent, with the added insult that the system can prove the patient was technically told. The trust damage lands on the clinician in the room, not the packet's author. Cost: the patient relationship, plus a complaint file, in exchange for skipping one sentence you could have said.

The Concept

FERPA, the Family Educational Rights and Privacy Act, is the federal privacy law for education records at any institution that takes federal education funds. If you teach students, you handle records it protects: grades, exam scores, clerkship evaluations, remediation plans, professionalism concerns, the MSPE.

It reaches medicine in two places. The first is medical education. The narrative evaluation, the competency-committee summary, the struggling-learner file are education records, and disclosing them outside the institution without consent is the same category of act as disclosing a chart. The second is the counterintuitive one: at student health services, the campus clinic's chart on a student is typically a FERPA "treatment record," excluded from HIPAA entirely. The privacy regime follows the institution, not the stethoscope.

The AI angle is that FERPA has no BAA. The lawful route for a vendor to touch education records runs through the institution's contracts, under what the law calls the school-official exception. A consumer chatbot you signed up for on your own is not a school official, so pasting learner records into it is a disclosure, exactly as pasting PHI into it would be.

And de-identification is harder for learners than for patients, because cohorts are small. "The intern who failed the airway assessment on this rotation" identifies one person to everyone who matters, with no name attached.

Clinical Anchor

What To Do

1. Extend the PHI reflex to learner data. Before pasting, ask about an evaluation exactly what you would ask about a chart.
2. Know which regime governs the record in front of you: patient chart, HIPAA; learner record, FERPA; campus-clinic student chart, usually FERPA, not HIPAA.
3. Use institution-sanctioned tools for learner work. The school-official exception runs through contracts, and your personal chatbot is not in one.
4. De-identify for cohort, not just name. In a class of eight, the rotation plus the deficiency is an identifier.
5. Draft with identity out, add identity after, inside the sanctioned system. The model never needed the name to help you write.

How It Fails

The clinician with flawless patient-privacy habits treats learner data as fair game precisely because it is not PHI. The struggling-learner summary goes into a consumer tool, works beautifully, and becomes routine. Then the learner exercises the right FERPA gives them, requests their file, disputes the record, and the question "who has seen this" gets asked formally. Cost: a protected record sitting in a system the institution never sanctioned, a violation with your login on the upload, and a trust breach with someone whose career you hold in your hands.

The Concept

Ambient scribes (Abridge, Nuance DAX, Suki, and EHR-integrated equivalents) listen to the visit, transcribe it, and generate a structured note. The documentation burden they remove is real, the burnout data is genuinely encouraging, and this is probably the AI tool most likely to be in your workflow already.

The half the vendor leads with: less time charting, more eye contact, notes done before you leave. Largely true.

The half this book exists for: the note is a prediction, not a record. The pipeline is speech-to-text, then a language model generating a note from the transcript, and that second step inherits every property from the Substrate section. Where the transcript is silent, the model completes the pattern of a typical note (F2): exams normalize, reviews of systems fill in, vague mentions crystallize into specific findings. The scribe does not know what you actually examined. It knows what notes usually say after visits that sound like this one.

Predictable failure geography: strongest in the narrative HPI, where the patient's own words are the source material. Weakest in exam findings (often partly unverbalized), numbers and dosages (speech-to-text mangles them), laterality, negatives ("no chest pain" heard or generated where the conversation was ambiguous), and attribution in multi-speaker visits, where the daughter's symptom history can land in the patient's HPI.

Two non-negotiables ride along: recording consent every visit (L4), and the signature rule at full strength (D10), because this is the one AI output that becomes legal testimony with your name on it every single time you use it.

Clinical Anchor

What To Do

1. Consent first, every visit, one sentence, easy no (L4).
2. Verify by zone: skim the HPI, but line-verify the exam, medications, numbers, laterality, and negatives. Check what the note says happened against what happened.
3. Hunt the silences specifically: anything documented as examined or asked that the visit did not contain is the scribe's signature failure. Delete on sight.
4. Dictate the unverbalized on purpose: state exam findings aloud as you go. It improves the source material and shrinks the gap the model fills.
5. Recalibrate after any vendor update (F4). The scribe you verified last quarter is not the scribe you have now.

How It Fails

The first month builds the habit and the third month breaks it. Early outputs get read closely, prove mostly accurate, and the verification relaxes toward a skim, then toward a signature reflex; automation bias compounding with volume (D10) on the highest-volume AI output in medicine. The fabricated findings are individually rare and always plausible, so nothing interrupts the slide. The cost arrives through the one note in five hundred that documents the exam you never did on the patient who deteriorates: a chart full of unread attestations, an audit log that shows the reading time, and a license explaining both.

The Concept

Clinical decision support has been in the EHR for decades as rules: if potassium high and patient on spironolactone, fire alert. The rules were dumb but inspectable; you could read the logic and decide where it was wrong.

The new generation is predictive and generative: machine-learning risk scores (deterioration, readmission, sepsis), imaging flags queued for your attention, and increasingly, language-model summaries and suggestions woven into the chart. Three properties changed.

The logic went opaque. A rule could be audited; a model's output is a score with, at best, a list of contributing features. You cannot inspect your way to trust. Trust has to come from performance data, ideally on your institution's population, which means the right to ask for that data is now part of the bedside skillset (D8).

The input is the chart, and the chart is dirty. These models consume documentation: vitals charted late, problem lists never reconciled, copy-forward text. Garbage in is now invisible garbage in, because the model does not flag that its inputs were stale. A score computed on bad data looks identical to a score computed on good data.

The model drifts. Performance degrades as practice patterns, populations, and documentation habits shift under it. The model validated at deployment is not the model's accuracy today (the sepsis spread, C3, is the canonical story). Recalibration is the institution's job, but knowing that drift exists is yours.

What stays constant from the old era: alert fatigue is the dominant failure mode of all CDS, and the liability cuts both ways (L3): following a bad flag off the standard of care and dismissing a good flag undocumented are both losing positions.

Clinical Anchor

What To Do

1. Treat the score as a consult, not a verdict: a prompt to look, never a substitute for looking, and never a reason to act against your exam without resolving the conflict.
2. Interrogate before you dismiss or obey: what inputs drove this, and are they real, current, and about this patient?
3. Document engagement either way, one line (L3): why you acted, or why you reasonably did not.
4. Ask the deployment questions once per tool: validated on what population, performance at our site, who monitors drift, when was it last recalibrated. No answers is an answer.
5. Report the misfires. Drift gets caught by aggregated bedside reports long before the annual review does.

How It Fails

Alert fatigue, now with a worse credibility curve. The model fires often, is usually ignorable, and trains the floor to dismiss it; then drift degrades it further, dismissal becomes universal, and the one true flag dies in a queue of forty. The new twist is misplaced deference at the other pole: the score's mathematical costume earns it more trust than a colleague's verbal concern would get, so clinicians override their own exam to follow a number computed from a mischarted blood pressure. Both poles share the cost: the patient the tool was deployed to catch, missed, with an audit log proving the flag fired and was waved off in four seconds.

The Concept

The Epic Sepsis Model shipped inside the most widely used EHR in the country and was adopted by hundreds of hospitals, largely on the vendor's internal performance claims. It became the natural experiment the field needed, and the results are the syllabus.

External validation versus internal claims. In 2021, University of Michigan researchers published an independent validation (Wong et al., JAMA Internal Medicine): in their hospitalized cohort, the model identified a third of sepsis cases, missed the rest, and generated alerts on a large fraction of all hospitalized patients to do even that. The vendor's reported numbers were dramatically better. Neither party was exactly lying; the gap was the methodology, most notoriously that aspects of the model's development tangled the prediction with the clinical recognition it was supposed to precede. A model can score well by predicting that sepsis will be diagnosed around the time clinicians are already diagnosing it. That is a circular victory with no bedside value.

The workload denominator. A model that flags everyone catches everyone. Sensitivity without the false-alert denominator is marketing, not evidence. The bedside question is always paired: what does it catch, and what does it cost in alerts per true catch?

The aftermath is the hopeful part. The scrutiny worked. The vendor rebuilt the model, institutions learned to demand local validation before deployment, and the episode pushed the field toward exactly the posture this book teaches. The system corrected because someone external checked, which is Discernment operating at institutional scale: the same move as D8, with a research budget.

Why this spread exists in a field edition: not to criticize one vendor, but because you will sit in committee meetings where the next model is pitched on internal numbers, and you should recognize the shape.

Clinical Anchor

What To Do

1. For any predictive tool, ask for external validation, not vendor numbers. If none exists, the deployment is the experiment, and someone should be running it as one, with local performance measured against ground truth.
2. Always get the pair: detection rate and alert burden. Refuse to evaluate either alone.
3. Ask what the model actually predicts. "Sepsis" might mean a billing code, an antibiotic order, or a clinical event. The label defines the usefulness.
4. Never subtract your own surveillance because a model is watching. The model's sensitivity is not your sensitivity; the net is not the climber.
5. When credible external evidence lands on a tool you use, pull your local numbers. The literature is the alarm; your data is the answer.

How It Fails

Institutional automation bias: the deployment itself becomes the evidence. The hospital bought it, IT integrated it, the committee approved it, so the floor reasonably assumes somebody validated it, while every party in that chain assumed the same thing about a different party. The vendor's internal numbers pass through procurement unchallenged and emerge at the bedside wearing institutional authority. Cost: years-long workforce trained to ignore the tool, patients assumed covered by a net that was not there, and the discovery outsourced to academic researchers who happened to check. The fix in one line: trust attaches to validation, never to deployment.

The Concept

Two distinct things share this label. Institutional chatbots: symptom checkers on the health system website, triage bots in the portal, AI answering scheduling questions, deployed under a BAA with at least nominal clinical oversight. And consumer chatbots: the general-purpose models patients use at home, which is where the real volume is. This spread is mostly about the second, because that is the one in your exam room tonight, uninvited.

What changed from the search-engine era is the register. Google returned ten links and left synthesis to the patient; visible seams, visible disagreement. The chatbot returns one fluent answer, in second person, shaped by exactly how the patient described their problem. Every property from the Substrate applies with the safety margins removed: the answer is a prediction tailored to the prompt (F1), the prompt was written by the most motivated and least calibrated describer possible, and the confidence of the prose carries zero information (F2). A patient who types "could this headache be a tumor" and one who types "reassure me about my headache" can get different answers from the same model, each fluent, each absorbed as the answer.

What also changed: the advice is sometimes genuinely good. Models give reasonable guidance on common complaints often enough that dismissing them wholesale costs you credibility, exactly as eye-rolling at Google did. The patient who arrives saying the chatbot told them to come in tonight is sometimes standing in front of you because the tool worked.

The institutional version carries the opposite risk profile: lower hallucination odds, but your health system's name on every answer, which is why those deployments live under L3 and L4 obligations the consumer tools shrug off.

Clinical Anchor

What To Do

1. Add it to your intake reflex: "What have you read or asked about this?" covers Google and chatbots alike, surfaces the anchor the patient walked in with, and lets you address it directly instead of competing with a ghost.
2. When the chatbot was right, say so. Crediting the tool when it earns it buys you standing for the times you contradict it.
3. Teach the one-liner version of this book: it predicts answers to the story you tell it, it cannot examine you, and it is most wrong when you most want a specific answer. Patients who understand the prompt-shapes-the-answer loop use these tools measurably better.
4. Redirect rather than prohibit: chatbots are good at explaining diagnoses, decoding jargon, and preparing questions for visits. Steering patients to those uses sticks better than warning them off entirely.
5. If your institution deploys one, know its escalation paths before vouching for it; its failures will be attributed to you (L3).

How It Fails

The failure is symmetrical anchoring. The patient anchors on the chatbot's answer before arrival, and the clinician anchors on dismissing it because of the source, and now two parties are defending positions instead of working a complaint. The reflux patient's six-hour delay is the visible half. The invisible half is the clinician who waves off "the AI said this could be serious" without engaging, teaching the patient that disclosure earns dismissal, so the next consultation goes unmentioned and unexamined. Cost: the AI consult goes underground, exactly as Dr. Google did when medicine sneered at it, and you lose the one move that ever worked: being in the conversation.

The Concept

Portal message volume broke clinical inboxes years before AI arrived, so the draft-reply feature (now native in major EHRs) landed on fertile ground: the model reads the patient's message plus some chart context, and a reply appears, waiting for your edit and send. On the D2 grid this is the favorable quadrant: high-stakes content, fully reversible until you hit send, with a built-in human checkpoint. Used properly, it is the best example of augmentation.

The draft is persuasive in a way a blank box is not. An empty reply field makes you generate; a drafted reply makes you evaluate, and evaluation under time pressure degrades into skimming. The phenomenon is anchoring: the draft frames what the reply should be before your clinical reasoning gets a vote. Early research on these tools found clinicians did not save dramatic time but reported less cognitive burden, which is the same finding stated two ways: the tool is doing more of the thinking. That is fine, exactly as long as the review is real.

The model answers the message, not the patient. It sees the text and whatever chart slice the integration feeds it (F1, D4). It does not know the message is the third escalating contact this month, that "still dizzy" comes from the woman whose last visit you nearly admitted, or that this patient minimizes everything. The thread's clinical subtext is your context, and it is not in the window.

The tone is excellent, and that is a trap. Drafts arrive warm and complete-sounding, which raises the approval reflex precisely where vigilance should rise: fluency reading as adequacy (F2). A reply can be perfectly empathetic and clinically wrong about what this message represents.

The discipline is one question before every send: is this what I would have said? Not "is this acceptable." Yours.

Clinical Anchor

What To Do

1. Read the patient's message first, fully, before reading the draft. Form your one-line impression of what this message is, then look at what the model thinks it is. Order matters; it is your only anchoring defense.
2. Apply the yours test before sending: would I have said this? Edit until the answer is yes, or discard and write.
3. Check the thread, not the message. Drafts are message-scoped; medicine is thread-scoped. Repeat contacts about the same symptom override any single draft.
4. Verify every clinical fact in the draft against the chart: doses, dates, results, instructions (D8). The draft's chart access is partial and its gap-filling is fluent.
5. Audit yourself monthly: pull ten sent replies and ask how many were genuinely edited versus approved. The ratio is your drift gauge (D10).

How It Fails

Volume converts editors into approvers. The inbox is infinite, the drafts are consistently decent, and the send button is the path of least resistance forty times a day; within months the workflow silently inverts from "AI drafts, I write the final" to "AI writes, I bless." Each individual approval was reasonable. The aggregate is a clinician whose patient communication is generated by a model that cannot see the thread, rubber-stamped at a pace no real review could survive, and the audit trail shows it. Cost: the no-showed wound check reassured into a readmission, signed with your name and a four-second review timestamp (D11).

The Concept

The build-versus-buy decision is the Delegation Decision (D1) one level up. Before you decide what to hand the AI, decide whether to build the thing that does the handing off at all.

There is a ladder here, and the cheapest rung that does the job is the right one.

• Use it as-is. The tool, out of the box, with no setup. Most needs stop here and should.
• Configure it. Instruction files, projects, custom commands (D6). Most of what feels like "I need to build" is actually "I need to configure."
• Integrate it. Connect tools that already exist so they talk to each other. No new code, just wiring.
• Build it. Net-new software with your name on it. The top rung, and the one people reach for first because building is now easy.

That is the trap. The model writes the first version of almost anything in an afternoon, so the build feels free. It is not. The first version was never the cost. The cost is maintenance: the model updates, the API changes, the workflow drifts, the source moves, and a tool with your judgment baked in that quietly breaks is worse than no tool at all.

So the real question is not "can I build this." You can. The question is whether the workflow earns its upkeep: is it recurring, specific to your practice, unserved by anything you could buy, verifiable in its output, and owned by someone past the day it ships.

Clinical Anchor

What To Do

1. Start at the bottom rung and climb only when forced. Can an existing tool, configured, do this? Usually yes.
2. Name the maintainer before you write a line. If the answer is "nobody, really," do not build it.
3. Build only verifiable workflows. If you cannot check the output, you cannot safely automate it (D1, D8).
4. Prototype in an afternoon, decide in a week. If it is not clearly earning its maintenance cost after a week of real use, kill it without ceremony.
5. Write down what it depends on: which model, which source, which API. That list is what you will check when it breaks, and it will break.

How It Fails

The demo works, so it ships, and the maintenance never gets budgeted. Builder tools rot silently: a model swap, a deprecated API, a changed source, and the output degrades while the tool still appears to run (D3). The clinician who built it has moved on to the next thing, but the tool keeps producing, keeps signing outputs with their standard attached. The failure is discovered downstream, by the people who trusted the output, long after the person who built it stopped watching. Cost: a pipeline failure wearing your name, found by everyone except you.

The Concept

Every product that advertises memory is doing the same trick: storing text and injecting it into the context window at the start of a session (D4). The model itself remembers nothing between conversations (F3). So engineering memory is engineering what gets injected, from where, and when.

Think in three layers, increasing in durability and decreasing in how often they should load.

• Instruction files. The role and the standing rules that load every single session (D6). Smallest layer, always present. Your standing orders.
• Project memory. Facts scoped to one body of work: this study's protocol, this initiative's constraints. Carried across the sessions of that work, absent everywhere else.
• The knowledge base. Your notes, protocols, and references, retrieved on demand rather than always loaded (D7). The library, not the desk.

The discipline is curation, not accumulation. Memory bloats by default, and a twenty-page instruction file degrades output exactly like any other heavy window (D4). The skill is keeping the always-loaded layer small and pushing everything else into retrieval, where it scales.

Provenance is the part people skip. A memory that injects a stale fact is worse than no memory, because the fact arrives with false authority and you stop checking it. Date what you store. Let retrieval pull the current version instead of freezing last month's.

Clinical Anchor

What To Do

1. Sort every fact into always-load, this-project, or fetch-when-relevant. Most of it belongs in the third bucket.
2. Keep the always-load layer under a page (D6). It is context, and context is finite.
3. Date and version stored facts. A memory with no date is a future hallucination carrying a credential.
4. Prefer retrieval over stuffing (D7). The library scales. The desk does not.
5. Audit memory like a medication list. Review what is stored on a schedule, and deprescribe what has gone stale.

How It Fails

Memory accumulates until it poisons. A fact that was true in March gets injected confidently in June, the output inherits it, and because the system "has memory" nobody re-verifies the premise. This is worse than the empty model, which at least announces that it knows nothing. The failure is invisible precisely because the system feels more capable, not less. Cost: confident output built on a premise no human checked, because the machine appeared to remember it.

The Concept

A one-off prompt solves today's instance. A skill captures the pattern behind it: the role, the steps, the constraints, the output format, packaged so it runs the same way every time. It is the move from prompts to pipelines (D3), made reusable and given a name you can trigger.

Every modern tool exposes this under a different label: custom commands, saved prompts, skills, project templates, custom GPTs. The mechanism underneath is identical. A unit you trigger, that loads its own instructions on demand and runs them.

The value is consistency and transfer. The skill encodes your judgment once, so the tenth use is as good as the first, and a colleague who runs your skill gets your standard rather than their improvisation. That is also the quiet power of it: a skill carries expertise to people who do not yet have it.

A skill is also the right home for failure controls. The verification step, the de-identification rule, the "ask before assuming" instruction can live inside the skill so they fire on every run, instead of depending on whoever is at the keyboard to remember them.

One discipline governs all of it: scope. A skill that tries to do everything triggers at the wrong times and does nothing well. One skill, one job, one clear trigger.

Clinical Anchor

What To Do

1. Find the prompt you keep retyping. That repetition is your first skill, already identified.
2. Write it as role, steps, constraints, format (D5). Put the safety checks inside it, not beside it.
3. Give it one job and a clear trigger. Resist the all-in-one skill that does six things adequately.
4. Test it on a hard case, not an easy one. A skill that only works on the obvious case is a demo, not a tool.
5. Version it deliberately. When you improve the skill, the improvement reaches every future use at once. That is the point, and it is also the risk.

How It Fails

A skill encodes a judgment, and a bad judgment encoded is a bad judgment at scale. The flawed step that was harmless when you ran it once now fires on every use, silently, with your standard attached. And because the skill "works," nobody re-examines the logic inside it. The error is systematic, identical across everything the skill touched, and traceable to one assumption you wrote down months ago and never looked at again. Cost: a uniform mistake distributed across every output the skill produced, by every person who trusted it.

The Concept

Without tools, a model can only talk. With tools, it can do: query a database, run a calculation, send a request, write a file. The line between a chatbot and an agent is tools.

The mechanism is function calling. You describe a capability, the model decides when to call it, and your code runs it and hands back the result. The model never touches your systems directly. It asks your code to act, and your code decides whether and how. That gap is where all your control lives.

MCP, the Model Context Protocol, is the emerging open standard for this connection: a common way to expose tools and data to any model, so an integration you build once works across products instead of being soldered to one vendor (F4). Preferring the open standard is how the work survives a product you will eventually leave.

The engineering itself is almost entirely about boundaries. The hard questions are not "can the model do this" but "what can this tool reach, what can it change, and what must it never be able to do." A read-only tool over lab values is one level of risk. A tool that can place an order is a different category entirely (D2).

Least privilege is the whole rule. Give the tool the narrowest access the job requires. A tool that can do more than its task is both an accident surface and an attack surface, especially once external content enters and prompt injection becomes possible.

Clinical Anchor

What To Do

1. Start read-only. A tool that only reads can be wrong, but it cannot act wrongly.
2. Grant the narrowest access the task requires. Least privilege is not paranoia. It is the specification.
3. Put a human checkpoint in front of any tool that commits an action (D2, D10). Agency is earned, never the default.
4. Assume external inputs are hostile. If the model reads content you did not write, it can be injected, and a tool with reach plus an injection is a real exposure.
5. Prefer the open standard over one-vendor wiring, so an integration outlives the product it started in (F4).

How It Fails

A tool with more reach than its job, on the day the input is poisoned. The model reads a document carrying hidden instructions, follows them, and the over-privileged tool does something nobody asked for. The quieter version: a write-capable tool runs inside a pipeline, an upstream step degrades, and the tool commits the bad result before any human reads it (D3). Cost: a real action taken in a real system, by a tool you built, that you never reviewed and did not intend.

The Concept

Software you write either works or visibly fails. AI tools do neither. They degrade quietly: a model update, a changed source, a drifted prompt, and the output gets subtly worse while the tool keeps running and keeps sounding right (D3, F4). Nothing throws an error. An eval is how you make that silent failure loud.

An eval is a set of known cases with known good answers, run against your tool on a schedule. It is the unit test for something that does not behave the same way twice (F5). You are not asking "did it pass." You are watching a rate across many cases, and watching that rate move when something underneath changes.

Build the eval from real failures. Every time the tool gets something wrong, that case becomes a permanent test. The eval set is your tool's memory of its own mistakes, the one thing standing between it and making the same error twice unnoticed.

The highest-value moment to run an eval is immediately after anything changes: a model version, a prompt edit, a new data source. That is exactly when clinicians assume "it still works," and exactly when it often does not.

Clinical Anchor

What To Do

1. Before you trust a tool, build its test set. Twenty real cases beat a thousand imagined ones.
2. Turn every failure into a permanent case. The eval set grows from real mistakes, not guesses.
3. Rerun after every change: model version, prompt, data source. Change is the trigger.
4. Track the rate, not the single run. Probabilistic output needs a denominator (F5).
5. Set a floor. If the pass rate drops below it, the tool comes down until it is fixed. No exceptions for how useful it is.

How It Fails

No eval, so the only detector left is harm. The tool degrades after a silent model swap (F4), the outputs stay fluent, and the first signal is a person downstream catching a mistake that had been running for weeks. The version with extra steps: the eval exists, but nobody reruns it after changes, which is the same failure dressed up as diligence. Cost: the degradation window, measured in everything the tool produced between the day it quietly broke and the day a human happened to notice.

These are the words that appear in vendor documentation, product releases, and AI conversations without anyone stopping to explain them. Each entry is one analogy and one clinical translation. The spreads do the teaching. This is just the lookup.

Core AI Mechanics

Token. The atom. Everything the model reads and writes is broken into tokens — roughly three-quarters of a word. “Vancomycin” is two tokens. “The” is one. Cost, speed, and context capacity are all measured in tokens, not words. When a tool says it has a 200,000-token context window, that is roughly 150,000 words, or several hundred pages of text.

Context window. Everything the model can see right now, and nothing else. Picture a desk with a finite surface. Whatever is on the desk, the model can use. Whatever is in a drawer, a different room, or a previous conversation, it cannot. Session ends, desk clears. This is why repeating patient details in every message is not redundant. It is necessary.

Hallucination. Confident prediction without grounding. The model is always doing one thing: predicting what comes next. When it predicts without facts to anchor to, it generates text that is plausible in form and wrong in content. It does not know it is wrong. It does not hedge unless trained to. The output reads like a confident attending and may be entirely fabricated. See Judging the Output.

Temperature. A dial between accountant and jazz musician. Low temperature means the model always picks the most probable next word. Predictable, consistent, sometimes flat. High temperature means it samples more freely, producing creative or varied output that is also more likely to wander. Most clinical tools run low temperature by default. When you notice your AI getting repetitive or oddly rigid, this is usually why.

Inference. Running the model to get an answer. When you hit send, you are requesting inference. “Inference cost” is what the API charges per query. Inference latency is how long it takes to respond. You will see these terms in vendor pricing sheets and IT conversations about enterprise AI deployment.

Prompt. Everything you type before hitting send. The prompt is the only control surface you have. There is no other dial. System prompts, examples, patient context, instructions, output format — all of it is prompt. Input quality is the only variable you control, and it determines output quality completely. See Prompting Is a Consult.

System prompt / instruction file. Standing orders the model follows before you say a word. Every commercial AI product has one baked in by the vendor. You can often add your own layer on top: custom instructions, project files, CLAUDE.md. These are how you enforce rules that apply to every interaction — no PHI, flag uncertainty, use this format — without repeating them every session. See Standing Orders for Your AI.

RAG (Retrieval-Augmented Generation). The open-book exam. Instead of answering from training memory, the model is handed documents at query time and answers from those. You ask about your hospital’s sepsis pathway. RAG pulls the actual pathway and puts it in the context window before the model responds. Cuts hallucination sharply. Does not eliminate it — the model can still misread the document it was handed. See Grounding: RAG & the Second Brain.

Fine-tuning. Residency, not a consult. Retraining the model on a specific dataset so it performs better on a narrow task. Expensive, slow, and usually not what clinicians need. Most clinical use cases are better served by good prompting and RAG. If a vendor says their product is “fine-tuned on clinical data,” that is a claim worth interrogating: what data, how recent, validated against what.

Multimodal. A model that accepts more than text. Early LLMs read and wrote words only. Multimodal models accept text, images, audio, and in some cases video. Your ambient scribe is multimodal: it listens to spoken language and outputs text. Any AI tool that reads an ECG strip, a wound photo, or a radiology image is multimodal. The underlying prediction mechanism is the same. The input types are not. When a vendor says their model is multimodal, ask which modalities are actually supported in the clinical product, not just in the underlying model.

Embedding. Meaning turned into numbers. Before retrieval can work, documents have to be converted into numerical representations that encode semantic similarity. Two sentences that mean the same thing should produce similar numbers even if the words differ. Embeddings are what make a vector database searchable by concept rather than exact keyword. You will not interact with embeddings directly, but they are the engine under RAG and semantic search.

Agentic and Workflow Terms

Agent. An AI that takes actions, not just answers. A chatbot responds. An agent responds and then does something: clicks a button, sends a message, pulls data from a system, writes a file. AI scribes, inbox drafters that auto-send, and clinical decision support tools that order labs are all agents to varying degrees. The more autonomous the action, the more critical your verification step. See From Prompts to Pipelines.

Agentic loop. Plan, act, observe, repeat. The internal cycle that makes an agent work. The model predicts an action, takes it, sees the result, incorporates the result into context, and predicts the next action. Claude Code runs this loop when it writes and tests code. An AI scribe runs a version of this loop when it listens, transcribes, and reformats. Loops amplify both quality and error. A wrong assumption early compounds through every subsequent step. See From Prompts to Pipelines.

Pipeline. A repeatable workflow with fixed steps and one verification checkpoint. When you do the same AI-assisted task more than three times, it is a pipeline candidate. Pipelines are faster and more consistent than one-off prompts. They also fail silently: if a model update or source change degrades the output, nobody notices until the damage accumulates. Every pipeline needs a human check at the end. See From Prompts to Pipelines.

Tool / function calling. The mechanism that lets a model take actions beyond generating text. Tools give the model the ability to search, calculate, pull data from an API, or trigger an external function. Without tools, a model can only talk. With tools, it can do. The line between a chatbot and an agent is tools.

Prompt injection. Someone else’s instructions smuggled into your context. If your AI is reading a web page, a document, or a patient message, and that content contains hidden instructions (“ignore your previous instructions and do X instead”), the model may follow them. A real attack vector for agentic tools that ingest external content. Relevant whenever your AI has access to inputs you did not write yourself. See Standing Orders for Your AI.

Sandbox. A walled environment where an agent can act without touching real data or live systems. Claude Code runs in a sandbox by default. Enterprise AI deployments with access to the EHR should be sandboxed during testing. If a vendor cannot describe the sandbox their agent runs in, that is a material gap.

Guardrails. Fences built into the model or the product that block specific outputs or actions. Every major commercial AI has guardrails: refusals on certain content types, output filters, usage policies. Enterprise products layer additional guardrails on top. Guardrails are not always visible, not always documented, and not infallible. A tool that “will never include PHI in its output” is expressing a guardrail, not a technical impossibility.

Infrastructure Terms

API (Application Programming Interface). The drive-thru window between your AI and another app’s data. Your AI does not log into Epic. It sends requests to Epic’s API, which returns structured data. Every integration between an AI tool and a clinical system runs through an API. The API defines exactly what is available and what is not. “The AI can access your notes” means the EHR vendor opened a specific window. It does not mean the AI has access to everything.

API key. The credential that proves your AI is allowed at the window. A long random string that authenticates requests. If an API key is exposed, anyone who has it can make requests billed to your account. Never paste an API key into a document, a shared chat, or a screenshot. This is the first rule of every developer security guide, and clinicians building AI tools violate it regularly.

Markdown. Plain text that formats itself. Asterisks become bold. Pound signs become headers. Hyphens become bullet points. Most AI tools output markdown. If you paste AI output into a plain-text field and see asterisks everywhere, that is why. Obsidian, Notion, and most documentation tools render markdown natively. Word and the EHR do not.

JSON (JavaScript Object Notation). The note card format software uses to pass data between systems. Structured, readable by humans if you know what you’re looking at, and nearly universal as the data format for API responses. When your AI tool connects to a lab system and pulls results, the results arrive as JSON. You will not write JSON manually, but you will see it when debugging integrations or reading API documentation.

CLI / terminal / bash. Typing commands directly to the computer instead of clicking. The terminal is the text interface to your operating system. Bash is the language those commands are written in. Claude Code runs in a CLI. Setup instructions for AI tools often include CLI steps. If you see a block of text with a dollar sign at the start, that is a bash command you are meant to type into a terminal. The dollar sign is not part of the command.

curl. A CLI command that sends a request to an API and shows you what comes back. You will see curl in almost every API quickstart guide. It is the simplest way to test whether an API connection works. curl https://api.example.com/endpoint says: go to that address and show me what it returns. If you are working with a developer on an AI integration and they ask you to run a curl command, this is what they mean.

Webhook. An app that taps you on the shoulder the moment something happens, rather than waiting for you to ask. A scheduled appointment triggers a webhook that tells your AI to draft a pre-visit summary. A lab result comes in and triggers a webhook that flags it for review. Webhooks are how real-time AI workflows are built. Pull means you ask. Push means it tells you automatically. Webhooks are push.

Model version. The frozen snapshot of a model you are using. GPT-4o and GPT-4o-mini are different models. Claude 3.5 Sonnet and Claude 3 Opus are different models. A vendor who says “we use AI” without specifying the model version is telling you nothing about capability, cost, or consistency. Model versions matter because they change, and when a vendor updates the underlying model, your outputs may change without warning.

Latency. The lag between send and response. A few seconds of latency is irrelevant for drafting a discharge summary. It is material for real-time ambient scribing during a patient encounter. When evaluating clinical AI tools, latency is a practical specification, not a technical detail.

Rate limit. A cap on how many requests you can make per minute or per day. Hit the limit and requests fail until the window resets. You will see this as a 429 error. Rate limits exist because AI inference is expensive and providers need to manage load. Enterprise contracts typically include higher rate limits. If a clinical tool goes down at peak hours, a rate limit is one of the first things to check.

Terms That Are Not What You Think

Memory. “It remembers me.” It does not, by default. Memory is a feature layered on top of a model, not built in. Every new session starts with an empty context window unless memory has been explicitly configured. Some tools offer memory features that persist information across sessions. These are implemented by injecting stored summaries into the context window at the start of each conversation. They are useful and imperfect.

Training. “It learned from my chats.” Consumer AI products do not train on your inputs by default, and enterprise products typically contractually prohibit it. Check the privacy policy. “Training data” refers to the massive dataset used to build the model before you ever typed a word. Your conversations are not improving the model in real time. They may be logged for safety review, depending on the product and your agreement.

Intelligence. “It understands.” It predicts. Very sophisticated prediction, over an enormous training set, produces outputs that look indistinguishable from understanding in many contexts. They are not the same thing. The model has no goals, no comprehension, no awareness of whether its output is correct. It has learned which tokens tend to follow which other tokens, at extraordinary scale. That is the whole engine.

Confidence. “It sounds certain, so it probably is.” Confidence carries zero information about accuracy in an LLM. The most hallucinated outputs are often the most fluent and assertive. The model does not have an internal accuracy meter it consults before responding. Hedging language like “I believe” or “approximately” is a trained behavior, not a signal of calibration. Treat every output as unverified until you have checked it. See Judging the Output.

Cross-references: terms marked See Dx point to the spread that covers the concept in full clinical depth.