Add optional probabilistic / uncertainty fields for AFR, Impact, and Risk values

[github-actions]

Motivation

Traditional TARA records single-point AFR/Impact/band values which conceal uncertainty and analyst judgment. Modern risk guidance (NIST IR/SP guidance, FAIR-like quantitative techniques, Monte Carlo) increasingly recommends representing uncertainty explicitly (three-point estimates, distributions, CI) so decisions (treatment, CAL decisions, regulatory reporting) can account for variability and be audited. Enabling a machine-readable way to capture distributions, estimation method and simulation references will improve traceability, reproducibility, sensitivity analysis and support automated decision-making across toolchains.

Proposed change

Introduce an optional standardized structure on attackFeasibilityRatings[], impactRatings[], and riskValues[] to capture probabilistic inputs and outputs. Backwards-compatible (fields optional).

Schema-level changes (concrete):

• Add optional fields to attackFeasibilityRatings / impactRatings / riskValues objects:
  • uncertainty: {
    method: enum ["point","triangular","normal","beta","empirical","three_point","bayesian","monte_carlo"],
    description: string,
    confidence: {level: "low"|"medium"|"high", percentile: {lower:number, upper:number}},
    parameters: object // keyed by method, e.g. for triangular {min,mode,max}; for normal {mu,sigma}; for empirical {samplesRef}
    }
  • distribution: {
    type: string, // e.g. "triangular","normal","empirical"
    parameters: object
    }
  • simulationRef: uri // link to evidenceStore / content-addressable file containing raw simulation output (e.g., Monte Carlo traces), schema: {type: "artifact", ref: <cid|url>, created, tool, version}
  • summaryStatistics: {mean:number, median:number, variance:number, percentileValues: [{p:number,v:number}]}
  • sensitivityAnalysisRef: uri // optional link to analysis report

Implementation notes:

• Provide three example use-cases in examples/ (one three-point estimate, one normal-with-parameters, one Monte-Carlo summary linking to simulation artifact in evidenceStore). Put simulation artifacts in examples/evidence/ and reference them.
• Update methods[] metadata to include allowed distribution types and mapping rules so methodId can declare the expected uncertainty encoding (e.g., iso-pas-8475-taf-v1 supports 'three_point' inputs).
• Update JSON schema and XSD to validate parameter shapes and numeric ranges.
• Add guidance to methodology describing how to convert probabilistic inputs to the existing band fields (band may continue to be used for human-display) and link to provenance (who ran the simulation, tool version, seed, date).

Mapping to RDX requirements:

• RDX-021 AttackFeasibilityRatings (extends: enrich AFR with distribution/uncertainty)
• RDX-023 ImpactRatings (extends: support impact distributions)
• RDX-025 RiskValues (extends: record probabilistic combined risk with summary stats)
• RDX-067 / UC_001_1 (enables richer product risk reports)
• RDX-117 (new requirement): "RDX SHOULD support optional probabilistic representations for AFR/impact/risk including distribution parameters, summary statistics, simulation artifacts and provenance."

References

• NISTIR / NIST guidance on risk estimation and quantitative methods (IR 8286 family and SP guidance on risk assessment) encouraging quantitative techniques (three-point, Monte Carlo). https://csrc.nist.gov/publications
• SP/peer literature describing Monte Carlo and probabilistic cyber risk: example survey & Monte Carlo use for cybersecurity risk estimation. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10056427/
• Academic/industry work on PRA / uncertainty handling as normative practice (EPA/NRC guidance on PRA uncertainty handling illustrates accepted practices for distribution encoding and CI reporting). https://www.epa.gov and https://www.nrc.gov

Acceptance criteria

1. Schema: spec/json/rdx.schema.json contains the new optional uncertainty/distribution/simulationRef/summaryStatistics fields on attackFeasibilityRatings, impactRatings and riskValues and the shape is validated by ajv with new examples added.
2. XSD: spec/xml/rdx.xsd includes equivalent elements and example XML files validate via xmllint.
3. Examples: Add at least three new examples: examples/rdx-afr-three-point.json, examples/rdx-impact-normal.json, examples/rdx-risk-montecarlo.json — each validates and includes simulationRef links to artifacts in examples/evidence/ (small CSV or JSON traces) and a human-readable summary.
4. Methodology: Add a short guidance document (methodology/probabilistic-risk.md) describing recommended practices for methods authors, how to declare distributions in methods[], and how consumers should compute band mappings from distributions.
5. Tests: CI validates examples and new fields; tools/validate.sh updated to include new examples.
6. Requirements: REQUIREMENTS.md updated with RDX-117 (new requirement) and clear mapping to RDX-021/023/025 extension notes.

---

Generated by tools/ai_idea_scout.py via the AI Idea Scout workflow.
Review the proposal, refine the title/body/labels, and close if not desired.