Write the acceptance contract before the prompt

Prompt discussions become subjective when “better” has not been defined. One person wants a short answer, another wants caveats, and a third expects every claim to include evidence. An acceptance contract resolves those differences before anyone debates wording.

The contract is not a longer prompt. It is a decision sheet shared by the task owner, reviewers, and implementers. Its purpose is to state which output may advance to the next step. Once that decision is explicit, the team can tell whether a failure calls for new source material, a workflow change, or model tuning.

Separate gates from preferences

Sort requirements into two groups. A gate rejects the output when violated: a missing order identifier, use of an unapproved source, or an unauthorized account action. A preference permits tradeoffs: shorter sentences, a livelier heading, or a different ordering of valid points. Turning every preference into a gate makes the workflow optimize formatting while reviewers drown in low-value failures.

Test a proposed gate with three questions. Would breaking it alter a decision? Could it harm someone or create a policy risk? Would the next step be unable to repair it cheaply? A requirement that receives three no answers is probably a preference.

Define five parts of an acceptable output

• Required content: fields or decisions that must appear.
• Evidence rule: what may support a claim and how it should be shown.
• Expression rule: tone, length, structure, and terminology.
• Uncertainty rule: what the workflow must say when evidence is missing or conflicting.
• Rejection rule: conditions that make the whole result unusable.

Write each rule so two reviewers can apply it to the same example. “Professional” is not a test. “No greeting; answer in three bullets; name the account and unresolved issue” is.

Example: research summary

The required content is a one-sentence answer, three supporting findings, and one unresolved question. Every finding must cite an approved source and date. Direct quotation is used only when wording matters. Conflicting evidence must remain visible.

The result is rejected if a central claim has no source, if a source predates the required period without a warning, or if the answer merges two different measures. A beautiful summary that violates one of these rules still fails.

Example: support reply

The reply must acknowledge the specific problem, give only verified steps, identify any account action requiring consent, and end with one next question. It may be warm, but cannot promise timing or refunds that are absent from policy.

When account state is missing, the correct output is a request for information—not an invented diagnosis. That uncertainty rule is more useful than asking the model to “avoid hallucinations.”

Use examples as contract tests

Attach one passing output, one near miss, and one clear failure to the contract. Annotate exactly which rule each example satisfies or breaks. These examples are tests, not decoration.

Only after the contract is stable should the team decide whether the prompt needs new instructions, better context, a schema, a validator, or a different model.

Copy this acceptance-contract worksheet

Complete the worksheet for one real task. Avoid assembling it from generic prompt phrases.

Contract field	What to record	Review evidence
Use context	Who uses the result and before which decision	Task brief or workflow stage
Required content	What absence prevents the work from continuing	Field-by-field check
Permitted evidence	Approved sources, versions, and date range	Cited passage and source date
Expression constraints	Format the receiving system genuinely requires	Schema or annotated pass case
Uncertainty action	What happens when facts are missing or conflict	Stop, question, or escalation log
Rejection conditions	Errors that must block the result	Failed example and rule identifier

Walk three inputs through the draft: a routine case with complete material, an edge case with missing facts, and a plausible-looking case that should be rejected. If reviewers cannot reach the same outcome from the worksheet alone, repair the rules before touching the prompt.

Connect the contract to release decisions

Give the contract a version, an owner, and a reason for every change. A new field definition, source boundary, or downstream action should rerun the historical cases. A harmless tone change does not need to trigger every regression. The release record should retain the contract version, test input, actual output, reviewer decision, and unresolved disagreement.

Do not preserve only an aggregate pass rate. Attribute each failure to a rule so that “correct citation but missing field” remains distinct from “polished response with an unauthorized promise.” If a rule never intercepts risk and serves no downstream consumer, consider removing it.

Common questions

Is this the same as a structured-output schema? No. A schema can inspect fields and types. It cannot establish whether evidence supports a conclusion, when work must stop, or whether the tone exceeds the system’s authority.

Does the contract really come before the prompt? A rough prompt may be useful while exploring the task. The contract must be fixed before comparing alternatives or claiming that one configuration performs better.

Does every scenario need a separate contract? Scenarios may share one when they serve the same decision, risk level, and downstream format. Split the contract when any of those changes substantially; one giant set of vague rules is not reusable governance.

Boundary

Do not make the contract so detailed that review costs more than the original work. Protect the decisions that matter, then allow harmless variation. If reviewers repeatedly disagree, fix the contract before tuning the system.