PROOF INTELLIGENCE FOR CRITICAL INFRASTRUCTURE
Prove what holds.Block what breaks.
Independent proof for critical software, critical actions, and modernization.
DRONES · PX4 SIMULATION
Three commands tried to fly into a no-fly zone. Our gate refused all three.
What we can do for your drones
- 01
Stop the command before the autopilot
Every command that would move the drone is checked against your no-fly zones before the autopilot sees it, then refused or let through.
- 02
Map every data output
From the firmware image alone: every channel the drone sends data on, and what goes out on it. A new output between two versions is flagged.
- 03
Prove a fix closes the flaw
A patch to the flight code is checked against the flaw it claims to close, not only against its tests.
- 04
Seal every decision
Accepted, refused or overridden by a person: each one is recorded, and a third party can check the record offline.
WHERE THE PROOF WORKS TODAY
Four jobs. Each one ships with its proof.
We write the code, or we check code someone else wrote. Either way, you get the proof, not a promise.
- 01Legacy modernizationMove COBOL to Java or Python. We translate it, or check the translation you already have, and show exactly where the new code behaves differently.A third-party COBOL → Java translation: 15 findings, 11 replayed in execution, including a credit-limit check that disappeared.SEE HOW WE CHECK IT START A PILOT
- 02Python to embedded CPort Python or MATLAB to the language of its chip, with proof it returns the same result.A Python signal-processing step translated to embedded C: the same result on all 140 trillion inputs. One short function, from our own tests.SEE THE PROOF START A PILOT
- 03Security fixesProve a patch really closes the flaw, before you ship it.Blind test: 20 drawn from 268 recent vulnerabilities, 13 proven closed within declared limits. Fixes credited by wolfSSL, IBM and Red Hat.SEE THE RESULTS START A PILOT
- 04Critical actionsDecide every critical action before it runs: allowed if it complies, blocked if it does not.Power grid, NERC CIP-010: 44 of 44 cases at the expected verdict, 22 of 22 sabotages refused.WATCH IT DECIDE START A PILOT
CODE VERIFICATION
Your code was rewritten. Does it still do the same thing?
A bank moves its COBOL to Java, with an integrator or an AI tool. The new code compiles and passes its tests. Yet in a real translation made by a third party, a transaction over the credit limit went through: a security control was gone. Ironproof shows you, module by module, where the new code no longer does what the old code did.
ALREADY RUN
On public AI-generated COBOL-to-Java translations, we found differences in behavior, confirmed on IBM’s COBOL compiler, and documentation that does not match the code it describes.
- 01
Different behavior.
The exact input where the two differ, replayed on your own compiler. You run it yourself and see the difference with your own eyes.
- 02
Not decided.
Where we could not conclude, we say so, with the reason. Never shown as a pass.
- 03
Same behavior.
We are rebuilding this answer. Until it holds up, we don’t issue it.
CLARIFICATION, OCTOBER 31, 2026
Audits of our own checker have reproduced dozens of false “same behavior” answers, on cases written to attack it. So we are rebuilding that answer, and we don’t issue it in the meantime. The figures we published before describe our model: read them as history, not as confirmed behavior.
READ THE CLARIFICATIONTwo roles. Our engine translates your code and compares its translation with the original. And it verifies translations made by others, for the side that carries the risk if it breaks.
You modernize, we check. Hand your client a report from someone who didn’t write the code. Every result reaches your client, including the ones you won’t like.
It starts with a traceability audit: we check what the translation says about itself, its cited sources, its data mapping, its compliance sheets. The proof of behavior comes next, in its own report. SEE THE AUDIT
SEE HOW WE CHECK ITWHY IRONPROOF
Ship it with its proof. Face the audit with a record. Catch what breaks.
- 01
Ship code that carries its proof
Every module we write or check arrives with what proves it: what differs, the exact input behind each difference, and what could not be decided. Your risk committee signs on evidence, not hope.
- 02
Give your auditor a record to re-check
Give your auditor and your regulator a sealed record of every answer and every decision that they can re-check themselves, instead of logs and screenshots.
- 03
Catch what tests miss
Get the exact input where the new code behaves differently, or the sequence of actions that breaks your rule, before production does.
HOW OUR PLATFORM WORKS
From your code to code that carries its proof.
- 01
Scope
Bring one case: a translated program, the policy behind an action, a security fix. Before anything runs, we write down exactly what will be checked.
- 02
Model
We turn it into precise logic a solver can read. Whatever we cannot model is listed as not covered, never skipped.
- 03
Compare and cross-check
A solver checks every case the model allows. A second, independent check confronts it: IBM’s compiler for COBOL, a second solver for policies, decoy fixes for C.
- 04
Seal and hand over
The proof, or the exact case that differs or breaks the rule, sealed with a classical and a post-quantum signature. Built so your auditor can re-run it without us.
Any code. Any command. Decided before it runs.
COBOL, Java, C, Python, access policies, AI agents before execution. One of three answers, and every answer is sealed.
WHAT COMES IN
- COBOL
- Java
- C
- Python
- Access policies
- AI agents
- Holdsproven within the stated model
- Breaksthe exact case that shows it
- Not decidedsaid as such, never a pass
Others sell trust.
We sell the right not to trust us.
