Prompt engineering is the practice of designing a task request and its surrounding context so a model has a clear job, clear boundaries, and an answer that an application or person can evaluate. The useful starting point is not clever wording but a plain definition of success, because a prompt cannot reliably express a goal that the team itself has not made concrete. Success criteria are observable conditions that distinguish an acceptable result from an unacceptable one, such as requiring a security finding to name an affected system, describe an alleged weakness, explain a plausible impact, and point to supporting text. Decision criteria are the rules used to choose among outcomes, while an output contract specifies the fields, types, allowed states, and evidence that the response must contain.

A solid prompt therefore describes the task, supplies only relevant context, states constraints and exclusions, gives decision criteria, and defines the output contract. Instructions such as be accurate, careful, and professional may set a tone, but they do not explain what evidence is sufficient, which borderline cases should be rejected, or how uncertainty should appear. Harbour Resolution is a fictional organization we will use as a running example, and in this episode its team is hypothetically reviewing incoming correspondence for credible vulnerability claims. A weak instruction saying identify security issues leaves the model to invent its own boundary between a concrete report, a vague complaint, promotional language, and unsupported speculation.

A stronger version defines a positive result as correspondence that identifies an affected system, alleges a particular weakness, gives a plausible impact, and includes supporting text, while explicitly excluding generic dissatisfaction and claims without evidence. If the output includes severity, the prompt must define evidence-based thresholds for each severity level and specify how uncertain cases should be labelled or escalated rather than forcing a confident rating. Classification means assigning an input to a defined category, and the categories in this case might be credible claim, insufficient evidence, or unrelated correspondence. A false positive occurs when harmless or unsupported material is incorrectly placed in the positive category, while a false negative occurs when a qualifying claim is missed.

Harbour Resolution's hypothetical reviewer might see a message saying the customer portal is terrible and insecure, feel tempted to flag it because the word insecure sounds urgent, and then notice that it names no weakness, impact, or supporting observation. Under the better design, that message becomes insufficient evidence rather than a credible claim, although a human escalation route may still be sensible when the language suggests a serious but poorly expressed concern. Before reaching for a larger model, the team can often reduce ambiguity by making the task definition and the boundary between decisions clearer. Explicit criteria reduce arbitrary judgment, but they do not eliminate every hard case, because language can be incomplete, contradictory, or dependent on knowledge that the prompt does not contain.

The team should evaluate those criteria on representative material, meaning a collection that resembles the ordinary cases, unusual cases near the decision boundary, and costly mistakes the workflow is expected to encounter. Zero-shot prompting means asking the model to perform the task without worked examples, which can be efficient when the instructions and category boundaries are already clear. Few-shot prompting means including a small number of worked examples that demonstrate how the rules apply to concrete inputs and outputs. For the fictional correspondence review, useful examples would include an ordinary credible claim, an ordinary non-security complaint, and a near miss that sounds technical but lacks supporting evidence.

The near miss is especially valuable because it teaches the decision boundary rather than merely repeating an easy pattern. One tempting mistake is to paste in every example the team can find, but examples consume context, which is the limited body of information available to the model during that request. Too many similar examples can also cause overfitting, meaning the model follows accidental patterns in the examples instead of applying the intended general rule. For instance, if every positive example happens to mention a login page, the model may start treating login language as a hidden requirement even though the written criteria cover any affected system.

A better approach uses a small, varied set and keeps an example only when testing shows that it clarifies behavior the instructions did not already settle. Examples for extraction, which means locating specified facts in source material and placing them into named fields, should cover absent values, conflicting statements, multiple records, and awkward formatting. Consider a hypothetical accounts team extracting an invoice amount, effective date, and account identifier from uploaded documents. A worked example should show that a clearly absent amount remains absent, because inventing a number merely to fill a required field is a serious failure. Another example can show two different dates and identify which nearby label supports the effective date, so the model learns that choosing a correctly formatted date is not enough.

