@sealed · .seal(inputs)
Seal the output
Wrap the result, its inputs, and how it was made into one signed file. A SHA-256 manifest of every part, an Ed25519 signature over the whole.
proof-core · the open evidence kernel
An AI answer you can’t re-derive is an opinion.
proof-core is a free, MIT-licensed evidence layer for computed outputs. It is standard-library-only and contains no AI. It wraps any result, including an AI agent’s answer, in a signed, tamper-evident record of what produced it, from what inputs, and whether it comes back when you re-run it.
proof-core is not AI. It is provenance for AI.
Not “trust us.” Check us.
Open and MIT, today. Keyless, with zero third-party dependencies. SMRFORGE runs on it; so can your software.
Illustrative. proof-core seals any computed output the same way. The seal proves custody, not that the answer is right. Origin shows here because a production key is pinned. Under the open demo key a bundle reads integrity-only.
What it does
Three verbs, no network, and no need to take the producer’s word. The checker imports no domain code, so a pass is never the producer grading its own work.
Wrap the result, its inputs, and how it was made into one signed file. A SHA-256 manifest of every part, an Ed25519 signature over the whole.
A standalone checker confirms the file is intact and signed under the pinned key. It needs only the file and the published public key. No network, no access to the producer’s system.
A signature can’t catch a signed mistake. Reproduce re-runs the computation on the recorded inputs and checks the result lands inside a tolerance band set up front.
Keyless by design. proof-core ships with no signing key of its own. Whoever uses it brings their own key, so the kernel never vouches for anyone. It does the math, you hold the trust root.
Build on it
Because proof-core is domain-neutral and keyless, an application doesn’t rebuild around it. It keeps its own code, calls proof-core to seal, verify and reproduce its results, and brings its own key and domain profile. Any software that produces a number or a decision can gain provenance without rebuilding itself.
Reactor physics, where being wrong is expensive. It runs on proof-core and shows the layer holds against numbers a skeptic re-runs.
Seals the verdict with the rule and the inputs pinned, so a reviewer can re-run the rule on the sealed inputs and confirm the verdict follows from them.
Seals a measurement screen with its thresholds, so the result travels with the evidence behind it.
Seals the output with the inputs and the run, so the agent hands over a record, not just a number.
Proof that travels
Normally the proof a result is real lives where it can’t move, in server logs, a dashboard, or someone’s word. proof-core puts the whole thing in one self-contained signed file, so the proof leaves the system that made it and still checks out months later, on a machine that was never near the original.
$ proof-verify result.bundle.json integrity every section hash recomputes ok origin signed under the pinned key ok $ proof-reproduce result.bundle.json --runner engine.module:Runner reproduce re-ran the engine on sealed inputs in band note checkable and re-derivable · not proof the answer is right
Agent-callable
MCP is the standard way an AI agent calls outside tools, and proof-core’s verbs map straight onto it. An agent produces provenance as a normal action, and can refuse to hand over a result that only passes integrity or fails to reproduce.
The agent runs a computation and gets back a sealed, signed bundle, so it can hand over the record, not just the number.
The agent verifies its own bundle and reads one of three honest verdicts, integrity and origin, integrity only, or fail.
The agent re-runs the number on the recorded inputs and confirms it lands in the committed band before it presents a result.
The open repo ships an MCP server template that puts seal, verify and reproduce behind one endpoint, and a proof-core edition ships the verify and reproduce tools over MCP today, so any MCP-capable assistant plugs in with no bespoke integration. A bundle one agent sealed, another can verify through the same tools. The bundle proves its recorded inputs are unaltered and re-runnable, not that the agent ran what it claims.
The honest boundary
A seal makes a result checkable by whoever holds the file. It does not make the answer right. proof-core proves provenance and re-derivability, not correctness. A faithfully sealed number from a bad input is a faithfully preserved wrong answer. That is why reproduce, and independent reproduction, sit above the seal.
Why open
A trust layer can’t be a black box. If we’re asking a skeptic to check a result, the checker has to be open to read and free to run. “Don’t trust us, check us” is an empty line otherwise.
So the kernel is free and MIT, and anyone can build on it without asking me.
Once provenance is common, the scarce thing is independent re-derivation, someone re-running the number and standing behind it. That is what I sell.
The physics and the plumbing are free and stay free. A seal doesn’t make a result right, it makes it checkable, and checking should cost nothing.
What’s free, what’s paid
You pay for independent reproduction and the assurance layer, never for the kernel or the physics.
open, MIT, forever
the scarce part
Physics is free and stays free. proof-core is free and stays free. You pay for independent reproduction and for the assurance a regulator reads, never for the kernel or the physics.
Open, and yours to build on
proof-core is public and MIT. SMRFORGE is the reactor-physics case that shows the evidence holds where being wrong is expensive. Questions, or want to seal your own output? Write to support@smrforge.io.
Both are standard-library only, with zero third-party dependencies, so they run fully offline, in a SCIF or behind a firewall.