SMRFORGE

Work with us

Scoped engagements · founder-led · reactor physics you can prove

Bring us a number a reviewer won’t take on faith.

Your physicists own the physics. We do not compute your reactor. We make its numbers checkable. Most of our work starts as a scoped engagement. We produce the evidence with you, and you leave with sealed bundles a reviewer can verify offline and re-derive from scratch on the free, open engine.

For an SMR developer heading to the NRC, or a team that needs an independent confirmation before a submission, that is the work.

One engagement, at a glanceFlagship
you sendone number. Your k_eff or shutdown margin, as your code reports it.
we re-deriveon the open engine, escalated to OpenMC where it has to hold up
you leave witha signed, reproducible confirmation. Inputs hashed, toolchain recorded, lineage walkable.
reviewer runs$ smrforge verify · $ smrforge reproduce · offline
alsoevidence packaging · pre-submission V&V · pipeline integration
custody, not correctness · advisory · air-gap-safeSCOPED

A confirmation makes your number checkable. It is not a certification, and your reviewer still makes the call.

Flagship engagement · independent confirmatory analysis

The same number, as it arrives and as it leaves.

Send us your criticality or shutdown-margin number. We re-derive it on the open engine and OpenMC and hand back a signed, reproducible confirmation your reviewer can re-run. A second opinion that checks itself, not one they have to trust.

One confirmatory engagement, end to end · values illustrative

As it arrivesyour number, as sent
> k_eff, from your own code
1.00210 “Our code says.”
inputsin a deck and an email thread
data libraryunstated
engine buildwhatever ran that day
second opinionnone
sealed bynobody
re-runnot possible
Defensible later? No. Whoever signs the submission is on their own.
the engagement
  1. 1Rebuild the model from your inputs, each one recorded and hashed
  2. 2Re-derive on the open engine
  3. 3Escalate to OpenMC, held to the committed band
  4. 4Seal and sign inputs, result, toolchain, lineage
Your number never gets altered. It gets a second one to stand next to.
As it leavesthe same number, confirmed
> the same model, rebuilt from your inputs
1.00198± 0.00031 open engine · OpenMC · ENDF/B-VIII
inputsrecorded, each hashed in the manifest
data libraryENDF/B-VIII, library hash recorded
engine buildopen engine + OpenMC, signed toolchain recorded
your number1.00210 · 12 pcm apart · inside the committed band
sealed byed25519, the SMRFORGE signing key
re-runby anyone with the open engine
$ smrforge verify confirmation.json
  OK · integrity + origin
$ smrforge reproduce confirmation.json
  re-derived within 3σ
Defensible later? Yes. By anyone, offline, without asking us.

Illustrative. The k_eff values above are placeholders, not a client result. The seal proves custody, not correctness. Verify runs offline anywhere. Reproduce needs the open engine installed, because a browser cannot run an eigenvalue solve.

Every way in

Four engagements. One deliverable shape.

Each one ends the same way. A sealed bundle your reviewer verifies offline, with the recorded inputs a re-run needs. Pick the row that matches what you are bringing.

How an engagement works

From your number to a reviewer’s re-run.

Four moves. You make the first and your reviewer makes the last. The two in the middle both end in a seal.

01you

Bring a number.

Your k_eff, shutdown margin, or a result from any code. Tell us what it is, which code produced it, and who has to accept it.

02SMRFORGE

We re-derive it.

On the open engine, escalated to OpenMC where it has to hold up. Your inputs never get altered. Each one gets recorded and hashed.

03SMRFORGE

You get a sealed bundle.

manifest
  inputs/        sha256
  result.json    sha256
  provenance/    engine · library · toolchain · seed
signature      ed25519

Signed, with the data pinned, the toolchain recorded, and the lineage you can walk end to end.

04your reviewer

They re-run it.

$ smrforge verify
  OK · integrity + origin
$ smrforge reproduce
  re-derived within 3σ

Offline, with a checker that imports none of our physics. Verify works in a browser. Try the checker. Reproduce needs the open engine installed.

What the seal proves

Custody, not correctness.

A sealed number from a badly specified model is a faithfully preserved wrong answer. Every result says what grade it is. Here is the line, drawn plainly.

A confirmation proves

  • The number is unaltered since it was sealed, and anyone can check that offline.
  • It re-derives from its own recorded inputs on the open engine, within the committed band.
  • The toolchain that minted it is recorded inside the seal and covered by the signature.
  • The engine is benchmarked against public references on open ENDF/B-VIII data. Of record today, an IAEA-2D full-core closure of −3 pcm against the published reference (code verification, not measured validation) and a continuous-energy Monte Carlo floor of +108 pcm, signed.

A confirmation does not prove

  • That your model is right. We re-derive the number from your inputs. We do not certify the inputs.
  • Licensability. A confirmation is not a certification, and nobody should license a reactor on it alone.
  • Reference fidelity by default. SMRFORGE results are screening-to-reference grade and advisory, labeled for fidelity on every result. It is not a licensing code.
  • A solve in your browser. Verify runs offline anywhere. Reproduce needs the open engine.
Advisory, by design. A confirmation makes a number checkable. Your physicists still own the physics, your reviewer still makes the call, and the seal hands them something to check instead of someone to trust. Want to see the seal hold or fail before you send anything? Try to break it.

Start one

Bring us a number.

SMRFORGE is founder-led. The person who reads your email is the person who does the work. Tell us what the number is, which code produced it, and who has to accept it, and we scope the engagement from there. support@smrforge.io