Forty minutes into the vendor pitch, the account executive says the sentence that will cost the room $240,000: "and of course, the model learns from your data." Around the table, heads nod. The COO writes "learns continuously" in her notebook. Nobody asks the question, because nobody in the room owns the vocabulary to ask it: learns how, exactly? At training time or at inference time? Eleven months later, at renewal, an engineer finally explains that the model never trained on anything; the vendor's staff had been manually updating a prompt template every few weeks, and the "learning" line item, priced like a research program, was two hours of copy-editing a month. Nobody lied, precisely. The vendor used a word loosely, and the buyer paid the difference between the loose meaning and the real one. This lesson exists so that the difference gets paid to you instead. It is a working glossary, but not an alphabetical one: every term arrives inside the meeting where not knowing it costs money, followed by the operator-grade definition, followed by the one question the term unlocks.

The Machine: Model, Training, and Inference

Start with the three words that structure every pricing conversation you will ever have with an AI vendor, because almost every expensive misunderstanding in this field is a confusion between two of them.

A model is the trained artifact itself: a very large set of numerical weights that turns input text into output text. Think of it as a photograph of everything the system absorbed during its education, frozen at a moment in time. It is not a database it can look things up in, and it is not a colleague who remembers last Tuesday. When a vendor says "our model," your first calibration question is whether they built one (rare, expensive) or licensed one from a major provider and wrapped software around it (the overwhelming majority). Neither is bad. But one of them justifies platform pricing and one of them justifies software pricing, and vendors know which impression they would rather leave.

Training is the education phase: the industrial process, involving enormous datasets and serious compute spend, that produced the weights. It happened before you ever saw the product, in someone else's data center, on data that almost certainly did not include yours. Training changes the model permanently. It is slow, costly, and infrequent.

Inference is the usage phase: every time you or your team sends a request and gets an answer, that is inference. It changes nothing about the model. Ten thousand inferences leave the weights exactly as they were. Inference is where your invoices live, because most AI products are priced per unit of inference, whether the unit is called a seat, a query, a document, or a token.

Now rerun the opening scene with the vocabulary installed. "The model learns from your data" almost always means one of three things, in descending order of frequency: your documents are retrieved and pasted into the model's input at inference time (no learning at all, in the training sense); a human periodically edits the prompts or configuration (manual maintenance wearing a lab coat); or, rarely and expensively, the vendor actually fine-tunes model weights on your data. These three things differ in cost by orders of magnitude, differ in data-governance implications enormously, and are all routinely sold under the same word.

The question this section arms you to ask: "When you say it learns from our data, does anything about the model's weights change, or is our data being supplied at inference time? And which one are we paying for?" Watch the answer carefully. A vendor who can answer it cleanly in one sentence is a vendor whose engineers talk to their salespeople.

The Reading Limit: Tokens and the Context Window

A hypothetical scene that plays out somewhere every week: a legal operations team feeds a 200-page master services agreement into an AI assistant and asks for a summary of termination provisions. The summary comes back fluent, confident, and beautifully formatted. Three weeks later someone notices it contains nothing from Schedule F, page 148, where the actual termination-for-convenience mechanics live. The tool did not malfunction. It stopped reading around page 60, said nothing about it, and summarized what it had. The team shipped a summary of the first third of a contract to a steering committee, wearing the authority of the whole document.

Two terms explain the whole incident. A token is the unit AI systems actually read and bill in: a chunk of text roughly three-quarters of a word long on average. "Remediation" might be two or three tokens; "the" is one. Every model prices and measures in tokens, which means your costs and your capacity limits are both denominated in a unit most buyers have never converted into anything they can picture.

So convert it. A dense business page runs roughly 500 words, call it 650 to 700 tokens. The context window is the hard ceiling on how many tokens the model can consider in a single request: everything it is reading, everything you asked, and everything it answers, combined. A model with a 40,000-token window can hold roughly 60 pages in mind at once. One with a 200,000-token window holds roughly 300. The window is not a soft preference; it is a wall. Whatever does not fit is not read, and here is the operationally dangerous part: the system will usually not tell you what fell off the edge. It answers from what it saw, with total composure, exactly like the contract summary above.

This is why "just upload everything" is not an architecture. Serious document workloads get chunked, batched, or retrieved selectively (the next section), and each of those design choices has failure modes an operations leader should ask about, because the person who signs off on the summarized contract owns the summary.

