{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/write-acceptance-evidence-before-implementation-starts",
  "id": "MHC-D-RESEARCH-0783",
  "version": "0.1.0",
  "title": "Write acceptance evidence before implementation starts",
  "summary": "Late acceptance criteria turn testing into negotiation.",
  "kind": "protocol",
  "body": "Before implementation, write the observable outcomes that would show the need is met. Name the evidence when useful: test, demonstration, inspection, analysis, user task or data check. Include important negative and boundary cases.",
  "limits": [
    "Discovery work can begin before final acceptance is known; do not pretend exploratory prototypes have production acceptance criteria."
  ],
  "topics": [
    "union-requirements-and-acceptance-clarity"
  ],
  "intents": [],
  "source_ids": [
    "RS-111B71DE76BA6C09",
    "RS-AA4CF71A3FB24D22"
  ],
  "evidence": [
    {
      "claim": "NASA recommends identifying a verification approach for requirements and keeping each requirement uniquely identifiable with a definitive source.",
      "source_id": "RS-111B71DE76BA6C09",
      "role": "supports",
      "note": "The appropriate verification method and documentation depth depend on risk and project scale.",
      "locator": "Requirements Verification Matrix"
    },
    {
      "claim": "GOV.UK user-story guidance recommends recording the actor, needed action and goal, focusing on why the need exists, and using acceptance criteria to state observable outcomes that show the job is done.",
      "source_id": "RS-AA4CF71A3FB24D22",
      "role": "supports",
      "note": "User-story syntax is one framing method and is not appropriate for every technical, regulatory or infrastructure requirement.",
      "locator": "What to include; Focus on the goal; Acceptance criteria"
    }
  ],
  "use_when": [
    "A team agrees on a task but expects to decide what 'done' means near the end."
  ],
  "avoid_when": [
    "Discovery work can begin before final acceptance is known; do not pretend exploratory prototypes have production acceptance criteria."
  ],
  "example": "For a mass update, acceptance covers successful valid rows, rejected invalid rows, an audit result and behavior when the input is empty.",
  "check": "The team can design the verification without first asking what the finished feature was supposed to do.",
  "steps": [
    "The team can design the verification without first asking what the finished feature was supposed to do."
  ],
  "sources": [
    {
      "id": "RS-111B71DE76BA6C09",
      "title": "Appendix D: Requirements Verification Matrix",
      "url": "https://www.nasa.gov/reference/appendix-d-requirements-verification-matrix/"
    },
    {
      "id": "RS-AA4CF71A3FB24D22",
      "title": "Writing user stories",
      "url": "https://www.gov.uk/service-manual/agile-delivery/writing-user-stories"
    }
  ],
  "relations": [
    {
      "from": "MHC-D-RESEARCH-0783",
      "to": "MHC-D-RESEARCH-0788",
      "type": "use_before",
      "url": "/knowledge/choose-the-verification-method-while-the-requirement-is-still-editable"
    }
  ],
  "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"
    }
  ]
}