{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/specify-the-interface-where-responsibility-changes-hands",
  "id": "MHC-D-RESEARCH-0785",
  "version": "0.1.0",
  "title": "Specify the interface where responsibility changes hands",
  "summary": "Many ambiguous requirements live in the space between two owners.",
  "kind": "checklist",
  "body": "For each important interface, name the producer, consumer, object transferred, trigger, format or contract, timing, error signal, retry or fallback, and who owns a failed handoff. Treat the boundary as a requirement surface, not invisible plumbing.",
  "limits": [
    "Interface detail should match risk; do not create heavyweight documents for trivial internal calls that are already governed by stable contracts."
  ],
  "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"
    }
  ],
  "use_when": [
    "Each component looks correct in isolation but failures occur at handoffs between teams, systems or process steps."
  ],
  "avoid_when": [
    "Interface detail should match risk; do not create heavyweight documents for trivial internal calls that are already governed by stable contracts."
  ],
  "example": "An outbound IDoc interface specifies who sends it, message type, trigger, acknowledgement, retry behavior and which team owns an unprocessed message.",
  "check": "A handoff failure can be assigned and diagnosed without first debating where one component ends and the next begins.",
  "checklist": [
    "Producer and consumer",
    "Data/object/event transferred",
    "Trigger and timing",
    "Format or contract",
    "Acknowledgement or success signal",
    "Failure/retry behavior",
    "Owner when the handoff fails"
  ],
  "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": [
    {
      "from": "MHC-D-RESEARCH-0785",
      "to": "MHC-D-RESEARCH-0786",
      "type": "useful_with",
      "url": "/knowledge/specify-what-happens-when-the-happy-path-cannot-complete"
    }
  ],
  "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"
    }
  ]
}