The questions this section arms you to ask: "What is the context window in pages, for our documents? What happens, visibly, when an input exceeds it? And what is our projected monthly token cost at realistic volume, not demo volume?" The last one matters because per-token pricing that looks like rounding error at 50 test documents becomes a real line item at 40,000 production documents a month. Make the vendor do that multiplication in front of you.

Grounding, RAG, and the Three-Rung Customization Ladder

The next scene is quieter and more expensive. A vendor demos an assistant that answers policy questions "from your knowledge base." Asked how, the sales engineer says the magic word: "it's grounded." Everyone relaxes, because grounded sounds like bolted to the floor. Nobody asks grounded on what, or retrieved how, and six months after go-live an internal audit finds the assistant confidently citing a travel policy that was superseded in 2024, because the retrieval index was pointed at a folder nobody had cleaned since the migration.

Grounding means constraining the model to answer from specific supplied sources rather than from its general training. An ungrounded model free-associates from everything it ever absorbed; a grounded one is supposed to quote your documents. The dominant technique for grounding is RAG, retrieval-augmented generation: before the model answers, a search step retrieves the most relevant passages from your document store and pastes them into the context window alongside the question. The model then answers from what was retrieved. Notice what this means: a RAG system is only as good as its retrieval. If the search step fetches the wrong policy, the stale version, or nothing at all, the model grounds itself beautifully on garbage. Grounding is a chain, and the retrieval link is where it usually breaks. The tell of a well-built RAG system is citations you can click: every claim traceable to the passage it came from, so a human can verify in seconds. In the previous lesson on hallucinations you learned why verification is the job; RAG with citations is what makes the job doable at speed.

Grounding also sits on the middle rung of a ladder every buyer should know cold, because vendors habitually sell you a higher rung than the problem needs. There are three standard ways to make a general model good at your specific work:

The ladder has a rule: climb only when the rung below has demonstrably failed. Fine-tuning is not "more better AI." It bakes yesterday's data into the weights (a fine-tuned model does not know about documents added after the tuning run; RAG does), it creates a maintenance liability, and it is the rung with the healthiest vendor margin, which is why it appears in so many proposals attached to problems that a week of prompt engineering would have solved. When a proposal leads with fine-tuning, the burden of proof runs uphill.

The questions this section arms you to ask: "Grounded on what corpus, retrieved how, and who owns keeping that corpus current? Can every answer cite its source passage? And show me the evidence that prompting and RAG were tried and failed before we pay for fine-tuning."

The Trust Terms: Hallucination, Confidence, Drift, and Evaluation

You met hallucination in the previous lesson: the model producing fluent, plausible, false output, the invented SOP step, the fabricated figure. One addition belongs in the glossary here, because it is the single most common inference error executives make in vendor meetings: treating the model's confident tone as an accuracy signal. The word for what is missing is calibration. A well-calibrated system is one whose expressed confidence tracks its actual correctness rate. Current language models are, by default, not that. Confidence is a property of the writing style, not a meter reading from the machinery; the model produces "the penalty clause caps liability at 12 months of fees" and "the penalty clause caps liability at 24 months of fees" with identical poise, one of them being wrong. An assistant that never says "I am not sure" is not an assistant that is always sure. It is an assistant with no gauge on the dashboard, and buying it means agreeing to check the fuel by opening the tank yourself, every time.

Two more terms cover what happens after the contract is signed, which is where the quiet money goes. Drift is the tendency of an AI system's real-world performance to change over time even though nobody changed anything on purpose. It comes from two directions at once: the world drifts (your products, policies, formats, and customer language shift, so the inputs no longer look like what the system was set up for), and the platform drifts (the vendor updates the underlying model, and behavior that your workflow depended on quietly changes with it). A system that hit 96 percent accuracy at go-live is not entitled to 96 percent in month six. Nothing broke, in the sense that anyone will get an alert. It just got worse, the way a supplier's quality gets worse, and you catch it the same way: by measuring incoming quality forever, not once at onboarding.

The measuring discipline has a name: evaluation, or in vendor dialect, "evals." An evaluation is a fixed, representative test set of your real cases with known correct answers, run against the system on a schedule, producing a score you can trend. It is the AI equivalent of the calibration check on a measuring instrument. No evaluation, no early warning; the first sign of drift becomes a customer, an auditor, or a regulator. When a vendor quotes "99 percent accuracy," the entire meaning of that figure lives in the eval behind it: measured on whose data, which cases, how recently, and can you rerun it on yours before signing. A benchmark you cannot rerun is a screenshot of someone else's speedometer.

