Priya runs continuous improvement at a mid-size plant, and she has spent three months teaching her team to write grounded prompts. It worked, mostly. Then she audited a week of AI output and found the same three mistakes scattered across every shift. An operator on Line 2 got a torque value in foot-pounds when the whole plant runs metric. A new quality tech accepted a root cause the AI invented because nobody told it to refuse when the data was thin. A maintenance lead got a work instruction written at a college reading level for a crew that reads at a seventh-grade level in a second language. None of these people wrote a bad prompt. They each wrote a decent prompt and forgot one thing, because remembering all of it, every time, on a hot afternoon, is not a human strength. The veteran who knew the plant ran metric, knew to demand a citation, and knew the crew's reading level, that veteran retires in November. Priya's realization is the subject of this lesson: the rules that make AI safe on the floor cannot live in each person's memory and each individual prompt. They have to be set once, in a system prompt, so that every conversation starts from the plant's reality instead of the internet's. A system prompt is the standing work order that every AI session inherits before anyone types a word.

What a System Prompt Is, in Floor Terms

Most AI tools let you set two kinds of instruction. The first is the message you type each time, the user prompt, which changes with every question. The second is a standing instruction that applies to the entire conversation or to every conversation by default. That standing instruction is the system prompt. It is set once, by whoever configures the tool, and the model treats it as the rules of the room before any user question arrives. Think of it as the difference between the specific job on today's work order and the plant standard operating procedure (SOP) that governs how every job on that line gets done. The user prompt is today's job. The system prompt is the SOP.

On the floor this distinction is the whole game. A user prompt is written by a tired operator with nine minutes before the production meeting, and it will be incomplete because humans under pressure are incomplete. A system prompt is written once by someone with time to think, reviewed, and then applied automatically to every session that operator runs. The operator no longer has to remember that the plant runs metric, that numbers need tolerances, that the AI must cite the source or refuse. The system prompt remembers for them. The playbook frames the destination for this chapter as locking specs, units, and a cite-or-refuse rule into a reusable form, and that is precisely what a system prompt does: it moves the safety rules out of fragile human memory and into the configuration.

Here is the reframe. You already standardize the things that must never vary. You do not let each operator decide the PPE rules or the lockout-tagout sequence; those are set once and applied to everyone. AI behavior on technical work is the same category of thing. The plant's units, its citation requirement, its refusal behavior, its reading level, and its accountability stance are not preferences to be re-decided every prompt. They are standards. A system prompt is where standards live so that a thinner, greener crew inherits them automatically instead of being expected to recreate them under pressure.

A user prompt is today's job. A system prompt is the SOP that governs every job. Put the rules that must never vary in the SOP, not in each tired operator's memory.

Lock the Plant Reality: Units, Specs, and Conventions

The first job of a plant system prompt is to pin the model to your plant's physical conventions so that no individual prompt has to. The most common silent error in technical AI output is the unit, and the previous lessons showed why: the model defaults to whatever was most common in its training data, which is often imperial when your plant is metric, or a bare number with no tolerance at all. You fix this once, in the system prompt, for every conversation.

A plant-reality block in a system prompt states the standing facts. It names the unit system: "This plant runs metric. Express all dimensions in millimeters, all torque in newton-meters, all pressure in bar, all temperature in Celsius. If a source document uses other units, convert and show both, and state the conversion factor you used." It names the numeric discipline: "Never state a numeric specification without its unit and its tolerance. If a tolerance is not available in the source, write 'tolerance not provided, pull from drawing' and do not invent one." It names the conventions specific to the plant: the asset-numbering scheme, the fault-code format, the standard the plant is audited against, like IATF 16949 (the automotive quality management standard the customer audits you against) or AS9100 (the aerospace equivalent). Now every session inherits these without the operator typing them.

Put a number on what this buys. Recall Priya's operator who got foot-pounds in a metric plant. If that value, say 70 ft-lb, gets read as 70 Nm by a green crew, the joint is undertorqued by roughly a factor of 1.36 and backs out in service, or the reverse overtorques and strips it. Either way it is a downtime event on a line where downtime is the tallest bar on the loss chart, and a single defect escape that becomes a customer containment can cost more than a month of the team's training. The system prompt that locks the unit system makes that specific error structurally hard to produce, because the model is told before every question that this plant is metric and must show its conversions. You did not catch the error after the fact. You designed the room so the error could not casually happen.

Encode the standard you are audited against

If your customer audits you to a specific standard, the system prompt should name it and constrain the model to it. A line: "All quality and process output must be consistent with IATF 16949. Do not assert a requirement of the standard unless it is present in a source document I provide; if asked about a requirement, either cite the provided source or say the requirement was not provided." This stops the model from inventing a plausible-sounding standard requirement, which is one of the playbook's named failure modes. The customer audits you, not the vendor, and a system prompt that forbids the model from fabricating requirements is part of how you stay defensible across the table from that auditor.

