Promptcraft for Human-AI Collaboration

How a Language Model Produces an Answer

A language model starts with the text you provide. It breaks that text into small pieces called tokens. A token may represent a whole word, part of a word, punctuation, or a space. The model then uses patterns learned during training to estimate what token should come next. It repeats that process until it reaches a stopping point or a length limit.

That process explains both the model’s strength and its weakness. If you ask, “Write a friendly reminder about tomorrow’s appointment,” the model has seen many examples of reminders, friendly wording, dates, and appointments. It can combine those patterns quickly. If you ask, “What was the exact reason this customer missed the appointment?” but provide no record, the model still has to produce something. It may fill the gap with a plausible reason because the request invites a complete answer.

The model does not check truth in the same way a person checks a source. It selects likely language. A response can therefore sound certain even when the model lacks enough information. This behavior often receives the plain-language label “hallucination”: an invented detail presented as though it belongs in the answer. The model may also misunderstand an unclear request, follow the wrong part of a long instruction, or combine true facts in a misleading way.

Use the Prompt Engineering Mindset Shift to handle this behavior. Treat every response as a draft produced under conditions you control. Your job involves setting those conditions, showing the model the relevant material, defining the required result, and checking the output before anyone relies on it.

1. Name the job. State exactly what you want the model to produce. “Write a 120-word appointment reminder” gives the model a clearer target than “Help with customers.” A clear job reduces irrelevant output because the model has fewer possible directions to follow.

2. Supply the facts. Add the information the model must use, such as the appointment date, cancellation rule, business name, or product details. The model cannot reliably recover facts that you never provide. Supplying them also gives you something concrete to compare against the final answer.

3. Set boundaries. Tell the model what it must not invent and what it should do when information is missing. For example: “Use only the policy below. If the policy does not answer a question, write ‘Not stated in the policy.’” This rule blocks the model from filling every gap with a guess.

4. Choose the form. Specify the length, audience, tone, and layout. Ask for a short email, a three-row table, or five numbered steps when that structure helps someone use the answer. A defined form makes errors easier to notice.

5. Check the result. Compare names, dates, prices, measurements, and claims against your source. Read the answer as a draft, not as proof. The more costly the mistake, the more carefully you should verify it.

Consider this prompt: “Tell me about our refund policy.” It leaves the model to guess the business, the policy, the audience, and the desired format. A stronger version says: “Using only the policy text below, write a plain-English reply to a customer whose unopened item arrived 12 days ago. State whether the customer qualifies for a refund, mention the required receipt, and keep the reply under 100 words. If the policy does not answer a point, say so instead of guessing.”

Ask yourself three questions whenever an answer sounds unusually certain: What information did the model actually receive? Which sentence proves the claim? What should the model have said if the information was missing? These questions turn suspicion into a repeatable check. The key takeaway: a model’s confidence belongs to its wording, not necessarily to its knowledge.

A Policy Reply Under Controlled Conditions

A small shop needs a consistent reply to refund questions. Its written policy says:

• Customers may request a refund within 30 days of purchase. - The item must be unopened and unused. - The customer must provide a receipt. - The policy does not explain who pays return shipping.

The shop wants a reply for a customer who bought an unopened item 12 days ago but did not mention a receipt. Here is a practical application of the Prompt Engineering Mindset Shift.

1. Define the job in one sentence. Write: “Draft a customer reply that explains whether the request appears eligible under the policy and identifies the missing requirement.” The expected outcome is a useful reply, not a general summary of retail law.

2. Paste the source policy. Include all four points exactly as the working material. The expected outcome is a response tied to the shop’s actual rules rather than a generic refund answer.

3. Add the known customer facts. State: “The purchase happened 12 days ago. The item remains unopened and unused. The customer has not said whether they have a receipt.” The expected outcome is a clear separation between confirmed facts and missing information.

4. Set the no-guess rule. Add: “Use only the policy provided. Do not decide who pays return shipping because the policy does not state it. If the receipt requirement remains unconfirmed, ask the customer to provide one.” The expected outcome is protection against a confident but unsupported promise.

5. Set the output limits. Request: “Write 70-100 words in a polite, plain-English email. Do not mention artificial intelligence. Do not add legal advice.” The expected outcome is a message the shop can review and send with little editing.

6. Inspect the draft against the source. Check the 30-day period, the 12-day timing, the unopened condition, the receipt requirement, and the unanswered shipping question. The expected outcome is a reply that contains no new policy terms.

A suitable result might say that the request appears to meet the 30-day and unopened-item conditions, but the customer must provide a receipt before the shop can process the refund. It should avoid claiming that the shop will pay return shipping. If the model writes, “We will send a prepaid label,” the smooth sentence signals a failure: the policy never supplied that fact.

Quick checklist

• State one specific job. - Paste the facts the model must use. - Mark unknown information clearly. - Tell the model what to do instead of guessing. - Set a useful length and format. - Compare every important claim with the source. - Treat unsupported confidence as an error, not as evidence.

This exercise shows the mindset in action. The model can organize language, adjust tone, and produce a clean draft. You still control the facts, the limits, and the final decision.

Where the Mindset Breaks Down

Mistaking fluent wording for understanding

A model can explain a subject in a calm, professional voice without understanding the situation behind the words. It may produce a convincing repair instruction while missing the model number, a safety condition, or a measurement.

Do this: Ask the model to list the facts it used and identify any missing information before it gives the recommendation. Then verify safety-critical details against the manufacturer’s instructions or another trusted source.

Not this: “Give me the correct repair for this machine,” followed by no model number, symptoms, or manual.

The fix works because it forces the model to expose the limits of its input. A polished paragraph cannot replace the missing details.

Allowing the model to fill gaps

Users often request a complete answer even when the source leaves a question unanswered. The model tends to honor the request for completeness, which can lead it to invent a return deadline, a delivery date, or a customer history.

Do this: Add a stop rule: “If the information is not in the supplied material, write ‘Not provided.’” For important work, ask for a separate “Unknowns” section.

Not this: “Make the answer sound helpful and fill in anything needed.”

The first instruction values accuracy over smoothness. The second rewards invention, even if you never intended to request it.

Failing to check a high-cost answer

A wrong word in a casual social post may cause little harm. A wrong dosage, contract term, financial figure, or safety instruction can create serious problems. The model does not know the cost of its error unless you explain the stakes and apply a review step.

Do this: Divide outputs into low-risk drafts and high-risk decisions. For high-risk work, require source citations from the material you provide, ask the model to flag uncertainty, and have a qualified person review the result before use.

Not this: Copying a confident answer directly into a customer policy, medical instruction, legal notice, or safety procedure.

The Prompt Engineering Mindset Shift does not mean distrusting every sentence. It means matching your checking effort to the consequences of being wrong. Use the model for speed and structure, but keep responsibility for facts and decisions where it belongs.

A language model becomes more useful when you stop asking whether it “knows” the answer and start asking what conditions produced it. Give it a defined job, reliable material, clear limits, and a review process. Then its fluency becomes a tool you can manage rather than a performance you must blindly trust. That shift - from magic to engineering - sets the foundation for every stronger prompt you build.

End of chapter one. 31 more chapters in the full book.