A model ignores output requirements: how do you find conflicting prompt instructions?

Turn unmet requirements into checkable conditions

Typical failures include a long explanation instead of a table, outside knowledge despite a source restriction, or continued expansion despite a short-answer request. Preserve input and output and identify the exact violated condition. Distinguish subjective style dissatisfaction from a measurable failure in length, fields or permitted sources.

Inspect conflicting instructions and assembled requests

Look for conflicts such as detailed explanation versus a single-value-only response, then check contrary requirements retained in history. Applications may append default templates, so inspect assembled text. If the service offers structured constraints, verify that the request enables them rather than merely mentioning JSON in natural language.

Simplify before restoring complex requirements individually

State the main deliverable clearly and separate mandatory constraints from areas allowing discretion. Supply a short correct example, then test different inputs rather than only ideal cases. Remove irrelevant role stories and repeated emphasis. Retain the previous version after each change so the cause of improvement can be identified.

Retest requirements on boundary inputs

Use normal and boundary inputs with the same checklist. Confirm both compliance and the absence of invented facts used to satisfy the format. If only inputs resembling the example succeed, adjust definitions or examples rather than declaring the entire template reliable.

Instruction following still has model-capability and product limits; not every condition can be enforced through natural language. This page reports no model success rate and does not recommend repeating “must” instead of testing. Strict fields and permissions need programmatic validation and authorization, not a prompt as the sole control.