-
Notifications
You must be signed in to change notification settings - Fork 10
Full Examples
SANKET SARKAR edited this page Dec 22, 2025
·
1 revision
This page points to the repo’s concrete example documents and explains how to use them for common risk-management workflows.
Everything here is engine agnostic and UI agnostic: CRML defines the document contracts, while engines decide which model IDs and runtime features they support. Assume CRML Studio can be used to manage the documents, run validation, and trigger simulations/risk modelling through your configured engine.
- examples/scenarios/fair-baseline.yaml (FAIR-inspired baseline)
- examples/scenarios/data-breach-simple.yaml (simple breach baseline)
- examples/scenarios/ransomware-scenario.yaml (ransomware baseline)
- examples/scenarios/ransomware-with-controls.yaml (control-relevant threat)
- examples/scenarios/multi-currency-example.yaml (currency-tagged inputs)
- examples/scenarios/qber-simplified.yaml (QBER-inspired structure)
- examples/portfolios/portfolio.yaml (scenario aggregation, assets/exposure, control packs)
- examples/control_catalogs/control-catalog.yaml
- examples/control_assessments/control-assessment.yaml (Assessment pack)
- Start with a baseline scenario (e.g., FAIR-style).
- Create a one-scenario portfolio that references it.
- Validate and run.
- Capture assumptions and data sources in the scenario
meta.
- Create multiple scenarios for distinct threat classes.
- Build a portfolio with explicit aggregation semantics.
- Add assets/exposure and bind scenarios to the relevant assets if applicable.
- Maintain canonical control IDs in a control catalog.
- Track organization evidence in an assessment catalog.
- Reference both from the portfolio.
- Ensure each scenario declares which controls are relevant (scenario controls).
- Tag severity inputs with their currency.
- Provide an external FX config at execution time.
- Scenario/portfolio schemas are strict; avoid adding engine-specific keys into the CRML documents unless your tooling explicitly supports that.
- Model identifiers are engine-defined; not every engine will support
mixtureor hierarchical frequency models. - “Pipelines” (MCMC, diagnostics, exports) are deliberately outside the CRML core documents; treat them as engine/tool configuration.