{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/turn-an-assumption-into-a-named-temporary-requirement-state",
  "id": "MHC-D-RESEARCH-0784",
  "version": "0.1.0",
  "title": "Turn an assumption into a named temporary requirement state",
  "summary": "An unlabeled assumption quietly becomes a permanent fact.",
  "kind": "template",
  "body": "Record the best current assumption, why it is being used, the risk if wrong, who must resolve it, by when and what evidence will close it. Keep provisional values visibly provisional rather than hiding them in normal requirement text.",
  "limits": [
    "Not all uncertainty should block progress. The point is to expose and manage it, not wait for perfect knowledge."
  ],
  "topics": [
    "union-requirements-and-acceptance-clarity"
  ],
  "intents": [],
  "source_ids": [
    "RS-A059268EF3F10749"
  ],
  "evidence": [
    {
      "claim": "NASA guidance recommends requirements that identify the responsible product or party and needed behavior, use consistent terminology, state what is needed rather than prescribing implementation, and include rationale and assumptions.",
      "source_id": "RS-A059268EF3F10749",
      "role": "supports",
      "note": "Some constraints legitimately specify implementation when mandated by architecture, regulation or compatibility.",
      "locator": "Editorial checklist; general goodness checklist"
    },
    {
      "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": [
    "A requirement contains an unknown value or premise that everyone knows is provisional but nobody owns resolving."
  ],
  "avoid_when": [
    "Not all uncertainty should block progress. The point is to expose and manage it, not wait for perfect knowledge."
  ],
  "example": "A migration design assumes a maximum daily volume based on incomplete history; the data owner is assigned to confirm it before load-test sizing is frozen.",
  "check": "Every consequential provisional premise has an owner and closure condition.",
  "template": "Temporary assumption: [ ]. Rationale: [ ]. Risk if wrong: [ ]. Owner: [ ]. Resolve by: [ ]. Evidence needed: [ ].",
  "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-0784",
      "to": "MHC-D-RESEARCH-0787",
      "type": "useful_with",
      "url": "/knowledge/trace-every-costly-requirement-back-to-the-need-it-protects"
    }
  ],
  "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"
    }
  ]
}