The questions this section arm you to ask: "How does the system behave when it is unsure, and can it decline to answer? What is the evaluation set, can we run it on our own cases before purchase, and how do we know in month six that it still works? Who watches the score, and what threshold triggers action?"

The Autonomy Terms: Agent, Orchestration, and Guardrails

No word in the 2026 vendor lexicon carries a wider gap between what is said and what is shipped than agent. Properly used, it means an AI system that does not just answer but acts: it plans steps toward a goal, uses tools (querying systems, filling forms, sending messages, updating records), observes results, and adjusts, all with limited human intervention per step. That is a meaningful and genuinely new category of software, and it is also a word under industrial-scale abuse. Gartner analysts examining the market in 2025 warned of widespread "agent washing" and estimated that of the thousands of vendors claiming agentic products, only around 130 were judged to be the real thing. The renamed chatbot, the rules-based workflow with one AI call in the middle, the RPA bot with a new logo: all marching under the agent banner, priced accordingly. The same Gartner research predicted that over 40 percent of agentic AI projects will be canceled by the end of 2027, and mislabeled purchases will be a healthy share of the corpses.

Two companion terms tell you whether an "agent" was built by adults. Orchestration is the coordination layer that sequences the work: which step runs when, what happens on failure, where the process pauses for a human decision, how multiple models or tools hand off to one another. When a vendor cannot walk you through their orchestration, what they have is a demo, not a system. Guardrails are the engineered limits on what the AI may do: which tools it can invoke, which records it can touch, spending and volume caps, permission boundaries, mandatory human approval on designated actions, and, critically, an action log (an audit trail of every step the agent took) plus a rollback path for undoing what it did. This is Chapter 1's accountability principle wearing its technical clothes: autonomy is bought in units of control. An agent that can update your ERP is exactly as trustworthy as the guardrails around it, no more.

The instant diagnostic for agent-washing costs you one sentence in the meeting: "Show me the action log from a production deployment, and show me the rollback." A real agent vendor has both on screen in ninety seconds, because their own engineers cannot live without them. A rebranded chatbot vendor asks to get back to you.

If you cannot define the term, you cannot scope the purchase, and the vendor will happily scope it for you.

Worked Example: Six Terms Against a Forty-Minute Pitch

Here is the whole lesson run at match speed, in a hypothetical composite assembled from patterns that will be familiar to anyone who has sat through a 2026 procurement cycle. All companies and numbers are fictional and indicative.

Bellwether Freight, a 600-person logistics firm, is pitched "OpsMind" by Cardamom Systems: a "self-learning AI operations agent that reads all your documentation and autonomously resolves exceptions." Proposed platform fee: $300,000 a year. The operations director, one lesson deep into a certification like this one, keeps a glossary card flat on the table and annotates the pitch in real time. Six moments decide the deal.

Minute 6: "self-learning." Question: training or inference? After some weather, the honest answer arrives: the model's weights never change; Cardamom's team revises prompt templates "regularly," which under further questioning means most weeks, manually. Annotation: maintenance, not learning. The $80,000 "continuous learning module" line becomes a support clause at a support price.

Minute 12: "reads all your documentation." Question: context window in pages, and what happens on overflow? Answer: roughly 32 pages per request; longer inputs are truncated, silently. Bellwether's average carrier contract runs 85 pages. Annotation: "all" means "the first third, without telling you." The claim shrinks to a document-chunking feature that needs verification design around it.

Minute 18: "grounded in your knowledge base." Question: grounded on what, retrieved how, citations clickable? Answer: retrieval from one indexed folder, refreshed nightly; citations "on the roadmap." Annotation: a RAG system without citations is a hallucination lesson waiting to be re-learned at production volume, and the corpus governance question ("who keeps that folder current?") has no owner. Deal condition: citations at go-live or no go-live.

Minute 24: "the agent resolves exceptions end to end." Question: show the action log and the rollback. Long pause. What OpsMind actually does is run a fixed rules workflow with a single model call that drafts an email a human then sends. Annotation: that is a useful drafting tool wearing an agent costume, priced at agent altitude. The word "autonomous" comes off the table, and with it the autonomy premium.

Minute 31: "99.2 percent accuracy." Question: evaluated on what, and can Bellwether rerun the eval on 200 of its own historical exceptions before signing? The figure turns out to come from Cardamom's internal demo set. The rerun is agreed. It later scores 87 percent on Bellwether's real cases, which is genuinely useful for a drafting tool and nothing like 99.2. Annotation: an accuracy claim is worth exactly the eval you can rerun. A quarterly re-evaluation with a drift threshold (act below 85 percent) goes into the contract.

