Build · Create · Engineering

Build an MVP Scope Boundary Contract

The founder gets a structured scope contract that locks the MVP boundary in advance, so zero-friction scope creep is gated by a written evidence test for every excluded feature rather than founder enthusiasm.

You receive: A JSON object: { inScope: [{ featureId, statement }], outOfScope: [{ featureId, statement, amendmentEvidence }], amendmentRule: string, signedOff: bool, reviewDate: date }

Part of Choose Business Model

What's verified: STUD verifies the scope contract is structurally complete and self-consistent: both lists meet their minimums, every excluded feature carries an amendment-evidence test, IDs are unique, and nothing is simultaneously in and out of scope. STUD does NOT judge whether the chosen scope is the right MVP, whether the excluded features are correctly excluded, or whether the evidence tests are well-calibrated. It enforces that a written, evidence-gated boundary exists, not that it is strategically correct.

{
 "buyerParamKeys": [
  "requireAmendmentEvidence",
  "requireGlobalAmendmentRule"
 ],
 "checkNames": [
  "format_parses",
  "inscope-min",
  "outscope-min",
  "id-uniqueness",
  "disjoint",
  "booleans",
  "evidence-required",
  "global-rule"
 ],
 "constants": {
  "_ISO_DATE_RE": "^\\d{4}-\\d{2}-\\d{2}$"
 },
 "deliverableLabel": "mvp_scope_boundary_contract",
 "documentKeys": [
  "amendmentEvidence",
  "amendmentRule",
  "featureId",
  "inScope",
  "outOfScope",
  "reviewDate",
  "signedOff",
  "statement"
 ],
 "enumLiterals": [
  [
   "yes",
   "true",
   "1"
  ]
 ],
 "submission": "a JSON document (submitted as a string), validated as data; every check below must pass",
 "tier": "doc-validator"
}