This leads to a crucial distinction between requested structure and enforced structure. JSON, which stands for JavaScript Object Notation, is a text format that represents objects, arrays, strings, numbers, true-or-false values, and null values in a machine-readable form. A prompt that says return JSON often improves consistency, but it remains a request, so the response might contain invalid punctuation, an unexpected field, explanatory prose, or the wrong kind of value. A schema is a machine-checkable description of the expected structure, including field names, data types, required properties, and allowed alternatives. A tool call is a structured request from the model for the application to invoke a named function with specified arguments, meaning the values that function receives.

On supported systems, Structured Outputs or a tool call using strict schema enforcement provides a stronger contract for the shape of that request. Merely offering a tool, or requiring the model to choose it, is not the same as enabling a supported mechanism that enforces the schema. Syntax concerns whether the output is structurally well formed, while semantics concerns whether the output means the right thing and is supported by the source. A schema can require the invoice amount to be numeric, but it cannot by itself prove that the number came from the total-due line rather than a purchase-order number. Likewise, it can require a date-shaped string without proving that the selected value is the effective date instead of the upload date.

The prompt is therefore guidance, and the schema is structural enforcement, but neither should be mistaken for proof that the extracted claim is true. The application still needs semantic validation, which checks the meaning, evidence, relationships, and business rules around structurally valid output. In a hypothetical procurement workflow, a model might return a perfectly formed supplier record while citing a paragraph that names a different company, and only an evidence check would expose that mismatch. Missing-value policy should be designed before extraction begins, rather than improvised after the model returns an awkward result. A nullable field is one whose schema explicitly permits the null value, while an optional field may be omitted entirely when the value is unavailable.

Null is useful only when the schema and every downstream consumer agree on its meaning, because one component may interpret it as unknown while another incorrectly treats it as empty or zero. Some workflows need typed unknown states, which are named categories such as not present, illegible, contradictory, and not applicable. Those distinctions affect action: an absent transaction identifier may trigger a request for more information, an illegible identifier may require a clearer scan, and contradictory identifiers may require investigation. Returning one generic unknown state would be simpler, but it would discard information that the next person or system needs to choose the right response.

In the fictional Harbour Resolution workflow, the model extracts a claimant name, complaint date, requested remedy, and transaction identifiers from each complaint. Where auditability matters, each extracted field should also carry a source reference or source span, meaning a location or exact portion of the supplied material that supports the value. Evidence is information directly present in the source, while inference is a conclusion drawn from that information, and the output should keep the two separate. If a complaint says a replacement was requested, that statement is evidence, but deciding that the claimant would accept store credit is an unsupported inference unless the source says so.

Auditability means another reviewer can reconstruct why a result was accepted, using the source, cited evidence, validation results, tests and recorded decisions. Records of which tools were called, what inputs they received and what they returned help that reviewer follow what the system actually did. A model can return a confidence category such as low, medium, or high, but that label is not a probability guarantee and should not be used as an automation threshold until it has been calibrated. Calibration means measuring the observed error rate within each confidence category on representative evaluated cases and checking that those rates are dependable before the categories control automation.

Even calibrated confidence has limits, because a new document type or an unfamiliar writing style can behave differently from the material used during evaluation. A validation-and-retry loop checks a response, reports specific correctable errors, and asks for a bounded repair, meaning only a limited number of focused attempts are allowed. A structural validator might report that transaction identifiers must be an array of strings, giving the model a precise defect it can repair without redoing unrelated fields. A semantic validator might report that the cited page does not contain the extracted amount, which directs attention to the evidence mismatch rather than vaguely requesting a better answer.

The retry request should preserve valid fields where practical, identify the failed rule, and prohibit unsupported invention, although the repaired answer must still be validated again. Retries should stop after a defined bound because repeated attempts can waste resources, obscure persistent ambiguity, and pressure the model toward a confident-looking guess. When the source is genuinely ambiguous, needs human review is a successful controlled outcome, not a failure to force certainty. Prompt chaining means dividing a complex workflow into separate model calls, such as inspect, extract, verify, and render. In a hypothetical insurance office, an inspection stage could identify the document type, an extraction stage could fill the matching schema, a verification stage could check every field against the source, and a rendering stage could prepare a readable summary.