Minute 38: "we recommend the fine-tuning package," $120,000. Question: what did prompting and RAG fail to do, with evidence? There is no evidence, because they were never tried. Annotation: the ladder's bottom rungs are unclimbed; the top rung is decorative revenue.

The deal that eventually closes, this being a hypothetical with a tidy ending, is $60,000 a year: a scoped document-extraction and drafting tool with clickable citations, a rerunnable evaluation on Bellwether's own cases, a quarterly drift check written into the service terms, and a named internal owner for the retrieval corpus. Same vendor, same underlying technology, $240,000 of vocabulary. Nothing in the meeting required the operations director to know how a transformer works. Every single move was a defined term plus its question, asked calmly, with a pen ready.

The Artifact: The Vendor-Meeting Glossary Card

This lesson's artifact is the card that sat on that table. It is deliberately compact: one row per term, the operator-grade meaning, and the question the term arms you to ask. Print it, take it into the next pitch, and let it be visible; a vendor who sees a buyer with a glossary card recalibrates the pitch in real time, which is the cheapest due diligence you will ever perform.

Two usage notes. First, the card is a filter, not a weapon: the goal is not to humiliate a sales engineer but to make loose claims precise before they become contract clauses, and good vendors visibly relax when the questions get specific, because specific questions are how real products win. Second, the card compounds with everything you have built in this chapter: the failure-mode checklist from the 95 percent lesson tells you whether an initiative is set up to prove value; this card tells you whether the thing being purchased is what the words in the deck imply. Run both.

What to Do Monday Morning

1. Print the glossary card and put it in whatever you actually carry into meetings. A card in a drawer is a lesson; a card on the table is leverage.
2. Autopsy the last AI pitch your organization received (deck, proposal, or meeting notes) with the card beside it. Highlight every glossary term the vendor used and write, next to each, which precise meaning was in play. Expect at least three highlights where you honestly cannot tell; each one is a question for the next call.
3. Do the pages math once, for your own documents. Take your longest routinely processed document type, estimate its token count (words times 1.3 is close enough), and compare it against the context window of any tool in use or under consideration. If the document does not fit, find out today what the tool does with the overflow.
4. Ask the training-versus-inference question about one live tool. Pick any AI product your organization already pays for and get a written answer to "does our data change the model's weights, or is it supplied at inference time?" The answer matters for pricing, for privacy, and for what "it will get better" actually promises.
5. Draft your evaluation ask as boilerplate. Write the two sentences ("we will rerun your accuracy figure on a sample of our own historical cases before purchase; re-evaluation on a fixed set will run quarterly with an agreed action threshold") and hand them to whoever owns procurement templates. Sentences in the template outlive enthusiasm in the room.
6. Teach one term to one colleague before the week ends, using the scene, not the definition. The vocabulary only becomes organizational leverage when more than one person at the table has it.

This lesson closes the chapter on what AI actually is for process work: what the machine does, where it breaks, what the words mean when money is on the table. The next chapter turns the lens around, from the technology to your organization, and asks the question the whole certification hangs on: whether your people, processes, data, and governance are actually ready for what you now understand.

Key Takeaways

• Treat vocabulary as negotiating leverage: every loosely defined term in a vendor meeting has a price, and the party with the precise definition is the party that sets it.
• Separate training from inference before discussing money: "the model learns from your data" usually means inference-time context or manual prompt maintenance, not training, and the three differ in cost by orders of magnitude.
• Convert tokens and context windows into pages of your own documents, and demand to know what happens, visibly, when an input exceeds the window, because overflow is silently unread.
• Interrogate grounding as a chain: RAG is only as good as its retrieval step and its corpus governance, so ask "grounded on what, retrieved how," and require clickable citations.
• Climb the customization ladder from the bottom: prompting first, RAG when your changing documents demand it, fine-tuning only against evidence that the cheaper rungs failed.
• Refuse confident tone as evidence: calibration is what current systems lack by default, so a system that never says "I am not sure" has no gauge, not a full tank.
• Test every "agent" claim with one sentence, "show me the action log and the rollback," remembering Gartner's finding that of thousands of claimed agentic vendors, only around 130 were judged real.
• Plan for drift from day one: write a rerunnable evaluation on your own cases into the contract, score it quarterly against an agreed threshold, and make "how do we know it still works in month six" a standing agenda item.