Give the model the facts it wasn't trained on

A model answers from two sources, and you control one

A model is trained once on an enormous snapshot of mostly public text and then frozen, with the cutoff date printed on each model's page; nothing after that date enters. At run time the model draws on that snapshot plus whatever your call sends, and there is no third channel. The demo failed on both at once: the snapshot held your three-year-old pricing page, and the prompt held nothing newer.

Our FuelTheFam fridge feature runs on the second source. When a user snaps a photo of their fridge, the call that builds their shopping list carries the deciding fact inside it: the photo, taken seconds ago. Training data supplies what spinach and a dozen eggs look like; the photo supplies which of them sit in this fridge. One prompt line adds discipline, return only items visible in the photo, because training data also carries a prior (internet fridges usually hold milk and ketchup) that would pad the list with plausible items the picture does not show.

At run time a model draws on exactly two sources, the frozen training snapshot and whatever the prompt carries, so every fact your feature needs that the snapshot lacks must arrive in the prompt.

The obvious objection is that the model already read the whole internet, your pricing page included. It did, and the objection fails twice. It fails on time, because the snapshot froze months before your call, so March's pricing, June's policy change, and yesterday's outage do not exist in it. And it fails on privacy, because no snapshot of the internet contains this customer's order number, that account's renewal date, or a fridge photographed a minute ago.

Stuff the facts into the prompt

The fix for the demo runs ten lines. Write the current facts down and send them with every call, ahead of the question:

You are the billing assistant for our product. Answer only from
the FACTS block. If the facts do not cover the question, say so
and point the customer to support.

FACTS (last updated 2026-06-30):
- Current plans: Essentials at $39/month, Team at $99/month.
- The Starter plan ($29/month) was retired in March 2026.
- Existing Starter subscribers keep $29/month until January 2027.

Customer question: {question}

The demo question now splits in two. Without the block: "Starter is $29 a month, and upgrading takes one click." With it: "Starter was retired in March 2026; new signups begin on Essentials at $39/month, and Team at $99/month sits above it." The same model produced both replies, and only one call carried the facts.

The grounding rule settles which source wins when your facts and the snapshot disagree, and gives the model a sanctioned exit when the facts run out, the same way the fridge feature asks for a retake instead of guessing at an unreadable photo. The dated header lets you catch stale facts before a customer does.

The threshold: when the facts fit on a few pages and change rarely, stuffing wins. The block rides along for a fraction of a cent per call at mid-tier rates, nothing new can break, and an update is a text edit. Most first features never need more than this.

When the facts fill a manual, fetch the relevant few

Volume breaks that threshold. By the time the help center behind the assistant holds two hundred articles, roughly four hundred pages, sending all of it with every call spends tokens on the whole pile and buries the two lines that answer. So you store the articles outside the prompt and fetch, per question, only the few that match. Here is the move, run once by hand.

The question: "Can I change my sign-in email without losing my order history?"

The three snippets the search returns:

• From Change your sign-in email: the setting lives under Settings > Account > Email, and a confirmation link goes to both addresses.
• From What stays with your account: orders, receipts, and saved addresses attach to the account, not to its email.
• From Confirmation emails that never arrive: links expire after 24 hours; resend from the same screen.

The answer, grounded on them: "Yes. Update it under Settings > Account > Email and confirm from both addresses. Your order history stays, because orders attach to your account, not your email. If the link does not arrive, check spam and resend; links expire after 24 hours."

The point of the move is that every sentence of the answer traces to a snippet. Engineers call the pattern retrieval-augmented generation, RAG for short, and the acronym promises more machinery than you just watched: store the documents, find the few that match, put them in the prompt, let the model answer from them.

The engineering that makes "find the few that match" accurate at scale, meaning-based search, document splitting, ranking, lives in the Frontier: Why hallucinations are context failures shows most wrong production answers are fetch failures, not model failures, and Retrieval: let the product look things up builds the machinery. Your decision here is simpler: retrieve when the facts are too large to send every time, change too often to paste, or differ per user.

When the fact is live, hand the model a tool

Some facts are true only at the moment of the question, an order's status, an account balance, whether the 6 a.m. class still has spots, so the third way hands the model a tool, a function or connector called mid-answer, and your systems return the fact fresh. The standard plug is the Model Context Protocol, and you will meet it in provider consoles in 2026 when you attach a document drive or a database to a model. Tools are the whole next chapter, Give the model tools to fetch and act.

Choose by the facts, not the fashion: stuff what fits on a few pages and rarely changes, retrieve from collections too large to send, and hand the model a tool when the fact is live.

That order is also this part's ladder: prompt, then facts, then tools, with a custom model trained only for the rare feature those rungs cannot carry.

Try it now

The drill takes fifteen minutes; the first path spends nothing, the second fractions of a cent. You arrive with the schema that locked your feature's output in Get output you can build on. You leave with your feature's facts wired in: a facts block stuffed into your prompt, plus a written decision on whether the feature will ever need retrieval.

No setup: Use our billing prompt as the template and draft your build's FACTS block on paper: every fact your feature's answers depend on that a frozen snapshot of the public web would not hold, prices, policies, anything recent or per-user. Then run the threshold: does the block fit on a few pages, change rarely, and read the same for every user? Three yeses mean stuffing carries the feature, so write "no retrieval, because" and finish the sentence; any no means naming the collection the feature would fetch from. Either way, the written sentence is your retrieval decision.

With your tools: Open Claude Code and hand it the block: add the facts, the grounding rule, and the dated header to your feature's prompt, above the schema instruction from the last drill, then rerun two real inputs and confirm the answers now quote your facts. Same move in Codex or Cursor: paste the block above the schema, add the grounding rule, rerun. If your tools are not set up yet, the Setup Clinic gets you there in one sitting.

Keep both artifacts; the next drill bolts a tool onto this same prompt.

Chapter Summary

• At run time a model draws on exactly two sources, the frozen training snapshot and whatever the prompt carries, and there is no third channel.
• Asked for a fact it was handed in neither place, the model still answers, in the same confident register, with the most plausible completion its training data offers.
• The snapshot fails you twice: it froze months before your call, and the facts your product owes its users, orders, balances, this afternoon's fridge photo, never touched the public web at all.
• When the facts fit on a few pages and change rarely, stuff them into the prompt with a grounding rule and a dated header; most first features need nothing more.
• When the collection is too large to send every time, retrieve: store the documents, fetch the few that match the question, and answer from those. That whole pattern is what RAG means.
• More context is not better context; an over-stuffed prompt spends tokens on every call and buries the line that answers.
• Facts true only at the moment of the question need a tool the model can call to fetch them fresh.
• You leave this chapter with your feature's facts stuffed into its prompt and a written decision on retrieval.
• Next, Give the model tools to fetch and act covers fetching's bigger sibling: letting the model do things.

Sources

• Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS.
• OpenAI, Anthropic, and Google documentation on knowledge cutoffs and on providing context to models (last verified July 2026).
• Model Context Protocol specification and provider connector documentation (last verified July 2026).