Prompt systemsGuide6 min

Build a prompt contract for deterministic product behavior

How to make prompts serve a product contract instead of becoming fragile hidden application logic.

Real example

Example: prompt contract for refund decision support

A refund assistant sometimes writes confident answers even when policy data is missing. Support needs consistent behavior.

The prompt contract says: identify policy version, extract customer facts, classify eligibility, cite evidence, and return needs_human_review when required facts are missing. The server validates the schema and blocks unsupported answers.

The assistant becomes predictable because missing information has an explicit output path.

Tutorial path

How to implement it

Step 01

Write the product outcome in one sentence before writing instructions.

Step 02

List allowed inputs and define what the model must do when required inputs are missing.

Step 03

Specify the output schema and unacceptable output patterns.

Step 04

Move calculations, permission checks, and final writes out of the prompt and into code.

Step 05

Version prompt changes and test them against saved examples.

Checklist

Ready when these are true

Outcome is explicit

Missing-input behavior defined

Output schema linked

Business rules in code

Prompt version tracked

Field notes

What matters in practice

A prompt contract states role, task, inputs, output shape, constraints, and refusal behavior.

Determinism improves when code owns rules and the model owns interpretation within those rules.

Prompts should be versioned with the workflow they affect.

Avoid these mistakes

Common failure modes

Do not hide business rules in long prose prompts when code can enforce them.

Do not let the model decide final refunds without policy evidence.

Do not change prompt contracts without regression examples.

Practical tip

A prompt contract should be readable by product, engineering, and support. If only one person understands it, it is too fragile.

Apply this to a build