{
  "schema_version": "1.0.0",
  "build": "SIO27",
  "count": 18,
  "requirements": [
    {
      "id": "EVAL-01",
      "discipline": "SECURITY",
      "title": "Authority boundary",
      "question": "Can commercial identity, API access, or credentials create machine authority?",
      "acceptance_basis": "Must remain NO. Authority is explicit, delegated, bounded, independently enforced and revocable."
    },
    {
      "id": "EVAL-02",
      "discipline": "SECURITY",
      "title": "Credential custody",
      "question": "Where do raw consequential credentials exist?",
      "acceptance_basis": "Downstream of valid authority and permit eligibility, inside the appropriate customer-controlled enforcement boundary."
    },
    {
      "id": "EVAL-03",
      "discipline": "SECURITY",
      "title": "Revocation",
      "question": "Can machine power be interrupted independently of the requesting agent?",
      "acceptance_basis": "Guardian/revocation controls must narrow, suspend, revoke, quarantine or recover without broadening authority."
    },
    {
      "id": "EVAL-04",
      "discipline": "ARCHITECTURE",
      "title": "Decision independence",
      "question": "Is authorization deterministic and separate from model inference?",
      "acceptance_basis": "ActionGate evaluates semantic action requests against current authority and policy; model confidence is not authorization."
    },
    {
      "id": "EVAL-05",
      "discipline": "ARCHITECTURE",
      "title": "Delegation lineage",
      "question": "Can evaluators trace where power came from?",
      "acceptance_basis": "Every effective grant requires attributable lineage, scope, validity, attenuation and revocation state."
    },
    {
      "id": "EVAL-06",
      "discipline": "ARCHITECTURE",
      "title": "Execution separation",
      "question": "Can the governance client itself execute the action?",
      "acceptance_basis": "No. Permit-bound execution and JIT credential materialization are separate downstream responsibilities."
    },
    {
      "id": "EVAL-07",
      "discipline": "DEPLOYMENT",
      "title": "Locality",
      "question": "Can enforcement run where the customer requires it?",
      "acceptance_basis": "Evaluate customer-managed, private, air-gapped, managed and hybrid profiles against the required data/credential boundary."
    },
    {
      "id": "EVAL-08",
      "discipline": "DEPLOYMENT",
      "title": "Shadow first",
      "question": "Can the refused workflow be observed before write capability exists?",
      "acceptance_basis": "Use customer-controlled read-only shadow observation and counterfactual ActionGate outcomes before consequential connection."
    },
    {
      "id": "EVAL-09",
      "discipline": "DEPLOYMENT",
      "title": "Rollback and teardown",
      "question": "Can the evaluation boundary be removed cleanly?",
      "acceptance_basis": "Bootstrap packages must expose verification, receipt and teardown behavior without retaining hidden authority."
    },
    {
      "id": "EVAL-10",
      "discipline": "PROCUREMENT",
      "title": "Claims discipline",
      "question": "Which claims are architecture, source-backed engineering, synthetic evidence or external proof?",
      "acceptance_basis": "Public Truth classification must travel with the claim; sealed builds are not customer deployment evidence."
    },
    {
      "id": "EVAL-11",
      "discipline": "PROCUREMENT",
      "title": "Commercial boundary",
      "question": "Do subscription, ownership or workspace roles create authority?",
      "acceptance_basis": "No. Commercial identity and entitlements have machine_authority_effect=NONE."
    },
    {
      "id": "EVAL-12",
      "discipline": "PROCUREMENT",
      "title": "Evaluation exit criteria",
      "question": "What does a completed evaluation actually approve?",
      "acceptance_basis": "Only the customer can define and record internal acceptance; StableMind evaluation completeness does not claim procurement or production approval."
    },
    {
      "id": "EVAL-13",
      "discipline": "EVIDENCE",
      "title": "Receipt versus proof",
      "question": "Does executor success independently prove consequence?",
      "acceptance_basis": "No. Execution receipts are evidence; independent verifier observations support Proof of Consequence."
    },
    {
      "id": "EVAL-14",
      "discipline": "EVIDENCE",
      "title": "Missing evidence",
      "question": "What happens when required verifier evidence is absent?",
      "acceptance_basis": "The proof state fails to UNVERIFIABLE rather than being promoted to success."
    },
    {
      "id": "EVAL-15",
      "discipline": "EVIDENCE",
      "title": "Evidence custody",
      "question": "Who holds evaluation artifacts and how are they attributable?",
      "acceptance_basis": "Evaluation must define customer-controlled custody, provenance, integrity and retention appropriate to the deployment profile."
    },
    {
      "id": "EVAL-16",
      "discipline": "PILOT_DESIGN",
      "title": "Refused workflow",
      "question": "Is the pilot anchored to an action the customer currently refuses to automate?",
      "acceptance_basis": "Define the semantic action, consequential target, authority source, approval boundary, consequence exposure and proof requirement first."
    },
    {
      "id": "EVAL-17",
      "discipline": "PILOT_DESIGN",
      "title": "Counterfactual baseline",
      "question": "Can the customer measure what ActionGate would have changed without executing?",
      "acceptance_basis": "Shadow mode may produce WOULD_PERMIT, WOULD_NARROW, WOULD_REQUIRE_HUMAN_AUTHORITY, WOULD_DENY or AUTHORITY_UNRESOLVED."
    },
    {
      "id": "EVAL-18",
      "discipline": "PILOT_DESIGN",
      "title": "Graduation gate",
      "question": "What must be true before consequential execution is considered?",
      "acceptance_basis": "Customer-defined evidence, authority, deployment, connector and operational gates must be satisfied independently; SIO27 cannot grant graduation."
    }
  ]
}