Prompting
Structured Output Contract
Design portable output contracts, use provider schema features where supported, and validate shape, meaning, authority, and evidence before downstream use.
- Format
- How To
- Level
- Intermediate
- Audience
- Practitioner, Developer
- Owner
- Project42 Editorial
- Review cadence
- Every 30 days
- Prerequisites
- A framed task and a consumer that needs predictable output
Separate shape from truth
Define the portable business contract first: fields, types, allowed values, required evidence, unknown handling, and version. Then map that contract to the current provider schema or tool mechanism. Keep provider-specific request syntax in an adapter so the business contract can survive model or provider changes.
A valid schema can constrain structure; it does not prove factual accuracy, permission, policy compliance, or successful side effects. Validate both structure and business meaning in trusted code before storage, display, communication, or action.
Define a portable envelope
Use explicit unknown values instead of forcing guesses. Do not put credentials or unrestricted sensitive text in examples.
{
"contractVersion": "1.0",
"status": "complete | needs-input | blocked",
"result": "[BOUNDED RESULT — NO SECRETS]",
"evidence": [
{ "claim": "[MATERIAL CLAIM]", "source": "[SOURCE ID OR URL]" }
],
"assumptions": ["[VISIBLE ASSUMPTION]"],
"warnings": ["[SAFETY, QUALITY, OR POLICY WARNING]"],
"nextAction": "[NONE OR HUMAN-APPROVED STEP]"
}Expected result and verification
The expected result is output that conforms to the declared version, represents unknown or blocked states explicitly, and carries evidence for material claims without leaking restricted data.
Validate against the schema, enforce allowed values and size limits, check citations against retrieved sources, apply authorization independently of model fields, and test missing, extra, malformed, adversarial, and oversized inputs. Pin and regression-test provider adapters because supported schema behavior can change.