{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/specify-what-happens-when-the-happy-path-cannot-complete",
  "id": "MHC-D-RESEARCH-0786",
  "version": "0.1.0",
  "title": "Specify what happens when the happy path cannot complete",
  "summary": "If failure behavior is unspecified, the implementation will invent it.",
  "kind": "checklist",
  "body": "List consequential failure conditions and define the required response: reject, retry, queue, rollback, preserve partial state, alert, ask for correction or degrade safely. Include what the user or operator can observe and how recovery is confirmed.",
  "limits": [
    "Do not enumerate every imaginable failure. Prioritize credible and consequential modes using risk and operational evidence."
  ],
  "topics": [
    "union-requirements-and-acceptance-clarity"
  ],
  "intents": [],
  "source_ids": [
    "RS-A059268EF3F10749"
  ],
  "evidence": [
    {
      "claim": "NASA's requirements checklist emphasizes clarity, one thought per requirement, completeness, explicit assumptions, consistency, traceability, feasibility and verifiability.",
      "source_id": "RS-A059268EF3F10749",
      "role": "supports",
      "note": "The checklist is for systems engineering; smaller tasks can apply the principles proportionally.",
      "locator": "Requirements validation checklist"
    },
    {
      "claim": "NASA guidance warns against unverifiable terms such as easy, fast, adequate or user-friendly unless they are translated into criteria that can be tested, demonstrated, inspected or analyzed.",
      "source_id": "RS-A059268EF3F10749",
      "role": "supports",
      "note": "Qualitative goals can still be useful during discovery when they are explicitly treated as goals rather than acceptance requirements.",
      "locator": "Verifiability/Testability"
    }
  ],
  "use_when": [
    "Requirements describe successful behavior but leave invalid input, timeout, partial failure or recovery undefined."
  ],
  "avoid_when": [
    "Do not enumerate every imaginable failure. Prioritize credible and consequential modes using risk and operational evidence."
  ],
  "example": "A batch update requirement defines whether valid rows commit when one row fails and what reconciliation output identifies the rejected records.",
  "check": "At least the important failure modes have an expected state and recovery path, not only an error message.",
  "checklist": [
    "Invalid input",
    "Dependency unavailable",
    "Timeout or duplicate event",
    "Partial completion",
    "Retry/rollback rule",
    "Visible error or alert",
    "Recovery confirmation"
  ],
  "sources": [
    {
      "id": "RS-A059268EF3F10749",
      "title": "Appendix C: How to Write a Good Requirement",
      "url": "https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/"
    }
  ],
  "relations": [],
  "collections": [
    {
      "id": "RC-272C54FF0D8FF2BA",
      "title": "Turn ambiguous work into requirements that can be checked",
      "url": "/collections/turn-ambiguous-work-into-requirements-that-can-be-checked"
    }
  ]
}