The Cite-or-Refuse Rule, Made Permanent

The most important single line in a plant system prompt is the one that makes the model cite its source or refuse to answer. The previous lessons taught this as a per-prompt move. The reason to move it into the system prompt is that the per-prompt version fails exactly when you need it most: under pressure, when the operator forgets to add it. A new tech facing a thin data set and a confident model will accept an invented root cause unless the rules of the room already forbid the model from inventing one. The system prompt makes refusal the default behavior instead of something each user has to request.

The cite-or-refuse rule has two halves, and a plant system prompt needs both. The citation half: "When you answer using a document I have provided, quote the exact line or section you used so I can verify it. Do not paraphrase a spec without pointing to its source." The refusal half: "When the information needed to answer accurately is not in the documents I provided, reply that the answer is not available in the provided sources and state exactly what is missing. Do not fill the gap from your general training. A refusal with a clear statement of what is missing is the correct and preferred answer when the source does not contain the information."

That last sentence does real work. Models lean toward being helpful, and helpfulness in a vacuum becomes fabrication. By writing into the system prompt that a refusal is the preferred answer when the source is silent, you re-tune the model's instinct for the floor, where a confident guess is worse than an honest "I do not have that." Walk through Priya's second mistake, the invented root cause. With cite-or-refuse in the system prompt, the new quality tech's session starts with the model already required to refuse when the historian (the time-series database that stores tag values like temperature, pressure, and vibration over time) trace and the maintenance history do not actually support a cause. The tech cannot accidentally accept a fabrication, because the model was told before the conversation began that it must say what is missing instead of inventing a conclusion. That is the difference between hoping every user remembers the rule and building the rule into the room.

Why refusal protects the audit trail

An AI that refuses when the source is silent produces a clean record: the question, the documents provided, and an honest gap. An AI that fabricates produces a record that looks complete and is wrong, which is the worst kind of record to have when a customer audit pulls the file. The playbook's cardinal rule for this program is that "the model flagged it" is never a sufficient answer to an auditor. A system prompt that enforces cite-or-refuse means every AI-touched answer in your plant either traces to a real source or openly names its gap, which is exactly the documentation posture an audit rewards.

Set the Audience and the Accountability Stance

Two more standing facts belong in a plant system prompt because they almost never change session to session: who reads the output and who owns it. Priya's third mistake was a work instruction written at a college reading level for a multilingual crew that reads at a seventh-grade level. That is not a per-prompt failure to fix one instruction at a time. It is a standing fact about her plant that should shape every operator-facing output the AI ever produces.

The audience block states the default reader and lets the user override it when needed. A line: "Unless I specify otherwise, write operator-facing content for a reader with under one year of experience, at a seventh-grade reading level, in short numbered steps describing physical actions, avoiding jargon and acronyms unless they are defined in the same line. When I ask for content for an engineer or a CMMS (Computerized Maintenance Management System, the software that holds equipment records and work orders) record, I will say so." This makes the safe, plain-language default automatic and keeps the model from drifting into the dense technical prose it produces by default. The playbook ties this directly to the talent cliff: with 85 percent of manufacturers saying staffing shortages are hurting product quality and a thinner, greener crew running the line, instructions that a new hire can actually follow are not a nicety, they are a quality control.

The accountability block sets the model's stance toward its own role. A line: "You are an advisory drafting tool. A human will verify your output against the drawing, the standard, and the historian before it becomes a record or reaches the floor. Present your output as a draft to be verified, not as a final answer. Do not express certainty about specifications, root causes, or procedures that the human has not confirmed against a source." This is the system prompt teaching the model to behave like the assistant the playbook describes: it assembles the evidence, the human owns the conclusion. It also quietly protects the crew, because a model that frames its output as a draft to verify is a model that does not lull a tired operator into treating a guess as gospel.

A worked block: the full skeleton

Assembled, a plant system prompt has a predictable skeleton, and every plant should write its own version of these blocks: a plant-reality block (units, conventions, the audited standard), a cite-or-refuse block (quote the source, refuse with a stated gap when silent), an audience block (default reader and reading level), and an accountability block (advisory, draft-to-verify, no false certainty). None of these blocks is clever. Each one simply takes a rule the previous lessons taught as a per-prompt habit and makes it permanent, so the rule survives the moment the operator is too rushed to remember it. The skill is not inventing new rules. It is deciding which rules must never vary and writing them into the room once.

Watch all four blocks save a single shift

