Open methodology, written for analysts and the people who sign off the analysts' work. No hand‑waving. Every choice has a reason; every reason has a published threshold.
Inputs we validate before a single iteration runs.
A Monte Carlo built on a bad register is a Monte Carlo that produces bad numbers, faster. We refuse to run iterations on inputs that fail any of the structural checks below. Anything else surfaces as a warning the analyst sees, decides on, and signs off.
Correlation matrix positive semi‑definiteness — a matrix that isn't PSD can't be sampled from without inventing variance. We test with the standard eigen‑decomposition and route the matrix through Higham's nearest‑PSD repair before sampling.
Three‑point ordering — minimum ≤ most likely ≤ maximum. Reversed or equal endpoints fail the check; we don't silently re‑order them.
Distribution‑family validity — every risk and duration uncertainty input declares its distribution. We only accept families on the AACE‑published list and check the parameters make sense for that family (e.g. BetaPERT shape parameter ≥ 1).
Probability bounds — risk probabilities live in (0%, 100%) open interval. Exact 0 and exact 100 are flagged for review — they almost always indicate a register modelling mistake.
Mapping coverage — every risk maps to at least one activity, unless it's explicitly flagged as non‑schedule. Orphan risks are caught at validation time, not after a five‑hour run.
Split impact totals — where a risk's impact is split across activities, the weights sum to 100% exactly. Off‑by‑one‑percent rounding errors fail the check.
Once inputs validate, we generate iteration samples by drawing correlated uniform variates through the NORTA (Normal‑to‑Anything) transform, then mapping each marginal onto its declared distribution family.
Higham PSD repair
Real‑world correlation matrices, hand‑built by analysts, are almost never positive semi‑definite. Higham's algorithm finds the nearest PSD matrix in Frobenius norm. We log the distance between original and repaired matrix — if it's material, the analyst sees it.
NORTA transform
Normal‑to‑Anything turns one correlated multivariate‑normal sample into samples from any marginal family while preserving the correlation structure approximately. We use rank‑based correlation throughout — see attribution below for why.
Triangular
The QSRA workhorse. Three parameters, no shape assumption, easy to defend to a non‑statistician. We accept it as a default when the analyst doesn't have shape data.
BetaPERT
Three‑point with shape parameter — weights the central tendency more heavily than Triangular. Common in cost risk and infrastructure schemes where expert judgement says "it's more likely to be near the middle".
Uniform
Two‑point. Use sparingly — uniform usually signals "we don't know yet" rather than "all values are equally likely". Risk Studio flags Uniform‑heavy registers as something to revisit.
Discrete
For risks with a finite list of outcomes — typically threats with two or three named scenarios, each with a stated probability. Probability weights must sum to 1.
Two further families — LogNormal and Normal — are supported for cost risk migration; they aren't recommended for schedule risk and Risk Studio surfaces a warning when they appear on duration uncertainty inputs.
03 · Iterations & convergence
10,000 iterations by default. We stop where the answer stops moving.
10,000 iterations is the published default and the number every scheme on our active UK infrastructure programme runs at. We made it the default because for the schemes we benchmark — 100 to 800 activities, 30 to 200 risks — the P50/P80/P90 estimates stabilise inside that count.
From V0.31 onwards, we publish a convergence diagnostic with every run: the running P80 estimate plotted against iteration count, with a tolerance band. If the diagnostic shows the P80 still wandering at 10,000, the report surfaces it. The analyst either runs longer or notes it as a caveat. We don't auto‑extend silently. The decision to accept a result is the analyst's, not the engine's.
S‑curve · M3 post‑mitigation10,000 iterations of a six‑hundred‑activity scheme — the curve through P80 is stable to under a working day.04 · Attribution
Spearman rank tornados — and why Spearman, not Pearson.
The tornado chart answers the question every steering group asks: which risks are driving the P80 result? We attribute using Spearman rank correlation between each input and the output finish date.
Pearson correlation measures linear association — fine when inputs and outputs are both roughly Gaussian. QSRA outputs almost never are. The duration to a key milestone is a chain of dependent activities, each with its own skewed distribution, hitting bottlenecks and constraints non‑linearly. Pearson on that produces tornado ordering that mis‑ranks high‑impact non‑linear risks.
Spearman rank correlation is monotonic — it picks up "as this input gets larger, the output gets larger" regardless of whether the relationship is linear or curved. For QSRA tornado ordering it's the correct measure, and it's what the AACE methodology guidance recommends.
05 · Per‑decile attribution
What drives the P10 isn't always what drives the P80.
A single‑tornado view answers "which risks drive the average outcome?". But the question that matters at sign‑off is usually "which risks drive the bad outcomes?" — and the answer can be different.
V0.30.3 added per‑decile attribution. For each decile of the output distribution we apply a re‑weighting factor decile_factor(d) = 0.4 + 1.2 × (d/9), then re‑rank risks. The result: fast tails (P10) surface rare‑but‑huge risks that almost never fire but devastate the schedule when they do; heavy tails (P80, P90) surface high‑probability risks that fire in bulk and accumulate.
It's a model‑based re‑ranking, not an iteration‑direct one — the Safran exports we benchmark against don't carry per‑iteration risk attribution at sufficient resolution. We flag this explicitly in the response payload and the report. The technique is honest about what it can and can't see.
06 · Audit‑replay
Every run, captured. Any past period, re‑runnable to byte‑identical output.
A QSRA result has to stand up six months later, to a regulator, to a project board, to an insurance underwriter. "We ran it and got 14‑June" isn't an answer if you can't show how you got there.
What's captured per run — inputs (XER, register, correlation matrix, mapping), full configuration (framework choice, thresholds, distribution selections), pseudo‑random seed, code version, output hashes (S‑curve points, tornado ordering, P‑values).
HMAC chain — each run's hash is computed over the previous run's hash plus the new payload, signed with a server key. Tampering with any past run breaks the chain from that point forward.
Byte‑identical re‑run — re‑running a historic period from its captured bundle produces the same output to the bit, on the same machine. We test this on every release: V0.31.1 added a determinism test that re‑runs a benchmark scheme twice and compares output bytes.
How a regulator spot‑checks — they pick a period from your audit log, ask you to re‑run it, and compare the new output against the archived one. If they match, the chain is intact; if they don't, your tooling has a bug. Either outcome is the right one to know.
Audit log · live viewEvery run, every user, every hash — chained, signed, regulator‑ready.07 · Validation vs Safran
How we validate against Safran.
Risk Studio's Monte Carlo engine is benchmarked against Safran on every scheme we run. We benchmark every Monte Carlo scheme against Safran and share the per‑scheme comparison under NDA.
Parity validation is ongoing. Rather than publish achieved tolerance figures ahead of that work being complete, we hold the bar at "shown, not claimed" — we walk procurement and assurance teams through the live comparison on a call, on their own data if they bring an XER and a register. We publish the benchmark register to procurement teams on request.
Anything outside our internal acceptance bands triggers a methodology review before a result goes into a client report. If you need the current benchmark position for a specific scheme or framework agreement, ask — we'll share what we have under NDA rather than round a number for a webpage.
08 · Caveats
What the maths can't tell you.
A defensible QSRA is one that's honest about its limits. Here are the limits.
Model risk.
A Monte Carlo is a model. Models embed assumptions about how risks interact, how distributions behave, and how the schedule responds to delay. Risk Studio is explicit about every one of those assumptions — the SOMA QSRA Readiness checks force them onto the page — but no validator removes the underlying truth that the model is not the world.
Data quality dependency.
Garbage in is still garbage out. The validation framework catches structural errors and ordering mistakes; it cannot catch a risk register that's missing the three risks no‑one wanted to write down. The most important step in a QSRA is the workshop that builds the register — Risk Studio supports it, but it can't replace it.
What Monte Carlo doesn't model.
Resource constraints (unless explicitly encoded as risks). Black‑swan events outside the population the distributions were calibrated against. Step changes in scope. The day the M25 closes for an unrelated incident. The model gives you a defensible probabilistic view of known risks acting on the current schedule — that's a lot, and it isn't everything.
If you're carrying a QSRA into an assurance review, lead with these caveats. Anyone serious will respect you more for naming them than for pretending the maths is bigger than it is.
Methodology pack
Drop this into your assurance pack.
A signed, version‑stamped PDF including the per‑scheme benchmark register and the SOMA QSRA Readiness V2.9 framework rationale. Written so an assurance reviewer can sign off the maths without a follow‑up call.
