It is 6:50 in the morning and Maria, a process engineer on a stamping line, has nine minutes before the production meeting. Line 3 threw a new fault overnight, the night shift left two lines of scrawl on the traveler, and she needs a plain-language summary of what the operators should check first. She opens a chatbot and types "why is my press faulting." Ten seconds later she has a confident, beautifully formatted answer that recommends a hydraulic pressure of 2,500 PSI and a die clearance of "approximately 10 percent of material thickness." It looks authoritative. It is also completely untethered from her actual press, her actual material, and her actual drawing. The 2,500 PSI is a number the model invented because the question gave it nothing real to stand on. If Maria pastes that into a work instruction, she has just handed her green crew a fabricated spec with her name on it. The problem was not the AI. The problem was the prompt. A vague question gets a confident, generic, and dangerous answer. A grounded question gets a useful one. This lesson is about the difference, because on a shop floor that difference is measured in scrap, false rejects, and the one defect escape you cannot afford.

Why a Vague Prompt Is a Loss Event

A large language model does not look up answers in a database. It predicts the most likely next words given what you typed. When you give it almost nothing, it fills the gap with the most statistically common pattern from its training data, which is a generic internet average of every press, every material, and every plant on earth. That average is rarely your plant. The model is not lying; it is doing exactly what it was built to do, which is produce a fluent continuation. The fluency is the trap. A wrong torque spec written in confident, well-formatted prose reads exactly like a right one.

Consider the real cost. Suppose Maria's line runs 1,200 parts per shift and a defect escape last quarter shipped 4,000 parts before anyone caught it, turning into a customer containment. The playbook is blunt about why this keeps happening: 85 percent of manufacturers say staffing shortages are hurting product quality, the experienced people are retiring, and the new crew has never seen this machine fail this way before. A green operator handed a fabricated 2,500 PSI spec has no internal alarm that says "that number looks off." The veteran would have squinted at it. The new hire trusts the page. So the prompt that produced the page is not a convenience question. It is a quality-control decision, and right now it has no controls on it at all.

Here is the reframe that makes the rest of this lesson click. A prompt is not a search query. It is a work order you are writing for a very fast, very literal, very confident assistant who has never set foot in your plant. You would never hand a contractor a work order that said "fix the thing." You would give them the drawing, the spec, the tolerance, the standard, and the acceptance criteria. The same discipline that makes a good work order makes a good prompt. The reader who already lives in the MES (Manufacturing Execution System, the software layer that runs and records production) and the quality system already knows how to write a precise instruction. The skill transfers directly. You just have to do it on purpose every time, because the AI will never ask you for the missing context. It will simply invent it.

A prompt is a work order for a fast, literal assistant who has never seen your plant. Vague in, fabricated out.

Context Is the Drawing You Attach

The single highest-leverage thing you can add to a prompt is context: the specific facts that pin the model to your reality instead of the internet average. Think of it as attaching the drawing to the work order. Without the drawing, the contractor guesses. With it, the contractor builds to spec.

Context on the floor has a predictable shape. It is the equipment (make, model, line, station), the material (alloy, grade, gauge, condition: is the part wet, oily, painted), the process parameters you actually run, the defect or symptom in concrete terms, the standard or customer that governs the part, and the audience who will read the output. Compare the two prompts below and notice that the second one is not longer because it is wordy. It is longer because every clause removes a guess.

Weak: "Why is my press faulting and what should I check?"

Grounded: "I run a 400-ton mechanical stamping press, station 3, forming 1.2 mm cold-rolled 1008 steel. Overnight it threw fault code E-217, which our manual lists as a tonnage-overload trip. The traveler notes say the fault started after a coil change. The crew on shift now is two operators with under six months of experience. Using only the symptoms I gave you, list the five most likely causes in order, what to physically check for each, and flag anything you cannot determine without more data. Do not invent pressure or clearance numbers; if a spec is needed, tell me to pull it from the die drawing."

The grounded prompt cannot produce the fabricated 2,500 PSI answer, because it explicitly forbids invented numbers and tells the model where the real number lives. It also gives the model the audience (green crew), which shapes the output toward checkable physical actions instead of theory. This is the difference between a generic essay and a triage list a new operator can actually run. It took Maria ninety seconds longer to write. It saved her from putting a fabricated spec into a work instruction that the customer can audit.

The brownfield reality changes what context you have

