// ANOMLY INVAR PROOFABL · VERIFICATION APPLIANCE
INVAR Proofabl
Proof you can check.
A fanless, hardware-rooted network appliance running INVAR, the verifier that independently re-executes AI compute and issues signed verdicts. Proofabl is the box; INVAR is the software inside it.
It takes the receipt from an inference job, re-executes a cryptographically sampled slice on its own root of trust, and signs ACCEPT, REJECT or UNVERIFIABLE. It proves what someone else’s GPUs actually computed without trusting the machine that ran them.
The one thing it settles
Confidential-computing attestation proves the environment — a genuine, unmodified enclave. It does not prove the output.
INVAR closes that gap the only way it can be closed: run the computation again, independently, and compare the bits. Proofabl is the box it runs in.
How a verdict is made
Five steps, all of them checkable afterwards by someone who trusts neither the prover nor the appliance.
01 · RECEIPT
A receipt arrives
The prover runs its job under the INVAR exact-integer profile and emits a signed computation receipt: digests of the input, the weights and the claimed output, plus a certificate that recomputes from the manifest. The prover stays untrusted throughout.
02 · COMMIT
Commit before challenge
The receipt is published to a transparency log first, binding the prover to one specific full output before it can learn which part will be checked. INVAR then recomputes the certificate from the canonical manifest. A mismatch is REJECT immediately, with no arithmetic required.
03 · SAMPLE
An unpredictable sample is drawn
A public randomness beacon, seeded strictly after the commit, derives a stratified sample of the output. Every shard, every layer and the final-logits stratum get a floor of draws, so nothing is unsamplable and the prover cannot pre-compute only the audited slice. Air-gapped sites use commit-reveal: the prover commits first, then the relying party supplies the nonce, so the sample cannot be known before the commit.
04 · RE-EXECUTE
INVAR re-executes it independently
The appliance re-runs the sampled slice in exact integer arithmetic on its own silicon and its own code build, rooted in its own TPM-measured boot, and requires the result to be bit-identical to the committed output at those indices. Small or critical jobs are re-executed in full.
05 · VERDICT
A signed verdict is anchored
INVAR emits ACCEPT, REJECT or UNVERIFIABLE with the coverage, sample size, detection floor and achieved confidence, signed by a key held in the secure element that the host cannot read, and anchors it back to the transparency log. The verdict carries the appliance boot measurement, so a relying party can pin what checked it.
Sampling strength is stated, not implied. For a job of n units with a fraction f corrupted, a sample of k units catches at least one corruption with probability 1 − (1 − f)k. A one-percent detection floor at ninety-five percent confidence needs roughly three hundred units; the verdict records k, n, the floor and the achieved confidence, so a reader sees the strength rather than just the word ACCEPT.
What it proves, and what it does not
The boundary belongs on the front of the box, not in a footnote.
WHAT IT PROVES
- The covered output is bit-faithful to an independent exact re-execution rooted in this appliance’s own hardware.
- The receipt is internally consistent: the certificate recomputes from the canonical manifest, and the input and weight digests match what was handed over.
- The audited slice was chosen after the prover committed, by a beacon it could not predict, and any auditor can recompute which slice that was.
- The verdict came from this appliance, under this measured boot, signed by a key the host cannot read or forge.
WHAT IT DOES NOT PROVE
- It does not bit-verify arbitrary vanilla-float GPU output. That is non-reproducible by construction, so it returns UNVERIFIABLE — never ACCEPT. The receipt’s profile field decides this up front, before any sample is drawn or compute is spent. The offer is “run the verifiable profile on your GPUs and this box proves the result,” not “we verify any GPU.”
- It does not judge model quality, safety or bias. A verdict says the output is faithful to its receipt, not that the answer is good.
- It does not verify regions outside the receipt’s coverage. Coverage bounds the verdict, and the verdict states its own scope.
- It is only as independent as whoever operates it. The value is highest when the verifier is run by a different party than the compute.
ACCEPT
The receipt is internally consistent and the sampled slice reproduced bit-identically, at the stated coverage and confidence.
REJECT
An integrity mismatch, or some sampled unit failed to reproduce. Fails closed.
UNVERIFIABLE
The job did not run under the verifiable profile, coverage was insufficient, or the sample could not be made unpredictable. Never silently upgraded.
Why a separate box
The honest answer runs both ways.
To catch your own errors, you don’t need one
Bit-flips, silent kernel drift, a regression between releases: run the INVAR verifier software on any spare machine, or the same one. That is legitimate, and it is basically free. We would rather say so than sell you hardware you don’t need.
To prove your honesty to someone else, you do
Verification on the machine that did the compute is marking your own homework: whoever controls the host can patch the verifier to always accept, or lift the signing key out of memory. A separate box gives an independent hardware-sealed key, separation of duties, measured-boot tamper evidence, and a genuinely different substrate reaching the same bits.
What’s inside
Concept configuration. Figures and specifications are preliminary and subject to change.
| Block | Specification |
|---|---|
| Compute | Raspberry Pi Compute Module 5 (CM5) — quad-core Arm Cortex-A76 with hardware crypto extensions. Sized for sampled re-execution and line-rate signing, not bulk inference. |
| Root of trust | TPM 2.0 measured boot, attesting the verifier’s own firmware. The boot measurement travels inside every verdict. |
| Verdict-signing key | Secure element holds the ECDSA P-256 signing key. It is generated in the element and never leaves it; the host reads only the public key and the signatures. |
| Arithmetic | INVAR exact-integer profile (b-posit with a wide quire accumulator) — the bit-identity property being audited. |
| Thermal | Fanless passive heatsink in a convection-vented clear enclosure. Silent, no moving parts; verification is a light, bursty load. |
| Network | 1GbE on the desktop unit; dual 1GbE on the 1U rack unit. |
| Power | USB-C 5V on the desktop unit. |
| Local I/O | 2× USB-A, microSD boot. |
| Status | PWR, ACT and CERT indicators. CERT goes green only on a verified ACCEPT. |
| Trust log | Transparency-log client (SCITT). COSE-signed statements, checkable by a third party. |
| Interfaces | Receipt in, verdict out over REST and a CLI. Synchronous for small jobs, asynchronous with webhooks for large ones. |
Form factors
- Desktop, fanless and quiet, beside a workstation or server.
- 1U rack, redundant network interface, convection-cooled, for the row it audits.
- A rack of verifiers: a verification tier beside the GPU fleet, on one shared transparency log.
Anyone can check a verdict
A verdict nobody else can check is not proof. The auditor side needs no appliance.
Given a verdict, the receipt and the public beacon value, the off-box auditor re-derives the sampled indices, checks the schema, the protocol invariants and the coverage bound, and verifies the verdict’s ECDSA P-256 signature. A third party confirms the result without trusting the appliance either.
Trust rests on the signature and the transparency-log entry, not on an HTTP status. A client is expected to pin the appliance identity — its id, boot measurement and public key — and check the signature rather than read a 200.
Auditor exit codes
INVALID means the verdict itself is forged or tampered — a bad signature, or sampled indices that do not re-derive from the beacon and receipt. DIGEST MISMATCH means the dump on the box does not match the receipt it claims to belong to. Exit code 1 is reserved for tool errors, the shell convention, and is never a verdict.
Provenance you can retrace
Proofabl runs the INVAR exact-integer stack. The same model and input produce a bit-identical whole-graph hash on x86, an NVIDIA RTX 5090 and an Arm Cortex-A53 board. A Tenstorrent Blackhole card and a Xilinx U200 FPGA then independently re-executed challenged rows of that same computation and accepted every one.
That cross-hardware bit-identity is the property INVAR audits. Proofabl puts that verifier in a tamper-evident box with its own root of trust, so the verdict about someone else’s compute comes from hardware nobody else touched.
Design-partner pilot
Before general availability, Proofabl is offered through a design-partner program. Per our own rule, a partner watches the appliance ACCEPT a known-good job and REJECT a tampered one on real hardware before anything ships. We do not sell hardware we have not validated end to end.
The fit is an operator, cloud, regulated or confidential-AI team, or an auditor who needs a credential a skeptic will accept — not a box to check their own arithmetic.
Talk to us about a pilotConcept datasheet from Anomly, Inc. Figures and specifications are preliminary and subject to change.