SMRFORGE

For reviewers and regulators

Reactor-physics evidence · one file, checked offline

A number you can re-run, not take on faith.

Your team computes a reactor-physics number in whatever code it already uses. SMRFORGE seals that result, the inputs that fed it, and the provenance that produced it, into one SHA-256 manifest with one Ed25519 signature. The bundle is self-contained, so anyone downstream can confirm it offline and re-derive it, without trusting the model, the vendor, or us.

Not “trust us.” Check us.

Anatomy of a sealed result
hashes illustrative · custody, not correctnessCHECKED

The seal proves the number is unaltered and re-derives from its own recorded inputs. Fidelity is labeled on every result, and every result is advisory.

Why a reviewer wants it

Five things a regulator wants from a number.

A reviewer has to defend a number they did not produce. The seal delivers each of these. The fourth is the one the person signing cares about most, so it carries the warm mark.

01FASTER

Checked in milliseconds, not hours.

Verify is a hash check and a signature check. It runs offline on the reviewer’s own machine, with no cluster and no re-run of the pipeline. If anything inside the bundle changed, the checker names the section.

02COST EFFECTIVE

A laptop, not a cluster.

The expensive Monte Carlo runs once. Downstream, a reviewer re-runs only the cheap deterministic step on the sealed upstream constants, which were already verified. A laptop does it.

03SMARTER

No trust in the producer.

The tolerance is committed before the run, not fitted after it. The seal covers the fingerprints of every input and output, so a doctored value is caught while the signature stays valid. Nothing rests on the producer’s word.

04JUST AS SAFE

Nothing about the safety basis changes.

The reviewer’s own validated codes and V&V still produce the number. SMRFORGE adds a checkable record beside the existing process and never becomes the authority over it. Adopting it subtracts no rigor.

05DURABLE

Still checks decades out.

The bundle verifies offline years later with just the file and the public key. It outlives the author, the cluster, and the tool that made it.

verify = hash + signature, offline · reproduce = re-run the open engine on the recorded inputs amber marks the human decision

Go deeper

Each of these has its own page. This one stays short.

Three pointers. None of them asks you to trust us first.

proof-layer.html

The Proof Layer

How a sealed result sits alongside your AI rather than in front of it, and how an orchestrator running many agents leaves a chain a reviewer can walk.

Read the proof layer →
sealed-results.html

Sealed results

The record holds more than k_eff. See what a sealed result carries, and which shapes of number the seal covers today.

See the sealed results →
check.html

Check a bundle

Verify a real sealed result in your browser, then tamper with one byte and watch the seal catch the change. No install, no server, no SMRFORGE code.

Check one now →
Said plainly. The seal proves custody, not correctness. A sealed number from a badly specified model is a faithfully preserved wrong answer. Verify runs offline and imports none of our physics. Reproduce needs the open engine installed, because a browser cannot run a Monte Carlo eigenvalue solve. Results are screening-to-reference grade, labeled for fidelity, benchmarked against public references on open ENDF/B-VIII data, and advisory. SMRFORGE is not a licensing code. It sits alongside the labs and your validated codes, and replaces neither.

Check us

Take the brief, or take the bundle.

Founder-led, and reachable. Download the two-page brief for the people who have to defend the number, or skip the brief and verify a sealed result in your browser in about a minute. Questions, bundles you want checked, and review requests go to support@smrforge.io.