This separation improves observability, meaning the team can see which stage produced a defect, and it allows each stage to use instructions and an output contract suited to its narrow job. The stages can also use different models selected for the accuracy, capabilities, delay and cost that each task can tolerate. That flexibility needs testing: introducing another model means checking its behaviour and monitoring the handoff, not assuming that the pieces work well together just because each looked useful on its own. The trade-off is that every additional call creates cost, delay, and a handoff where context can be lost or an earlier mistake can propagate.

More stages are therefore useful when they create a testable boundary or an independent check, not merely because a longer pipeline looks sophisticated. Chain-of-thought prompting asks a model to work through intermediate reasoning steps, and difficult tasks may benefit from room for analysis while the final response remains tightly constrained. Exposed reasoning should not be treated as an audit record, because a fluent explanation is still generated output and may not faithfully describe how the answer was reached. A self-critique asks the same model path to inspect its own answer, which can catch omissions or formatting defects but may repeat the assumptions that caused the first error.

That limitation is called correlated error: two judgments fail together because they share the same perspective, context, or mistaken premise. For higher-assurance work, an independent pass can use a distinct role and fresh instructions, and the system should preserve disagreement instead of pressuring the second pass to endorse the first. In a dual-pass extraction pattern, the first instance extracts fields and citations, while the second receives the source and proposed extraction and checks each field without being told that the proposal is presumed correct. A hypothetical payroll team might use that pattern for a form containing a handwritten account identifier, with the verifier rejecting the field when the cited mark is illegible rather than selecting the nearest plausible digits.

Independent verification costs another call and still cannot guarantee correctness, so it belongs where the consequence of an error justifies the added work. The same pattern can support code review through adversarial verification, meaning a second pass deliberately challenges each proposed defect’s evidence, affected scope, and connection to the actual code rather than trying to confirm it. Authentication verifies the claimed identity of a person or system, while authorization determines whether that verified identity is permitted to perform the requested action. A prompt can ask a model to recognize an apparent approval message, but the surrounding application must enforce authorization because descriptive text is not a security control.

In a hypothetical leave workflow, a message bearing a manager's name might be extracted as an approval statement, yet the application must still authenticate the sender and verify that the sender is authorized to approve that employee's leave. Confirmation is also different from authorized approval: a model saying that it understands or has confirmed a requested action does not mean a permitted decision-maker has approved execution. These distinctions keep language from quietly turning into authority, especially when a structured output feeds another system. Batch processing groups many requests for asynchronous handling, meaning results arrive later rather than within an interactive conversation. An API, which stands for application programming interface, is a defined way for software components to exchange requests and responses, and a message batch API suits large workloads that do not need immediate answers.

A hypothetical records team could submit many archived complaints for overnight extraction, but batch processing would be a poor fit for a live support exchange with a strict response-time objective. Each submitted item should carry a stable custom identifier, meaning a value that remains unchanged and uniquely links the result back to its source record. The workflow must track submission, processing state, each item's result status, retry decisions, expiry, and reconciliation, which is the process of matching returned results with the records that were sent. It also needs downstream idempotency, meaning that processing the same successful result more than once has the same intended effect as processing it once.

Without idempotency, a retried or duplicated batch result could create duplicate case notes or repeat another downstream action even though the model output itself was valid. Batching may change operational cost or timing, but it does not remove responsibility for validation, evidence checks, access control, failure handling, or human escalation. The durable sequence is to define success and failure, provide necessary context and discriminating examples, constrain syntax through the strongest suitable mechanism, validate meaning and evidence outside the model, and iterate from representative observed failures. Put simply, a reliable prompt tells the model what good looks like, while a reliable system checks structure, truth, authority, uncertainty, and consequences before trusting the result.