What is Provable AI?
A category name for what enterprise AI has been missing: the ability to prove — cryptographically, deterministically, and at runtime — what an AI system actually did.
Can you prove what the AI did?
Until recently, the honest answer inside most enterprises was: not really. We could describe. We could log. We could sample, monitor, observe, and — if we were lucky — reconstruct. What we couldn’t do was prove.
Logs are testimony. They are the system telling you what it remembers. Reconstruction is archaeology. It assembles a probable story from fragmentary evidence. Testing asserts a claim about behavior under sampled conditions.
None of these are proof. Proof is a formal guarantee that a specific thing happened in a specific way — not a narrative about it, and not a statistical pattern around it. Provable AI starts by taking that word seriously.
Logs describe. Proofs attest.
Not computation consumed. Not state agreed upon. Attestable execution under contract.
In legacy systems, work is measured by computation consumed or state agreed upon. Cloud bills pay for CPU. Consensus protocols agree on a shared ledger. Neither asks whether a specific piece of work — a specific decision, a specific effect, by a specific agent, under a specific policy — actually happened the way it was supposed to.
For enterprise AI, that’s the question. Proof of Execution reframes it. Work becomes attestable execution under contract: a triple of the execution’s contract, its causal event stream, and its replay context, together carrying a proof that the execution stayed within its authorized boundary.
The loop that follows is Execution → Proof → Attestation → Scheduling. Governance stops being a downstream review and becomes a runtime primitive.
Work, in the PoE paradigm, is not computation consumed or state agreed upon. It is attestable execution under contract.
Five guarantees.
Provable AI is not a vibe. It is a short list of properties that can be formally stated, implemented, and verified. Rhodes & Kang (2026) prove that these five guarantees hold over any execution that satisfies a minimal set of runtime invariants, under stated trust assumptions.
Authorization
No effectful action is performed without a valid allow decision issued under the contract. The execution has an authoritative root.
Path compliance
Every effectful action stays within the scope authorized by some canonical Gateway evaluation. Side channels and parallel paths are structurally impossible.
Effect correctness on deny
Denied branches produce no persistent state change. A deny decision is not advisory — the downstream system is never touched.
History integrity
The recorded event stream is an unaltered record of what occurred. Tamper is cryptographically detectable.
Replayability
Replay under the same contract, event stream, and replay context on a compliant interpreter yields the same terminal result and persistent state delta.
Four novel contributions, not one.
The runtime-verification, reference-monitor, and tamper-evident-logging literatures each establish some of the primitives PoE uses. The paper’s contribution is what no prior system does: compose them into a single runtime-checkable object and quantify exactly what must be assumed for the composition to be sound.
Composition
Authorization, enforcement path, durable effect, tamper-evident history, and replay context — bound into one proof-carrying object x = (C, T, R). Prior systems capture one or two of these; PoE’s contribution is the join.
Separated assumptions
Cryptographic assumptions (A1–A4: signature unforgeability, collision resistance, Gateway integrity, Recorder integrity) are separated from deployment assumptions (A5–A7: trace completeness, dependency declaration, clock monotonicity). The latter enter Theorem 2 as named parameters ε_tc, ε_dep, ε_clock — bounded by operational controls, not by the security parameter. No hand-waving about what’s cryptographic vs operational.
Trace completeness as a derived property
Lemma 1 reduces A5 (the strongest deployment assumption) to a concrete architectural discipline — Effector-exclusive credentialing. Sole mutator, synchronous pre-commit seal, non-Effector credentials cannot mutate, uncompromised Recorder root. Four structural properties, not one free assumption.
Regulatory mapping
The formal guarantee structure maps directly onto current supervisory expectations for agentic AI (FINRA 2026 Rules 3110 / 3120, Rule 4511, SEC 17a-4). Not a post-hoc translation for marketing; a bidirectional link that lets a firm answer examiner questions from the trace.
Theorem 2: every violation reduces to something named.
Under the stated assumptions, the probability that a PoE-valid execution violates any of the five semantic guarantees is bounded by the sum of three cryptographic advantage terms (Gateway signature forgery, Recorder signature forgery, hash collision) and three named deployment-failure probabilities (ε_tc, ε_dep, ε_clock). The cryptographic terms are negligible in the security parameter. The deployment terms are not — they are the honest surface that separates a claim from a hand-wave.
The invariant set is minimal (Theorem 1): removing any invariant breaks the soundness bound. And replay equivalence holds under interpreter determinism and dependency-declaration completeness (Theorem 3). Preliminary single-node prototype measurements (§9 of the paper) show the mechanism runs at ~2.7 ms overhead per execution, amortizing to 4.4% on concurrent batches.
Six planes. Separated by design.
A runtime that produces proofs needs structural separation between who plans, who authorizes, who mutates, and who records. Without that separation, the planner silently becomes the executor and the trace self-attests — a classical capability-security failure.
The Prime Execution Model (PEM) organizes execution into six planes: Governance (policy authorship), Planning (untrusted proposal), Enforcement (the Gateway), Effect (the sole mutator), Record (the sealed event stream), and Observation (non-authoritative inspection).
One architectural rule binds them: all effectful execution must pass through exactly one authoritative Gateway evaluation. The paper calls this the Golden Rule. Path compliance and deny semantics derive from it.
One Gateway. One place policy is evaluated. No side door.
Envelope, certificate, score.
Each governed action emits a Determinism Envelope — the unit of proof. It binds identity, scope, authority, decision logic, input, result, and state delta into a single self-contained structure. Envelopes accumulate into an append-only, Merkle-sealed event stream (the ECES).
Contracts and revocations live in their own tamper-evident stores. The Contract Registry maps id(C) → C and is content-addressed; the Revocation Log records point-in-time freshness for each contract so a verifier can distinguish “valid when executed” from “valid now.” Recorder time is authoritative; wall-clock is advisory.
When well-formedness and all five invariants hold, the runtime issues an Execution Attestation Certificate (EAC) — a signed certificate bound to the contract hash, the stream root, the replay-context hash, and the issuing key id. An EAC has its own lifecycle: active, suspended, or revoked. Revocation does not rewrite history; it changes current acceptability only.
An Execution Compliance Score (ECS) accompanies the EAC in deployment. Auditors report one number per period; scheduling routes high-trust traffic toward high-fidelity executors. Proof-valid outcomes authorize the next step; the loop closes.
Provable AI is not a rebrand.
Not observability.
Observability describes execution for debugging, not for formal authorization or replay. Dapper and OpenTelemetry observe; PoE proves. You can have both; they are different things.
Not a TEE.
Trusted execution environments attest to code integrity inside an enclave. An attested enclave can still take an unauthorized sequence of actions. PoE attests to the authorization and shape of the trajectory itself.
Not consensus.
Consensus protocols agree on shared state; they do not attest to the off-chain trajectories that produced it. PoE governs the trajectory.
Not verifiable computation or zkVMs.
SNARKs and zkVMs (Jolt, RISC Zero, SP1) prove a function executed per VM semantics. They do not bind authorization, enforcement path, or replay context into the proof. PoE proves a different object: that a governed execution stayed within contract scope, traversed the authorized path, produced recorded effects, and is replayable. The two compose — a zkVM can prove internal functional correctness while PoE proves authorization, path, and effect boundaries.
Not blockchain for AI.
No tokens. No public chain. No minting. Cryptographic integrity, used where it belongs — inside an enterprise runtime.
Not upstream planner safety.
Prompt injection can compromise a planner. PoE is confinement: even a compromised planner cannot produce an attestable execution outside its contract. Upstream hardening is orthogonal and necessary.
Four honest limitations.
Proof of Execution is a sharp primitive with sharp edges. The paper states its limitations explicitly; we will not pretend otherwise.
Valid under contract is not the same as good contract.
PoE attests that execution stayed within the boundary the contract fixed. It says nothing about whether the contract was well-chosen. A contract that authorizes harmful actions yields PoE-valid harmful execution. Contract authoring, review, and revocation are upstream problems.
Authorized is not the same as safe.
A fully authorized action may still cause real-world harm — bad financial advice under a valid contract, correct retrieval of data that was nonetheless the wrong data to surface. PoE governs the trajectory; it does not adjudicate the wisdom of the authorized capabilities.
Replayable is not the same as reproducible in the world.
Replay equivalence holds under captured inputs and interpreter determinism. It does not guarantee that the external world at replay time resembles the world at execution time — data sources change, tools get decommissioned, model versions get deprecated.
Planner compromise is out of scope.
PoE confines the damage a compromised planner can do within an issued contract; it does not prevent planner compromise. Prompt-injection hardening, model-level interpretability, and contract-origination controls are orthogonal and necessary.
First implementation. Not the whole category.
AlphaBitCore is the AI Control Plane. Every execution our runtime governs produces an Execution Attestation Certificate under the Prime Execution Model — because the runtime is architected around the five invariants, not retrofitted to them.
Provable AI is bigger than any one company. It is a category the industry is going to need, and we believe it will be the default posture for any serious enterprise use of AI within a few years. Our job is to make that future usable now.
The AI Control Plane. Provable by design.
Provable AI.
Because every serious use of AI in the enterprise will eventually require a proof, and nothing else in the market produces one.