{
  "ok": true,
  "data": {
    "entry": {
      "id": "refusal-fixtures",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Use refusal boundaries as test fixtures",
      "body": "Do not only test the happy path. Save examples that should be refused, partially answered, or redirected, then run them every time you change instructions. Safety behavior drifts just like product behavior.",
      "tag": "evals",
      "date": "2026 · 04 · 12",
      "publishedAt": "2026-04-12",
      "note": null,
      "insight": {
        "aha": "Safety quality is not whether the model refuses. It is whether it refuses at the right boundary.",
        "tryThis": "Keep allowed, disallowed, and allowed-with-constraints prompts as fixtures and run them after prompt edits.",
        "watchFor": [
          "Over-refusal on harmless transformed versions",
          "Under-refusal when the same intent is phrased politely",
          "Responses that refuse but fail to offer a safe next step"
        ]
      },
      "extended": [
        "Most prompt tests focus on whether the model can complete the intended workflow. That misses the other half of the product: whether it handles edge requests without over-refusing, leaking private context, or inventing authority it does not have.",
        "Build a small fixture set with three buckets: allowed, disallowed, and allowed-with-constraints. A good model response should land in the right bucket and explain the usable next step.",
        "This turns safety from a vibe into a regression target. When a prompt edit changes the refusal boundary, you see it immediately."
      ],
      "url": "https://tips.platphormnews.com/entries/refusal-fixtures"
    }
  }
}