What you will learn
Task instructions, JSON schemas, Few-shot examples, Fallbacks, Prompt versioning.
Engineering the capability
Treat a prompt as one versioned component of an application contract. Specify the task, available evidence, output fields, and behavior when the task cannot be completed. Examples help clarify categories, but they must represent the boundary cases rather than only easy successes.
Structured generation can improve format compliance. Validate the result regardless: schema validity, business meaning, and authorization are separate checks. A valid amount of minus ten may be invalid for an invoice; a valid account ID may belong to someone else.
Define recovery explicitly. A bounded retry that asks for schema correction can help, but repeated repair attempts increase cost and can change meaning. Preserve a safe failure state once the budget is exhausted. Record prompt versions with evaluation results so a change can be compared and rolled back.
Worked case
A classifier supports billing, access, and unknown. The input “I cannot see my invoice” touches billing and access. Decide whether the task permits multiple labels, a clarification question, or unknown before writing examples. Otherwise two equally plausible outputs appear to be random model errors when the product rule is actually missing.
Put it into practice
Continue with the next lab: build a validated ticket classifier. Build the artifact, record the failure cases, and explain the tradeoff before moving on.