A model you can read without the software
The OpenPRA Model Exchange Format is the part of this project most likely to outlive it. It is defined once, in TypeScript, and published as JSON Schema — so a regulator, a reviewer, or a competing tool can read a model without asking anyone's permission.
Where this format comes from
The OpenPRA MEF is not a new idea. It descends from the Open-PSA Model Exchange Format, published between 2007 and 2017 by the Open-PSA Initiative — a group of PSA practitioners and researchers who argued that a model tied to the software that made it is a model nobody can check. They wrote the specification, chose XML, and set out the layered architecture that a PRA model needs: stochastic, fault tree, meta-logical, event tree, and report.
Steven “Woody” Epstein (1948–2019) was one of the founders of that Initiative. He spent thirty-five years in probabilistic risk assessment, on more than twenty plant assessments, and after 2011 wrote a practitioner's independent assessment of Fukushima Daiichi. The argument this whole project rests on — that a model no one outside the organisation can read has never really been reviewed — is his and his colleagues' argument before it was ours.
That lineage is operational, not sentimental. OpenPSA XML is a first-class input to PRAXIS through a documented mapping specification with its own diagnostics catalogue and placeholder policy — not a legacy importer bolted on the side. A model written against the Open-PSA format two decades ago should still open.
What OpenPRA adds is a single TypeScript source of truth, JSON Schema generated from it rather than maintained alongside it, and coverage of the technical elements RA-S-1.4 requires. The premise underneath is unchanged.
The Open-PSA Model Exchange Format specification is listed under Foundations on the Research page, alongside Kaplan and Garrick.
One definition, two artefacts
TypeScript definitions
The single source of truth. Every domain type and DTO in the platform comes from here, so the app and the schema cannot drift apart.
Generated JSON Schema
Emitted from the definitions rather than maintained by hand. Validate a model against it in any language — and hand it straight to the solver, since PRAXIS reads the MEF natively rather than converting first.
Translation and generation
OpenPSA MEF XML in and out, a SAPHIRE round trip through PRAXIS, and generation of models from systems engineering descriptions (MBSE).
Mapped against RG 1.247
Trial Regulatory Guide 1.247 endorses ANSI/ASME/ANS RA-S-1.4-2021 for advanced non-LWR risk-informed activities. The schema has been walked against it to find where it does not yet carry what a peer review would ask for. The gaps are written down rather than quietly left out, and they drive what gets built next.
Being able to represent something is not the same as it being right. The schema is a container; the analysis is still yours.
Methods, not just numbers
The HRA module carries THERP, IDHEAS, and NUREG-1792 as structured method definitions — performance shaping factors, dependency, and recovery kept in the model rather than in a spreadsheet that travels separately and gets lost.
A human error probability without the method that produced it is not reviewable. The schema refuses to store one that way.
Why a model exchange format at all
This list is not ours. It is adapted from section 2.1 of the Open-PSA Model Exchange Format specification, where the case was made first and made well. Two decades on, most of it still holds.
- Two tools cannot open the same model without a bespoke converter.
- A model written last year may not open next year.
- There is no common format for the industry's own data.
- Numerical approximation and truncation are relied on without being stated.
- Calculations are hard to quality-assure because the method is not recorded.
- Models do not travel between organisations, so review is shallow.
- Human actions are modelled in ways that cannot be re-derived.
- Scenarios not yet thought of have nowhere to live in the model.
- Digital and autonomous control systems have nowhere to live in the model.
- Results are hard to visualise, so insight stays with whoever ran the model.
- Models are unclear: what a model actually represents is not evident from the file.
- The completeness of a model is asserted rather than shown.