{
  "example_kind": "original synthetic manual planning case",
  "slug": "negative-test-expected-result",
  "title": "Classify a negative test against its expected result",
  "scenario": "Synthetic planning case: An external acceptance contract rejects a request with a missing required identifier. Test A receives that expected rejection; test B accepts another identifier-missing request.",
  "layout": "protocol",
  "dataset": {
    "heading": "Inspect the invented case records",
    "headers": [
      "Test",
      "Declared expected behavior",
      "Observed toy behavior",
      "Verdict"
    ],
    "rows": [
      [
        "A",
        "Reject missing identifier",
        "Rejected",
        "Pass"
      ],
      [
        "B",
        "Reject missing identifier",
        "Accepted",
        "Fail"
      ]
    ]
  },
  "derivation": "Verdict compares observation with the declared expectation. The outcome sign alone—accepted or rejected—does not define test success.",
  "result": "A passes this negative-test expectation and B fails it. Do not label every rejection a product failure or every accepted request a pass.",
  "boundary": "The artifact classifies negative-test success against a stated contract rather than an intuitive positive/negative label.",
  "limitations": "The example supplies no native API or permission claim. Error text, recoverability and other valid/invalid conditions need separate evidence.",
  "sources": [
    "original"
  ],
  "tasks": [
    [
      "Confirm the missing-input contract",
      "Behavior owner",
      "The identifier is actually required in this external example."
    ],
    [
      "Compare expected and observed outcomes",
      "Reviewer",
      "A matches rejection; B violates the same declared boundary."
    ],
    [
      "Assign the unexpected acceptance",
      "Delivery owner",
      "B’s failing fixture receives an owned investigation without changing the expected result after the fact."
    ]
  ],
  "faqs": [
    [
      "Can a rejection still be wrong?",
      "Yes if it rejects a valid input or has another unaccepted behavior; the contract must be explicit."
    ],
    [
      "Does A prove every invalid input is handled?",
      "No. It is one fixture under one boundary."
    ]
  ],
  "method_references": [
    {
      "id": "original",
      "title": "Original worked-case definitions",
      "scope": "Definitions, policy choices, records and calculations are authored for this worksheet. No external standard, statistical validation or live product measurement is claimed."
    }
  ]
}