Follow one real morning to see why the blocks matter together rather than one at a time. A second-shift operator, eight months in, hits a recurring flash defect on a molded part and asks the configured AI assistant to help him write a quick check for the next operator. Without a system prompt he would likely get a dense, imperial-unit, jargon-heavy paragraph that confidently names a root cause. With the plant system prompt in force, four things happen at once and none of them required him to remember anything. The plant-reality block keeps any barrel-temperature value in Celsius with a tolerance, matching his process sheets. The cite-or-refuse block makes the model say it cannot name the root cause from what he provided and ask for the historian trace, instead of inventing "worn vent" as a confident conclusion. The audience block produces a five-step, seventh-grade, numbered visual check the next operator can actually run. The accountability block stamps the output as a draft for the shift lead to verify before it goes on the line. One rushed question, four standards applied automatically. That is the entire point: the system prompt did the remembering so the thinned crew could do the work.

Now price the alternative. Without those blocks, the operator pastes the confident "worn vent" cause into the next traveler, the next operator chases a vent that is fine, the real cause (a moisture issue the historian would have shown) keeps producing flash, and a batch escapes to the customer. A single defect escape that becomes a containment can cost more than a month of the team's training. The system prompt did not just clean up the wording. It blocked the specific chain of events that turns a rushed question into a shipped defect.

Govern the Prompt: Test It, Version It, Own It

A system prompt is a controlled document, and it deserves the same governance as any other controlled document on the floor. The moment you centralize the rules, the system prompt itself becomes a single point of failure: a careless edit can silently change the behavior of every AI session in the plant. So you treat it like a work instruction under document control, not like a sticky note someone can change at will.

Test it before you deploy it, and test it the way you test a vision system. Build a small holdout set of known-answer cases: a few questions where you already know the correct spec, a few where the answer is deliberately not in the provided document so the model should refuse, and a few operator-facing requests where you can judge the reading level. Run the proposed system prompt against all of them. If it cites correctly on the known specs, refuses cleanly on the deliberate gaps, and produces seventh-grade steps on the operator requests, you have evidence it behaves. If it fabricates on a gap case, the prompt is not ready, exactly as a vision model that fails its holdout is not ready for the line. This is the same false-reject discipline the playbook teaches: you do not trust the behavior until you have measured it on cases where you know the truth.

Version it and log changes. Keep the system prompt under version control with a date, an author, and a note on what changed and why, the same as a revision block on a drawing. When an AI output is questioned in an audit or a root cause, you need to know which version of the rules was in force when that output was generated. A system prompt that drifts silently is as dangerous as a drawing revision nobody recorded. Assign an owner. One named person, typically the CI lead, a quality engineer, or a plant data lead, owns the prompt, approves changes, and reviews it on a schedule. Ownership is what keeps it from rotting as the plant, the standards, and the customer requirements change.

Remember the boundary: a system prompt constrains behavior, it does not guarantee it. A system prompt makes the safe behavior the strong default and the unsafe behavior much harder to trigger. It does not make the model incapable of error. A model can still misread a document, and a determined or sloppy user can still override instructions in some tools. So the system prompt sits inside the verification discipline, not in place of it. It raises the floor on every session, which is enormous when the crew is thin and green, but the human still traces every number to its source and signs the record. The playbook is unambiguous that accountability stays with the plant and the human who signs, and no system prompt changes that. It just makes sure the human starts every session from the plant's reality instead of the internet's.

Key Takeaways

• A system prompt is the standing SOP every AI session inherits before anyone types a word, while a user prompt is today's specific job. Rules that must never vary belong in the system prompt, not in each tired operator's memory under pressure.
• Lock the plant reality once: name the unit system, require every number to carry a unit and tolerance, and encode the asset-numbering, fault-code, and audited-standard conventions. This makes the metric-versus-imperial error that backs out a joint structurally hard to produce.
• Make cite-or-refuse permanent. Require the model to quote the exact source line, and to refuse with a clear statement of what is missing when the source is silent, declaring refusal the preferred answer. This stops a green tech from accidentally accepting an invented root cause.
• Encode the standard you are audited against and forbid the model from asserting a requirement that is not in a provided source. The customer audits you, not the vendor, and a fabricated standard requirement is a named failure mode this rule prevents.
• Set the default audience and reading level so operator-facing output is automatically short, numbered, seventh-grade, and jargon-light for a thinner, greener crew, with a clear way for the user to override it for engineer or CMMS content.
• Set the accountability stance: the model is an advisory drafting tool, its output is a draft to be verified against the drawing, the standard, and the historian, and it must not express false certainty about specs, causes, or procedures.
• Govern the system prompt as a controlled document: test it against a holdout of known-answer and deliberate-gap cases before deploy, version it with date and author, and assign one owner who approves changes on a schedule.
• A system prompt raises the floor on every session but does not replace verification. It makes safe behavior the strong default; the human still traces every number to its source and signs the record, because accountability stays with the plant and the person who signs.