SMRFORGE

The Proof Layer

Reactor-physics evidence · complements production AI

The numbers your AI produces,
made provable.

Your AI produces the number. SMRFORGE makes it something the accountable person can stand behind. A sealed result carries everything needed to re-run it, so anyone downstream can reproduce and verify it without trusting the model, the vendor, or us.

Not “trust us.” Check us.

Verify a bundle yourself → See the code
One sealed number
1.001742± 0.000285
LEU-COMP-THERM-008 · OpenMC · ENDF/B-VIII.1
bundle_sha256sha256:0f98…c8e8 The manifest. Every input, the result, and the data library it read, each hashed into one digest.
signatureed25519 cfb88804… Who sealed it, and that nothing inside the bundle has changed since.
verifyOK · integrity + origin Checked offline by a tool that imports none of SMRFORGE’s physics.
reproducere-derived within 3σ Re-run on the open engine from the recorded inputs, held to the committed band.
offline · no trust requiredCHECKED

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

The problem

AI produces numbers faster than anyone can defend them.

The person who acts on a number has to defend it later. An engineer signing a design. An auditor signing off. A regulator deciding whether to believe it. For that person, “the model produced it” is not an answer. They need to open the number up and re-derive it. In nuclear this is the whole bottleneck. Every safety-relevant number is defended to the NRC by hand, for months.

The same number, twice

Undefendedas it leaves the model
> k_eff for this LEU lattice?
≈ 1.0017 Trust me.
inputsnot recorded
data libraryunstated
engine buildunknown
sealed bynobody
re-runnot possible
Defensible later? No. Whoever signs it is on their own.
Sealedas it leaves the proof layer
> the same question, the same model
1.001742± 0.000285 LEU-COMP-THERM-008 · OpenMC
inputsrecorded, each hashed in the manifest
data libraryENDF/B-VIII.1, library hash recorded
engine buildOpenMC, signed toolchain recorded
sealed byed25519 cfb88804…
re-runre-derived within 3σ
Defensible later? Yes. By anyone, offline, without asking us.

How it complements your AI

It sits alongside your AI, not in front of it.

The model’s reasoning stays a black box. The result it lands on does not have to.

Your AI · any model, any vendor

Produces the number

reasoning · black box · stays yours
k_eff      1.001742 ± 0.000285
inputs     lattice, materials, library
engine     OpenMC, run on your side

The model gets to its answer however it gets there. SMRFORGE never looks inside, and does not need to.

SMRFORGE · the proof layer

Seals it, then signs it

manifest
  inputs/        sha256
  result.json    sha256
  provenance/    engine · data library · toolchain · seed
bundle_sha256  sha256:0f98…c8e8
signature      ed25519 cfb88804…

Every input, the result, and the provenance that produced it, hashed into one manifest and signed. The bundle is self-contained. Nothing in it needs a network or a vendor to check.

The accountable person · engineer, auditor, regulator

Checks it cold

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

Verify runs anywhere, with a checker that imports none of SMRFORGE’s physics. Reproduce re-runs the open engine on the recorded inputs, so it needs the engine installed. A browser cannot run an eigenvalue solve, and this page does not pretend it can.

1 · your AIcomputes a number
2 · SMRFORGEseals inputs · result · provenance, then signs
3 · any reviewerverify offline · reproduce on the open engine

SMRFORGE adds a defensibility layer to what you deliver. It does not replace any of it.

When an agent’s work ends in a real calculation, that calculation can be sealed, independently re-run, and signed, so the engineer or regulator downstream can confirm it cold. It is the auditability, traceability, and reproducibility layer alongside a production AI system. The labs stay where they are. So does the model. The open kernel underneath it, the seal, the verifier and reproduce, is proof-core, free and MIT. If you’d rather build on it yourself, start there.

Agentic pipelines

An orchestrator that calls SMRFORGE leaves a trail, not just an answer.

smrforge serve is live today. One local process, pure Python standard library, no web framework, nothing fetched at runtime, so it runs air-gapped. It fronts a REST API and an MCP endpoint. An agent can run a SMRFORGE capability as one step in its workflow and get back a signed evidence bundle.

One step, two doors · 127.0.0.1:8765

# MCP, for agents (JSON-RPC 2.0)
POST /mcp
{ "jsonrpc": "2.0", "id": 7,
  "method": "tools/call",
  "params": { "name": "smrf_run_<capability>",
              "arguments": { ...declared inputs... } } }

-> result content: the signed evidence bundle
# REST, for everything else
POST /v1/run/<capability>
Content-Type: application/json
{ ...declared inputs... }

-> 200, body: the signed evidence bundle
GET  /v1/tools       the open capabilities
GET  /openapi.json   the generated spec

Same bundle through either door. The MCP tool list and the OpenAPI spec are generated from the capability cards, so an agent discovers what it can run with tools/list and the spec cannot drift from the code.

The trail · each step binds to the one before it

step 1 · screening solve
bundle_sha256 sha256:…a1
derived_from none, this is the root
step 2 · reference solve
bundle_sha256 sha256:…b2
derived_from sha256:…a1 · consumed input, pointer, digest
step 3 · shutdown-margin gate
bundle_sha256 sha256:…c3
derived_from sha256:…b2 · consumed input, pointer, digest
reviewer · human or agent
$ smrforge verify step-3.json --chain --from ./chain/
walks every link backwards, offline, nothing fetched

The link lives inside the seal, so the signature covers it. A reviewer walks the chain and re-checks it offline, re-running only the cheap deterministic steps. The orchestrator did not just produce an answer. It produced a trail someone else can audit. Hashes above are illustrative.

Live today

  • smrforge serve, REST and MCP on localhost, standard library only
  • A signed evidence bundle returned per call
  • Sealed derived_from links between steps, binding by content hash
  • smrforge verify --chain walks the links offline

The direction, not a finished claim

  • Autonomous orchestration across a whole pipeline
  • Agents chaining and re-checking each other end to end
  • This is what the layer is built for. It is not shipped as a product today.

AI can produce the number. SMRFORGE is what makes it defensible.

Check it yourself

The three moves a reviewer makes.

No trust in us required. Verify, reproduce, redact. None needs a network.

$ smrforge verify <bundle>

Confirm the seal offline

A standalone checker that imports nothing from our engine. A pass is a real second opinion, not us grading our own homework. Run it on a real bundle in your browser.

$ smrforge reproduce <bundle>

Re-run the open engine

Re-derive the number from the sealed inputs, with the open engine installed. This is what a signed PDF cannot do. It proves the number is real, not just unaltered.

redact

Seal without exposing

Strip a customer’s inputs from a public copy while the seal still verifies. Provably sealed and untampered, inputs never shown.

What the seal proves, and what it does not. Custody, not correctness. A sealed number from a badly specified model is a faithfully preserved wrong answer. Verification against the bundle is not validation against a measurement. SMRFORGE results are screening-to-reference grade, labeled for fidelity, benchmarked against public references on open ENDF/B-VIII data, and advisory. It is not a licensing code.

Try it

Don’t trust us. Check us.

The physics engine is free and MIT-licensed. The evidence is the product. Verify a sealed reactor number and watch the seal catch a tampered one, in your browser, in about a minute, with no install, no server, and no SMRFORGE code.

Check a bundle → Read the code on GitLab Or try to break the seal