Guides/Prompt & policy design

Prompt & policy design for products

Users do not experience “the model” — they experience stacked instructions, injected context, and validated outputs. Product teams win when precedence is explicit and downstream parsers match what marketing demos imply.

Instruction precedence

Align with legal and safety partners on what belongs in immutable policy versus editable product copy — this diagram is a collaboration aide, not legal advice.

Ship explicit precedence: when UX adds “modes,” encode them as separate system branches — not buried edits users can mimic.

Output contracts

Output posture	Typical fit	Product tradeoff
Free-form prose	Exploration, creative drafts, low structured downstream use	Cheap to prompt-test — expensive to parse reliably in apps
JSON / schema mode	UI rendering, tools, billing codes, strict pipelines	Repair loops & validation UX — budget retries in latency
Few-shot exemplars	Niche formats legal/clinical teams insist on seeing	Token bloat; staleness when examples drift from prod data
Hard refusal templates	Regulated domains; zero tolerance for invented facts	Support load — pair with escalation paths, not silent fails

Rigidity vs reliability

Constraint vs downstream reliability (schematic)

Tighter contracts reduce silent breakage in code paths — at the cost of prompt churn and user-visible repair.

Pick the weakest contract that still satisfies your parsers — over-constraining early burns teams before product-market fit.