{
  "$schema": "https://cyclonedx.org/schema/bom-1.7.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:5662701a-4a41-48c8-8128-59cb7528077c",
  "version": 1,
  "metadata": {
    "timestamp": "2026-07-11T00:00:00Z",
    "authors": [
      {
        "name": "Hypermedia Au Security Team"
      }
    ],
    "component": {
      "type": "data",
      "name": "Method Validation Specification",
      "version": "1.0.0"
    },
    "properties": [
      {
        "name": "cyberbench:artifact-kind",
        "value": "attestation (declarations document; per method, not per run — no layer)"
      },
      {
        "name": "cyberbench:fullname",
        "value": "Method Validation (ISO/IEC 27041 method assurance — the reliability lever)"
      },
      {
        "name": "cyberbench:claim-predicates",
        "value": "method-validated,method-validation-failed"
      }
    ]
  },
  "definitions": {
    "standards": [
      {
        "bom-ref": "method-validation-v1.0.0",
        "name": "Hypermedia Security: Method Validation Specification",
        "version": "1.0.0",
        "description": "The method-validation attestation: the reliability lever. ISO/IEC 27041 §7.1 states the threat exactly — digital evidence can be challenged on the grounds that methods used to produce it were not fit for purpose, so evidence of fitness for purpose must be producible. This attestation is that evidence, keyed to a method (a workflow or model+task pairing), never to a run, finding, or case. It records the validation scope and outcome as two orthogonal ISO 27041 §5.9 fields, carries the validation evidence a challenger can probe, is time-boxed with a review date, and backs the engine gate: no method backs a disclosed finding unless a current method-validated claim with status fully-validated covers it. Note 27041's own distinction (§5.8.1/§5.8.3): verification (conformance to specification) is not validation (fitness for the investigative purpose) and is not sufficient in its own right — this standard governs validation.",
        "owner": "Hypermedia Au",
        "externalReferences": [
          {
            "type": "other",
            "url": "https://sec.hypermedia.au/attestations/method-validation/v1",
            "comment": "The attestation schema enforcing this standard.",
            "properties": [
              {
                "name": "cyberbench:role",
                "value": "attestation-schema"
              }
            ]
          },
          {
            "type": "other",
            "url": "https://sec.hypermedia.au/standards/analysis-provenance/v1",
            "comment": "cyberbench:methodRef — the gated edge",
            "properties": [
              {
                "name": "cyberbench:role",
                "value": "referenced-from"
              }
            ]
          },
          {
            "type": "documentation",
            "url": "https://www.iso.org/standard/44405.html",
            "comment": "ISO/IEC 27041:2015 — verified against the standard text 2026-07-11 (SPEC-8 note): §5.9.2 comprehensive validation (all possible conditions); §5.9.3 sufficient validation (fit for a particular intended use as defined by the identified requirements); §5.9.4 fully validated (for the intended use defined in the validation plan; 'should, normally, not be employed until it has been fully validated'); §5.9.5 failed validation (review, amend, re-validate); §5.9.1 boundary conditions and error rates, plan independent of design; §6.1/§7.2 validator independence; §7.3 evidence of validation; §7.4 maintenance ('review date has passed… considered unvalidated until re-validation occurs'); §5.10 confirmation and reuse of prior validation; §5.7.1/§5.8.2 work-instruction definition and verification; §5.6.3 the only-tool-available allowance CyberBench deliberately overrides"
          },
          {
            "type": "documentation",
            "url": "https://www.rfc-editor.org/rfc/rfc2119",
            "comment": "RFC 2119 (as clarified by RFC 8174) — requirement key words; only capitalised forms are normative"
          },
          {
            "type": "website",
            "url": "https://sec.hypermedia.au"
          }
        ],
        "requirements": [
          {
            "bom-ref": "method-key",
            "identifier": "METH-001",
            "title": "Method Key",
            "text": "The claim target MUST be a method identifier — urn:cyberbench:method/workflow/<id> for a workflow, or a model+task pairing — and MUST NOT be a finding, analysis run, case, or BOM-Link. At any moment a method has at most one current claim; re-validation supersedes it with a new attestation.",
            "descriptions": [
              "Keying to the method, not the run, is what lets one validation serve every finding that used the technique — ISO/IEC 27041 §5.10 explicitly permits confirming a previously validated process without further validation when it is fully validated for the current investigation, including externally validated processes. The method lives on its own clock: validated before any case uses it, re-validated on a cadence."
            ],
            "parent": "method-validation-v1.0.0",
            "properties": [
              {
                "name": "requirement-uri",
                "value": "https://sec.hypermedia.au/standards/method-validation/v1#method-key"
              },
              {
                "name": "validation-method",
                "value": "schema"
              },
              {
                "name": "target-pattern",
                "value": "urn:cyberbench:method/…"
              },
              {
                "name": "iso-basis",
                "value": "ISO/IEC 27041 §5.10 (confirmation / reuse of prior validation)"
              }
            ]
          },
          {
            "bom-ref": "validation-scope",
            "identifier": "METH-002",
            "title": "Validation Scope",
            "text": "The map MUST state the validation scope as exactly one of: comprehensive — the process was tested under all possible conditions (ISO/IEC 27041 §5.9.2); sufficient — the process was validated against the agreed requirements for the conditions of the intended use, showing it fit for that particular use (§5.9.3). Closed set.",
            "descriptions": [
              "Scope says how broadly the method was tested, nothing about whether it passed. §5.9.2 reserves comprehensive validation for processes deployed regularly across multiple investigation types and teams — it is not considered essential and is likely prohibitively expensive otherwise. §5.9.3's sufficient validation is the working norm: correct results for the type of inputs encountered in the investigation under consideration. Which scope a given finding class requires is per-matter assurance policy, outside this standard."
            ],
            "parent": "method-validation-v1.0.0",
            "properties": [
              {
                "name": "requirement-uri",
                "value": "https://sec.hypermedia.au/standards/method-validation/v1#validation-scope"
              },
              {
                "name": "validation-method",
                "value": "schema"
              },
              {
                "name": "allowed-values",
                "value": "comprehensive,sufficient"
              },
              {
                "name": "vocabulary",
                "value": "closed (locked v1.0.0)"
              },
              {
                "name": "iso-basis",
                "value": "ISO/IEC 27041 §5.9.2 / §5.9.3 (body-text verified)"
              }
            ]
          },
          {
            "bom-ref": "validation-status",
            "identifier": "METH-003",
            "title": "Validation Status",
            "text": "The map MUST state the validation status as exactly one of: fully-validated — the process passed validation for the intended use defined in its validation plan (ISO/IEC 27041 §5.9.4); failed — the process did not pass validation (§5.9.5). Closed set. The claim predicate MUST agree with the status: method-validated is assertable ONLY when status is fully-validated; a failed validation MUST use method-validation-failed.",
            "descriptions": [
              "Status is the outcome axis, orthogonal to scope: §5.9.4's 'fully validated for the intended use defined in the validation plan' means a sufficiently-scoped validation that passes is fully validated relative to that plan — sufficient + fully-validated is a legitimate ISO combination, not a contradiction. §5.9.5 does not discard a failure: requirements, design and implementation are reviewed, amended, and the process re-validated. The failed attestation stays on the record — the honesty is the point."
            ],
            "parent": "method-validation-v1.0.0",
            "properties": [
              {
                "name": "requirement-uri",
                "value": "https://sec.hypermedia.au/standards/method-validation/v1#validation-status"
              },
              {
                "name": "validation-method",
                "value": "schema + predicate-agreement"
              },
              {
                "name": "allowed-values",
                "value": "fully-validated,failed"
              },
              {
                "name": "predicates",
                "value": "method-validated,method-validation-failed"
              },
              {
                "name": "vocabulary",
                "value": "closed (locked v1.0.0)"
              },
              {
                "name": "iso-basis",
                "value": "ISO/IEC 27041 §5.9.4 / §5.9.5 (body-text verified)"
              }
            ]
          },
          {
            "bom-ref": "validation-evidence",
            "identifier": "METH-004",
            "title": "Validation Evidence",
            "text": "The attestation MUST carry evidence of all four kinds: req-capture (the agreed functional and non-functional requirements the validation plan was built from), eval-results (test outcomes including boundary conditions and error rates), known-limitations (documented weaknesses and uncertainty), and template-review (review of the prompt/workflow template — the method's work instruction).",
            "descriptions": [
              "ISO/IEC 27041 §7.3: a record of the outcome of each test, with details of problems encountered, forms the evidence of validation; §5.9.1 requires the plan to be produced independently of design and, where possible, to determine boundary conditions and error rates; §5.5 governs requirements capture; §5.6.3's weakness/uncertainty analysis is the known-limitations kind. template-review is CyberBench's name for reviewing the method's step-by-step definition — approximately ISO 27041 §5.7.1/§5.8.2 work-instruction verification (in 27041 the documented detailed work instruction is the process definition and is verified against the design; for an LLM method the prompt/workflow template is that work instruction). The ≈ is deliberate: a mapped equivalent, not a quoted clause."
            ],
            "parent": "method-validation-v1.0.0",
            "properties": [
              {
                "name": "requirement-uri",
                "value": "https://sec.hypermedia.au/standards/method-validation/v1#validation-evidence"
              },
              {
                "name": "validation-method",
                "value": "schema"
              },
              {
                "name": "required-kinds",
                "value": "req-capture,eval-results,known-limitations,template-review"
              },
              {
                "name": "iso-basis",
                "value": "ISO/IEC 27041 §7.3, §5.9.1, §5.5, §5.6.3; template-review ≈ §5.7.1/§5.8.2 work-instruction verification (owner ruling 2026-07-11)"
              }
            ]
          },
          {
            "bom-ref": "validator-identity",
            "identifier": "METH-005",
            "title": "Validator Identity",
            "text": "assessors[] MUST identify the validator, the attestation MUST be signed by that identity (Fulcio-verified comparison), and the validator MUST be independent of the method's design and implementation.",
            "descriptions": [
              "ISO/IEC 27041 §6.1 requires assurance stages to be carried out independently of the development of the processes — by someone other than the developers — and §7.2 requires the validation set to be produced by a party not involved in the design, implementation and verification of the process. Independence is what makes the validation evidence probative rather than self-serving."
            ],
            "parent": "method-validation-v1.0.0",
            "properties": [
              {
                "name": "requirement-uri",
                "value": "https://sec.hypermedia.au/standards/method-validation/v1#validator-identity"
              },
              {
                "name": "validation-method",
                "value": "certificate-identity-comparison"
              },
              {
                "name": "iso-basis",
                "value": "ISO/IEC 27041 §6.1, §7.2 (validator independence)"
              }
            ]
          },
          {
            "bom-ref": "ongoing-assurance",
            "identifier": "METH-006",
            "title": "Ongoing Assurance",
            "text": "The map MUST state a validUntil date and a scheduled review date. A method whose validUntil has passed MUST be treated as unvalidated until re-validation occurs; re-validation MUST issue a new attestation superseding this one.",
            "descriptions": [
              "ISO/IEC 27041 §7.4 in its own words: validation sets and evidence should be subject to periodic review, and a process which no longer has current evidence of validation — for example because the review date has passed or non-functional requirements changed — should be considered unvalidated until re-validation occurs. validUntil is that rule as a machine-checkable field: the method analogue of Evidence Record renewal."
            ],
            "parent": "method-validation-v1.0.0",
            "properties": [
              {
                "name": "requirement-uri",
                "value": "https://sec.hypermedia.au/standards/method-validation/v1#ongoing-assurance"
              },
              {
                "name": "validation-method",
                "value": "temporal-comparison"
              },
              {
                "name": "iso-basis",
                "value": "ISO/IEC 27041 §7.4 (body-text verified: past review date ⇒ unvalidated until re-validation)"
              }
            ]
          },
          {
            "bom-ref": "validation-gate",
            "identifier": "METH-007",
            "title": "Validation Gate",
            "text": "A finding's analysis-provenance methodRef edge (the claim's externalReference marked cyberbench:role = methodRef) MUST resolve to a method-validated claim whose status is fully-validated and whose validUntil window covers the time of promotion. A method whose current status is failed, or whose validation has lapsed, MUST NOT back a disclosed finding — with no exception for a method being the only one available. The verifier MUST enforce this gate; it is not a convention.",
            "descriptions": [
              "This gate is CyberBench policy, deliberately stricter than ISO/IEC 27041. ISO's own baseline is softer: §5.9.4 says a process 'should, normally, not be employed until it has been fully validated', and §5.6.3 allows that a process exhibiting unknown or high weakness is not necessarily excluded — where it is the only process available it will likely be considered invaluable. CyberBench tightens both on purpose: under the AI-reliability threat model, 'it was the only tool we had' is not a defensible basis for a disclosed finding. 27041 is cited here as the baseline this requirement tightens, not as mandating it (owner ruling 2026-07-11)."
            ],
            "parent": "method-validation-v1.0.0",
            "properties": [
              {
                "name": "requirement-uri",
                "value": "https://sec.hypermedia.au/standards/method-validation/v1#validation-gate"
              },
              {
                "name": "validation-method",
                "value": "cross-reference + temporal-comparison"
              },
              {
                "name": "strictness",
                "value": "CyberBench policy — deliberately stricter than ISO/IEC 27041 §5.9.4/§5.6.3 (owner ruling 2026-07-11)"
              },
              {
                "name": "enforced-by",
                "value": "adbom-cli at verification; analysis-provenance/v1 methodRef is the governed edge"
              }
            ]
          }
        ]
      }
    ]
  }
}