Reactor-physics evidence
A simulation output is a claim. A reviewer has to be able to check it.
Your physicists own the physics. SMRFORGE seals every result they produce as an evidence bundle anyone can verify offline and re-derive from scratch on the free, open engine. When a number was built from another sealed result, it says so by hash, and a reviewer walks the whole derivation. We don’t compute your reactor; we make its numbers checkable.
Not “trust us.” Check us.
Engagements are open now. The Community engine is open source (MIT) and available today; Pro, the assurance layer, is in commercial beta. The physics is free and stays free.
Illustrative. The IAEA-2D closure is code verification against a published reference, not validation against a measured experiment. The seal proves custody, not correctness.
How you check it
Integrity is one command. Re-deriving the number is a deeper one. Walking a derivation is a third. None needs a network, and none trusts us.
A standalone checker confirms the record is intact, complete and signed, and it imports none of our physics, so a pass isn’t us grading our own work. The in-browser version is a from-scratch RFC 8032 Ed25519 verifier with no crypto library behind it. Run it on a real bundle.
A signature can’t catch a signed lie. This re-runs the open engine on the bundle’s own recorded inputs and checks the number comes back: exact for deterministic solvers, within the sealed band for Monte Carlo.
A result built from another sealed result cites it by content hash. The walker checks every link offline, from the upstream constants to the final number, with the upstream bundles you hand it. Custody, end to end.
Sealed cross-bundle chaining
Every bundle pins its inputs and outputs by SHA-256, names the nuclear data it read by
content hash, and seals the toolchain that minted it, machine and solver. When one sealed result feeds
the next, the downstream bundle binds the upstream by hash in a sealed derived_from link.
Alter anything upstream and the chain breaks where it was altered.
$ smrforge verify --chain nodal.bundle.json --from ./upstream root nodal.bundle.json integrity ok signature ok link 1 homogenization sha-256 3b9f… verified consumed few_group matches chain verified · 1 link · no unresolved upstreams note custody, not correctness · fidelity: screening · advisory
The sealed link holds digests of what was consumed. Whether the chain is sound is decided by the verifier that walks it, on your machine, every time. No bundle gets to grade its own upstream.
With the upstream constants sealed and verified, a reviewer can re-derive the deterministic step on them directly, without repeating the expensive calculation that produced them.
The consumed value sits in the downstream bundle’s own sealed inputs and is pinned to the upstream seal, so a swapped upstream, a laundered key, or an edited constant each fail where they were touched.
Any computation, one seal
A bundle seals whatever the computation outputs. Inputs, result, provenance, one SHA-256 manifest, one Ed25519 signature. A single k_eff is the easiest thing to show, so it is the demo. The same record now holds a full-core flux field, a single depletion step, a measured rod-worth comparison and a USL applicability analysis, each sealed and checked the same way.
The full 52-assembly power array is sealed as the array, re-derived exactly on reproduce.
A single depletion step's isotopics, sealed. Screening-grade on a synthetic network, not an irradiated-fuel assay.
The BEAVRS D-bank worth, 811 pcm, sealed with its uncertainty and compared to the measured 788 (C/E 1.03).
An applicability analysis and subcritical-limit margin. The v1 result honestly seals a null defensible USL on screening c_k.
When a result is an array or a stochastic number rather than one value, the bundle carries the full inputs and, where the number is stochastic, a sealed reproduce tolerance, so a reviewer re-runs the open engine and checks the result the same way, not just a headline number.
The seal proves custody of the computation, whatever its shape. k_eff is the demo, not the limit.
Work with us
Most of our work starts as a scoped engagement. We wire the SMRFORGE engine into the analysis pipeline your team already runs, so every criticality, shutdown-margin, and depletion number comes out sealed and re-runnable, not only the one you send in afterward. For an SMR developer heading to the NRC, that’s the work.
We wire the engine into the workflow your physicists already run, over the local MCP and REST surface. Sealing a result becomes one call, and a signed, re-runnable evidence bundle comes back per call, on every number your pipeline computes. Your physicists own the physics. We do not compute your reactor.
How integration works →Also: independent confirmatory analysis (send one number, we re-derive and sign it), evidence packaging, and pre-submission V&V. Lab and academic collaborations welcome. All engagement types → support@smrforge.io
Verification, honestly labeled
These are code-verification closures: the engine checked against analytic solutions and published benchmark references, not against measured experiments. The IAEA-2D −3 pcm and the CE Monte-Carlo +108 pcm floor are our numbers of record; the analytic rows are method-verification tolerances and the OpenMC row is a reproducibility band, not accuracy claims. Screening-grade by design, and every row re-runs from its own bundle.
| Anchor | Compared against | Result | Fidelity |
|---|---|---|---|
| IAEA-2D full core | k = 1.029585 | C−E ≈ −3 pcm | screening |
| Bare-cylinder R-Z | analytic k(B²) | < 2 pcm | screening |
| Infinite-medium k∞ | closed-form 2-group | ≤ 1 pcm | screening |
| In-tree CE Monte Carlo | OpenMC (matched free-gas) | ≈ +108 pcm | screening |
| Criticality (OpenMC) | continuous-energy MC | re-derives in ±3σ | lab |
pcm = per cent mille (10−5 Δk/k). Verification (vs analytic and published references) is not validation (vs measured experiments). Screening k-eff is a trend, not a validated absolute. Nuclear data cited on this site is openly distributable (ENDF/B-VIII.0 and VIII.1).
The fidelity ladder
Every method here runs today. The in-tree engine is screening-grade by design; the graded reference tier is the sealed OpenMC escalation, a field-validated code, cited, reproduced through our evidence spine. Accuracy is OpenMC’s; the auditable evidence is ours. Reference is earned per domain, live today for LWR-lattice and LEU-solution criticality.
Full-core diffusion, in-tree.
Transport on the same inputs.
Continuous-energy, in-tree, screening-grade.
Same inputs, an eigenvalue from a field-validated code, sealed and reproduced through our spine. Reference lives here, earned per domain.
Run it yourself
Community is the whole physics engine and the whole evidence spine, the same tools we use in an engagement. Pro is the assurance layer around them. No physics is ever Pro-only.
Screen a core, escalate it to OpenMC, and ship every result sealed. Free, MIT, source-only.
derived_from)Our engagement work, productized: the assurance package a regulator reads, run in-house.
The seam: physics fidelity, geometry, solvers and the evidence spine ship free in the open core. Pro composes them; it never contains them.
Source-only, by design. Python 3.11+, pure standard library, no dependencies. It is not on PyPI, on purpose: the engine is built for air-gapped and regulated environments, so what you install is the source tree you can read, never a package index. Getting started →
One flag per declared input. smrforge tools lists the open capabilities and
smrforge schema <card> prints one card’s inputs; a missing or misspelled input is a
named error, not a stack trace. The output is a sealed evidence bundle.
Register the open cards, call run_capability(name, inputs), and get the result and the
same sealed bundle back: the same input checks, the same record.
A standard-library HTTP server bound to 127.0.0.1. POST a JSON body to run a card and the response is the bundle; the same server speaks MCP to an AI agent. No web framework, no network fetches.
What runs where. The in-tree engine runs anywhere Python does. The lab-grade OpenMC path needs a real OpenMC install and a continuous-energy cross-section library on your host; without them those cards refuse, rather than fabricate a number.
Questions
Longer ones on the info sheet and in the open repository.
smrforge verify
checks integrity offline with a checker that imports none of our physics. smrforge reproduce
re-runs the open engine on the bundle’s own inputs. When a result was built from another sealed
result, its bundle binds the upstream by hash in a sealed derived_from link, and
smrforge verify --chain <bundle> --from <dir> walks every link offline. The link
carries facts, never a verdict: the verifier that walks the chain decides.pip install -e . (Python 3.11+). Not on PyPI, by design. Also public: the
Evidence Envelope standard, its single-file reference verifier with no SMRFORGE import, and the
reviewer kit. Pro is source-available (FSL-1.1) and licensed, in commercial beta.smrforge serve starts a standard-library HTTP server on 127.0.0.1 (port
8765 by default) fronting a REST API (POST /v1/run/<capability> returns the signed
bundle; /v1/tools and /openapi.json describe it) and an MCP endpoint
(JSON-RPC 2.0 at /mcp) for AI agents. No web framework, no network fetches. Pro cards are
not served by the open server; they need an entitlement token.Talk to us
Tell us which codes your reactor numbers come out of and we scope the integration from there. Or bring us a single number and we hand it back as a signed confirmation your reviewer re-runs offline. Engagements, pilots and Pro, all at support@smrforge.io.