{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/prototype-the-uncertain-part-instead-of-specifying-it-by-imagination",
  "id": "MHC-D-RESEARCH-0789",
  "version": "0.1.0",
  "title": "Prototype the uncertain part instead of specifying it by imagination",
  "summary": "Some ambiguity should be tested, not polished into a longer specification.",
  "kind": "concept",
  "body": "Identify the uncertainty and build the cheapest prototype that can answer it: sketch, mock, sample data flow, throwaway code or technical spike. State what the prototype is testing and what production qualities it intentionally does not prove. Use the result to revise the requirement.",
  "limits": [
    "Prototype code and demo success are not production evidence for security, reliability, performance or maintainability unless those were deliberately tested."
  ],
  "topics": [
    "union-requirements-and-acceptance-clarity"
  ],
  "intents": [],
  "source_ids": [
    "RS-AA4CF71A3FB24D22",
    "RS-0563603D99A737E6"
  ],
  "evidence": [
    {
      "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"
    },
    {
      "claim": "GOV.UK prototyping guidance recommends exploring and testing alternative designs before committing to production and notes that prototype code may deliberately not meet production standards.",
      "source_id": "RS-0563603D99A737E6",
      "role": "supports",
      "note": "A prototype reduces selected uncertainties; it does not prove production reliability, security, accessibility or scalability unless those properties are explicitly tested.",
      "locator": "When to use prototypes; Using code prototypes"
    }
  ],
  "use_when": [
    "The team cannot write credible acceptance criteria because the solution or user interaction is still genuinely uncertain."
  ],
  "avoid_when": [
    "Prototype code and demo success are not production evidence for security, reliability, performance or maintainability unless those were deliberately tested."
  ],
  "example": "Before specifying a complex approval UI, the team tests two clickable flows with likely users; before choosing an integration library, it runs a spike against the real API limits.",
  "check": "The prototype has a question it can answer and an explicit boundary on what its success does not prove.",
  "sources": [
    {
      "id": "RS-AA4CF71A3FB24D22",
      "title": "Writing user stories",
      "url": "https://www.gov.uk/service-manual/agile-delivery/writing-user-stories"
    },
    {
      "id": "RS-0563603D99A737E6",
      "title": "Making prototypes",
      "url": "https://www.gov.uk/service-manual/design/making-prototypes"
    }
  ],
  "relations": [
    {
      "from": "MHC-D-RESEARCH-0789",
      "to": "MHC-D-RESEARCH-0783",
      "type": "alternative",
      "url": "/knowledge/write-acceptance-evidence-before-implementation-starts"
    }
  ],
  "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"
    }
  ]
}