Most readers are not in a gleaming greenfield plant with a clean digital twin feeding the model live data. The playbook is honest that greenfield plants deploy AI 40 to 60 percent faster precisely because their data is already structured and reachable. You are probably running a 1990s PLC (Programmable Logic Controller, the industrial computer that runs the machine's logic) and a historian (the time-series database that stores tag values like temperature and pressure over time) that nobody has queried in years. That means the context you paste into a prompt is often the only context the model will get, because you cannot wire it to live tag data yet. In a brownfield plant, your prompt is carrying more weight, not less. The discipline matters more, not less, because there is no automated grounding layer behind it to catch your omissions.

Units and Tolerances, or It Is Not a Spec

On the floor, a number without a unit and a tolerance is not a spec. It is a rumor. "Torque the bolt to 25" is meaningless. Twenty-five what? Newton-meters? Foot-pounds? Inch-pounds? The difference between 25 Nm and 25 ft-lb is roughly a factor of 1.36, which is the difference between a properly seated fastener and a stripped thread or a joint that backs out in service. Generative AI is notorious for dropping units, silently converting them, or stating a value with false precision like "approximately 24.7 Nm" when the real spec is a range. You must demand units and tolerances explicitly, and you must check them on the way out.

Walk through a concrete case. A maintenance tech asks an AI to help write a torque sequence for a pump flange. The model returns "tighten bolts to 80 in a star pattern." The tech, under pressure and short two people, almost runs with it. The actual drawing calls for 80 ft-lb plus or minus 5, applied in three passes (30 percent, 60 percent, 100 percent), in a star pattern. The AI's "80" with no unit, no tolerance, and no staged sequence is not just incomplete. It is the kind of instruction that produces a flange leak, an unplanned shutdown, and a hunt for a root cause that was actually authored by a sloppy prompt. The fix is to make units and tolerances a required field in your prompt, exactly as they are a required field on a drawing.

Force the model to be explicit. Build the requirement into the instruction: "State every numeric value with its unit and its tolerance. If the drawing gives a range, give the range, not a single number. If you do not have the tolerance, say 'tolerance not provided, pull from drawing,' and do not guess." This one sentence converts the model from a confident guesser into a tool that flags its own gaps. It will not catch everything, which is why human verification still owns the final number, but it dramatically cuts the rate of silent unit drops.

Ranges, conversions, and the rounding trap

When you ask for a unit conversion, never accept it blind. Models routinely produce conversions that are off by a rounding step or that flip the direction. If you need 1.2 mm sheet expressed in inches for a customer print, the answer is about 0.047 inch, and you should sanity-check it against a known anchor (1 inch is 25.4 mm, so just over a millimeter is just under five hundredths of an inch). The thirty-second mental check is cheaper than a batch of parts cut to a hallucinated dimension. Treat every AI-produced number the way you treat a measurement from a gauge you have not calibrated lately: useful as a starting point, not as a record until verified.

"Cite the Spec": Grounding the Model on Real Documents

The most powerful prompting move in a manufacturing context is the instruction "cite the spec." It means: do not answer from your general training; answer from the document I am giving you, and tell me exactly where in that document the answer came from. This is the floor-level version of what the AI world calls grounding or RAG (Retrieval-Augmented Generation, where the model is forced to base its answer on specific source documents you provide rather than on its memory). You do not need to understand the plumbing to use the discipline. You just have to paste the real document and demand that the answer trace back to it.

The mechanics are simple. Instead of asking "what is the torque spec for this flange," you paste the relevant section of the drawing or the procedure and ask: "Using only the text I pasted below, state the torque spec, the tolerance, and the sequence. Quote the exact line you used. If the answer is not in the text I provided, say 'not found in provided document,' and do not fill it in from your own knowledge." Now the model is reading your drawing, not the internet. When it quotes the line, you can verify in one glance that it read the right row. When it says "not found," you have learned something true: the spec is not where you thought it was, and you need to go find it rather than ship a guess.

This is also the move that survives the customer audit. The playbook's cardinal rule for this program is that the customer audits you, not the vendor, and "the model flagged it" is never a sufficient answer to an auditor. When your prompt forces the model to cite the source line and you keep that source alongside the output, you have an audit trail. You can show the auditor the drawing, the quoted line, and the human who verified the match. Without grounding, you have a confident paragraph and no way to prove where it came from, which is exactly the position no quality engineer wants to be in across the table from a customer.

The refusal you want. A grounded prompt should make the model comfortable saying "I do not have that." That refusal is a feature, not a failure. An AI that says "the tolerance is not in the section you pasted" has just done your job for you by catching a gap before it reached the floor. An AI that confidently fills the gap with a plausible number has set a trap. Reward the refusal. Build prompts that make refusal the safe default whenever the source does not contain the answer.

Audience, Format, and the Shape of Useful Output

A correct answer in the wrong shape is still a failure on the floor. The same fact has to land differently for a green operator at the machine, a maintenance tech writing a CMMS (Computerized Maintenance Management System, the software that holds equipment records and work orders) entry, and a quality engineer drafting an 8D (the eight-discipline structured problem-solving report customers require). Telling the model who will read the output and what shape you need is not a nicety. It is what turns a generic essay into something that goes straight into the system your plant actually runs on.

Specify the audience in floor terms. "Write this for an operator with under six months of experience, at a seventh-grade reading level, as a numbered checklist of physical actions" produces something a new hire can follow at the machine. "Write this as a CMMS work-order description: symptom, suspected cause, parts likely needed, and estimated labor, in under 100 words" produces something that drops cleanly into the maintenance system. Same underlying facts, two completely different and equally useful outputs, both shaped by one sentence in the prompt.

Format control also protects against the wall-of-text problem. A model left to its own devices will write five paragraphs when you needed a five-row table. On a line where the operator has fifteen seconds between parts, the table wins every time. Ask for the structure you want: a table with named columns, a numbered list, a fixed set of fields. The playbook for the program later teaches structured output for MES systems in depth, but the basic move starts here in prompting: name the format, name the fields, name the length. The model is happy to comply, and your downstream system, whether that is a paper traveler or the MES, accepts the result without rework.

A worked example: the same defect, three audiences

Maria has a recurring burr on a stamped bracket. She wants three things from one set of facts. First, for the operator: "Write a 5-step visual check for this burr at the machine, numbered, plain language, no jargon." Second, for the CMMS: "Write a maintenance work-order line: the burr suggests a worn die edge at station 3; describe the symptom, the suspected cause, and the inspection needed, in under 80 words." Third, for the quality file: "Draft the 'problem description' section of an 8D for this burr, stating the defect, the affected part numbers, the quantity at risk, and the containment already in place; do not propose a root cause yet, since that requires verification." Three prompts, three correct shapes, one underlying reality. The skill is not writing more; it is telling the model precisely what good looks like for each reader.

Iterate, Verify, and Own the Output

A good prompt is rarely the first prompt. The professional move is to treat the first answer as a draft and steer it, the way you would coach a capable but green technician. If the model invents a number, call it out: "You stated a pressure I did not give you. Remove it and flag where it should come from." If it is too long, say "cut this to a ten-line checklist." If it missed the audience, redirect: "This is too technical for a new operator; rewrite at a seventh-grade level." Each turn tightens the output. The cost is a minute. The payoff is an output you can actually use and defend.

Verification is where the discipline becomes non-negotiable, and it is the spine of this entire program. The playbook states it plainly: the job shifted from "produce the draft" to "verify the draft against the drawing, the standard, and the historian." A prompt, no matter how well built, does not relieve you of checking the result against the real source. Every number gets traced to the drawing. Every procedure gets checked against the actual process. Every root cause gets validated against the historian trace and the maintenance history, not accepted because it reads well. The prompt makes the draft faster and cleaner. The human makes it true.

Put a dollar value on why this is worth the minutes. A single defect escape that becomes a customer containment can cost more than a month of a reskilling program, per the playbook's well-dig. A flange torqued to a hallucinated value can mean an unplanned shutdown on a line where downtime is the tallest bar on the loss chart. Against those numbers, the ninety seconds it takes to write a grounded prompt and the few minutes it takes to verify the output are the cheapest insurance in the plant. The reader who builds this into a habit is not slowing down. They are the one who stops shipping fabricated specs while everyone else is still pasting "why is my press faulting" into a chatbot and trusting the answer.

Accountability does not transfer to the tool. When you sign the work instruction, the traveler, or the 8D, you own every number on it, including the ones the AI drafted. "The model wrote it" is not a defense to an auditor, a customer, or your own conscience when a green operator follows a fabricated spec into a bad part. The prompt is your tool. The verification is your signature. Keep the two clearly separated in your own mind and you will get the speed of AI without inheriting its confidence in things that are not true.

Key Takeaways

• A prompt is a work order for a fast, literal assistant who has never seen your plant, not a search query. Vague questions produce confident, generic, fabricated answers, and on the floor a fabricated spec is a quality-control failure with your name on it.
• Context is the drawing you attach: equipment, material, real process parameters, the concrete symptom, the governing standard or customer, and the audience. Every clause you add removes a guess the model would otherwise fill with the internet average.
• A number without a unit and a tolerance is a rumor, not a spec. Force the model to state every value with its unit and tolerance, give ranges as ranges, and flag missing tolerances instead of inventing them. The 25 Nm versus 25 ft-lb gap is a stripped thread waiting to happen.
• "Cite the spec" is the highest-leverage move: paste the real drawing or procedure and require the answer to quote the exact source line or say "not found in provided document." This is grounding, it survives the customer audit, and the refusal you get is a feature, not a failure.
• Tell the model who will read the output and in what shape. The same fact must land as a 5-step operator checklist, an under-100-word CMMS work order, or an 8D problem description. A correct answer in the wrong shape still fails on the floor.
• Iterate the draft like you would coach a green tech, then verify everything against the drawing, the standard, and the historian. The job shifted from producing the draft to verifying it; the prompt makes the draft fast, the human makes it true.
• In a brownfield plant running a 1990s PLC and an unqueried historian, your pasted context is the only grounding the model gets, so prompting discipline matters more, not less, because nothing automated is behind it to catch your omissions.
• Accountability never transfers to the tool. When you sign the instruction, the traveler, or the 8D, you own every number on it, including the ones the AI drafted. The prompt is your tool; the verification is your signature.