We Made Every Computation Provable. Here's How.

What if every computation your system performed could be independently verified? Not "logged." Not "monitored." Verified. Mathematically. By anyone. Without trusting you. We built that.

This is a post for builders. For the founders staring at compliance checklists wondering how to prove what their system actually computed. For the engineers who know that a database row labeled "result" carries exactly zero evidence of how it got there. For anyone who has ever been asked "can you prove that output is correct" and had to answer with architecture diagrams instead of cryptographic evidence.

We are going to walk through what provable computation means in practice, how we engineered it into every cache operation, what it costs, and what it unlocks. No hand-waving. No theoretical future work. This is shipping code with 31 passing tests.

The Problem We Solved

Computation results are ephemeral. Your system computes something -- a fraud score, an inference result, a pricing calculation, a risk assessment -- and returns the result. The moment that result leaves the function boundary, the proof of how you got there disappears. The inputs are gone. The parameters are gone. The model version that produced it is gone. The hardware that ran the computation is gone. All that remains is a value in memory with no provenance.

This is not an abstract concern. Consider what happens when a regulator asks: "Show me the computation that produced this fraud decision." You can show them the code. You can show them the logs. You can show them the database row that stores the result. But you cannot prove that this specific code, with these specific inputs, on this specific version, produced this specific output. You are asking them to trust your infrastructure. You are asking them to trust that your logs were not modified, that your code did not change between the computation and the audit, that your parameters were what you say they were.

Trust is not evidence. Evidence is evidence. And for computation results, there has been no evidence. Until now.

What "Provable" Actually Means

We need to be precise about this word because the industry has made it meaningless. "Provable" has been co-opted by blockchain projects that conflate distributed consensus with mathematical proof, and by zero-knowledge proof systems that solve an entirely different problem. Here is what provable computation means in the context of Cachee, and what it does not mean.

It is NOT zero-knowledge proofs. Zero-knowledge proofs let you prove you know something without revealing what you know. That is useful when you need to hide inputs. We do not hide inputs. We bind them. Every computation fingerprint includes the full input hash. If you have the inputs, you can recompute the fingerprint and verify it matches. We are not trying to prove knowledge without disclosure. We are trying to prove that a specific result came from specific inputs via a specific computation. Those are fundamentally different goals, and conflating them leads to architectures that are 1,000x more expensive than necessary.

It is NOT blockchain consensus. Blockchain consensus proves that a network of participants agreed on a state transition. We do not need distributed agreement. We need a single authority -- the computation host -- to produce a binding that anyone can independently verify. Consensus is for resolving disagreements between untrusted parties. Provability is for producing evidence that a specific thing happened. Blockchains solve the former. We solve the latter. The cost difference is enormous: a blockchain transaction costs gas and latency measured in seconds. A computation fingerprint costs less than a microsecond.

What it IS: every result carries a cryptographic binding to its exact inputs, computation identity, and execution context. Change any input and the binding breaks. Change the computation version and the binding breaks. Change the parameters and the binding breaks. The binding is a computation fingerprint:

SHA3-256(input_hash || computation_hash || parameter_hash || version || hardware_class)

This fingerprint is deterministic. Same inputs, same computation, same parameters, same version, same hardware class -- same fingerprint. Always. If any component differs, the fingerprint differs. You cannot substitute inputs after the fact. You cannot claim a different version produced the result. The fingerprint is the evidence, and the evidence is bound to exactly what happened.

This approach is cheaper than ZK proofs, simpler than blockchain, and sufficient for 99% of compliance use cases. The remaining 1% -- cases where you genuinely need to prove knowledge without disclosure -- should use ZK. But most organizations reaching for ZK actually need provability, not zero-knowledge. They want to prove what happened, not hide what happened. We built for that.

The Four Properties of a Provable Result

A result is provable when it satisfies four properties simultaneously. Miss any one and you have a gap that an attacker or auditor can exploit. These four properties are not theoretical desiderata. They are enforced by construction in every Cachee entry.

Property 1: Authenticity

The result was produced by a known, authorized computation host. Not forged. Not injected. Not replayed from a different context.

Every cached result is signed by three independent post-quantum signature families: ML-DSA-65 (FIPS 204, lattice-based), FALCON-512 (NTRU lattice-based), and SLH-DSA-SHA2-128f-simple (FIPS 205, stateless hash-based). An attacker who wants to forge a cached result must break MLWE lattices, NTRU lattices, AND stateless hash functions simultaneously. These are three independent mathematical hardness assumptions. Breaking one does not help with the other two. The probability of all three falling in the same time window is the product of three independent probabilities, each of which NIST considers negligible through at least 2060.

Any single signature failure invalidates the entire entry. This is not "best two out of three." It is unanimous agreement from three independent mathematical foundations that this result is authentic.

Property 2: Identity

The result is bound to the exact computation that produced it. Not just "a fraud score" but "this fraud score from this model version with these feature inputs and these parameters on this hardware class."

The computation fingerprint is the identity. SHA3-256(input_hash || computation_hash || parameter_hash || version || hardware_class) binds the result to every dimension that matters. Same inputs, same parameters, same version, same hardware class = same fingerprint. Different anything = different fingerprint. There is no ambiguity. There is no "close enough." The fingerprint is either an exact match or it is not.

This means two cache entries that were produced by different model versions will have different fingerprints even if the result happens to be the same value. The identity is not the value. The identity is the provenance of the value. Two systems can produce the same fraud score of 0.73, but if they used different model versions, the fingerprints differ, and you can prove which system produced which result.

Property 3: Integrity

The result has not been modified since it was computed. Not by an attacker, not by a bug, not by bit rot, not by a misconfigured migration script.

Cachee uses content-addressed storage. The storage address of every entry is derived from the content itself: SHA3-256(value_hash || fingerprint). If you modify the value, the address does not match. If you modify the fingerprint, the address does not match. If you modify anything, the address does not match. There is no way to substitute a different value for the same address because the address IS the content.

This is backed by sled -- a modern embedded database written in Rust with crash-safe semantics. The content-addressed entries are persisted to disk, and every read verifies that the content matches its address. An attacker who gains disk access and modifies a cached value will find that every subsequent read detects the tampering because the content no longer matches its address.

Property 4: Temporality

The result is bound to a specific point in time. You cannot backdate a result. You cannot claim a computation happened yesterday when it happened today.

Every result is appended to a hash-linked audit chain. Each entry in the chain includes the computation fingerprint, a timestamp, and the hash of the previous entry. This creates an ordering that is tamper-evident by construction. If you insert an entry between two existing entries, the hash chain breaks. If you modify any historical entry, every subsequent hash is invalid. If you try to backdate a result, the hash ordering proves the lie.

The audit chain is not a log file. Log files can be truncated, overwritten, or deleted. The audit chain is a cryptographic data structure where the integrity of every entry depends on the integrity of every previous entry. Tampering with history requires recomputing the entire chain from the tamper point forward, and every downstream entry carries signatures that would also need to be forged -- which requires breaking three independent PQ signature families simultaneously.

How We Built It

The engineering story matters because provability is not a feature you bolt on. It is a property that emerges from how every layer interacts. Get any layer wrong and the provability guarantee collapses. Here is how we built each layer, in the order we built them, and why the order matters.

Step 1: Real PQ Signatures

We started with the signing layer because everything else depends on it. If signatures can be forged, nothing else matters. We use the actual NIST PQ libraries: pqcrypto-dilithium, pqcrypto-falcon, and pqcrypto-sphincsplus. Not wrappers around wrappers. Not "PQ-inspired" algorithms. Real keygen, real sign, real verify -- the same code that NIST validated. Every cache write produces three independent signatures. Every verified read checks all three. A single failure rejects the entry.

We chose three families deliberately. ML-DSA-65 is the workhorse -- fast signing, fast verification, reasonable key sizes. FALCON-512 provides diversity from a different lattice assumption (NTRU vs. MLWE). SLH-DSA provides the safety net -- it is hash-based, meaning its security relies only on the properties of SHA-256, which is the most conservative assumption in cryptography. If lattices fall tomorrow, the hash-based signature still holds.

Step 2: Deterministic Fingerprints

Once we had signing, we needed identity. The computation fingerprint is deterministic: given the same inputs, computation, parameters, version, and hardware class, you always get the same fingerprint. This is critical because it means fingerprints are independently verifiable. You do not need access to the cache to verify a fingerprint. You need the inputs, the computation identity, and SHA3-256. Anyone can recompute the fingerprint and check that it matches.

Determinism also means cache hits are semantically meaningful. A cache hit does not just mean "we have a value for this key." It means "we have a value that was produced by this exact computation with these exact inputs." If the model version changes, the fingerprint changes, and the old cached result is a miss. You never serve stale results from a superseded model because the fingerprint enforces identity.

Step 3: Content-Addressed Storage

With fingerprints in place, we built the storage layer. Every entry is stored at an address derived from its content: SHA3-256(value_hash || fingerprint). This means the storage layer itself is a verification mechanism. You cannot move a value to a different address. You cannot put a different value at an existing address. The address and the content are cryptographically bound.

We use sled as the backing store. Sled is an embedded database written in Rust with lock-free concurrent reads, crash-safe writes, and zero-copy reads for values that fit in a page. The combination of content-addressed keys and sled's crash safety means that the integrity guarantee survives process crashes, power failures, and ungraceful shutdowns. If sled can read the entry, the entry is valid.

Step 4: The Audit Chain

The audit chain links every event into a tamper-evident sequence. Each event record contains the computation fingerprint, the operation type (write, read, verify, state transition), a timestamp, and the SHA3-256 hash of the previous event. This creates a hash-linked chain where modifying any historical record invalidates every subsequent record.

The audit chain is not optional. Every cache operation appends to the chain. Writes, reads, verifications, state transitions -- everything is recorded. The chain is the ground truth for "what happened and when." An auditor can walk the chain from genesis and verify every link. If any link fails verification, every subsequent event is suspect. This is the property that makes provability temporal: you cannot insert events into the past because the hash chain enforces ordering.

Step 5: Verification on Read

This is where most systems fail. They sign data at write time and never verify it again. The signatures become decoration -- they exist, but nobody checks them. In Cachee, GETVERIFIED actually calls bundle.verify(). Not a metadata lookup. Not a flag check. Real PQ signature verification across all three families. If any signature fails, the entry is rejected and the failure is recorded in the audit chain.

This means every verified read is an integrity check. You do not need a separate "integrity verification job" that runs nightly. Every read is verification. The cost is approximately 3ms for full three-family verification, which is roughly the same as a Redis round-trip over localhost. For reads that do not need verification, the in-process path remains 31 nanoseconds. You choose the verification level per read based on the sensitivity of the use case.

Step 6: Lifecycle State Machine

Cached results are not permanent. They have lifecycles. A result might be superseded by a newer computation. It might be revoked because the inputs were discovered to be invalid. It might expire because the freshness contract elapsed. It might be deprecated because the computation version was retired. Each of these transitions has compliance implications, and each must be recorded.

Cachee implements a five-state lifecycle: Active, Superseded, Revoked, Expired, and Deprecated. Every transition requires a TransitionAuthority (which key authorized the change) and produces a TransitionProof (cryptographic evidence that the transition was valid). Terminal states are terminal. You cannot resurrect a revoked entry. You cannot un-expire an expired result. The state machine enforces finality, and every transition is recorded in the audit chain.

This matters because compliance frameworks demand lifecycle management for data. SOC 2 wants change management evidence. HIPAA wants access and modification records. FedRAMP wants authorization for every state change. The lifecycle state machine produces all of this evidence natively. No external workflow tools. No ticketing system integration. The evidence is produced by the cache operation itself.

Step 7: Merkle Anchoring

The audit chain provides local tamper-evidence, but a determined attacker with persistent access could theoretically recompute the entire chain. Merkle anchoring provides the external checkpoint. Periodically, the system computes a Merkle root over the current audit chain and anchors it. Anyone with the Merkle root can verify that the audit chain has not been modified since the anchor point. An attacker who recomputes the chain will produce a different Merkle root, and the divergence is detectable.

The anchoring interval is configurable. For high-compliance environments, anchor every minute. For standard deployments, anchor hourly. The anchor itself is a single hash value -- 32 bytes -- that represents the integrity of the entire audit chain up to that point.

What Provable Computation Unlocks

Provability is a foundation, not a feature. Once every computation result carries cryptographic evidence of its provenance, entire categories of problems become tractable.

Compliance

SOC 2, HIPAA, FedRAMP, CMMC -- every compliance framework requires proving what happened. Not describing what should have happened. Not showing a policy document. Proving what actually happened with evidence that an auditor can independently verify. The computation fingerprint plus triple PQ signatures plus audit chain provides exactly this. An auditor can take a cached result, verify the signatures offline using standard PQ libraries, recompute the fingerprint from the declared inputs, and confirm that the chain ordering is valid. No trust required. The evidence speaks for itself.

AI and Machine Learning

Cached inference results that carry provenance. When a model produces an inference, the fingerprint binds the result to the exact model version, the exact prompt or input features, the exact parameters, and the hardware that ran the inference. Six months later, when a regulator or customer asks "what model produced this decision," you do not need to search logs. The fingerprint is the answer. It is bound to the result. It cannot be separated from the result. It IS the result's identity.

This is especially critical for AI governance frameworks emerging in the EU, the UK, and proposed in the US. Model cards and documentation are a start, but they are not evidence. A computation fingerprint is evidence. It binds a specific output to a specific model version with the same rigor that a notarized document binds a signature to a signer.

Finance

Trade decisions backed by cryptographic proof of the computation that produced them. When a trading algorithm produces a recommendation, the fingerprint proves which model, which market data inputs, which risk parameters, and which software version produced the recommendation. In a regulatory inquiry, this is the difference between "our system said to buy" and "here is the cryptographic proof that model v3.7.2 with these specific market inputs and risk thresholds of 0.05 produced a buy recommendation at exactly this timestamp, independently verifiable by any party with SHA3-256."

FINRA, the SEC, MiFID II, and similar frameworks are moving toward computational auditability. Provable results satisfy these requirements natively. The compliance team does not need to build a separate evidence pipeline. The evidence is the cache entry.

Healthcare

Patient data access with verifiable audit trails. HIPAA requires a complete accounting of disclosures -- who accessed what patient data, when, and why. Provable computation extends this to computational results. When a clinical decision support system produces a recommendation based on patient data, the fingerprint proves exactly what data was accessed, what computation was performed, and what result was produced. The audit chain proves when it happened and that no historical records were modified.

For healthcare organizations, this transforms the audit trail from "we logged it" to "we proved it." The difference is significant: a log entry is a claim. A computation fingerprint backed by three PQ signatures is evidence.

The Cost of Provability

Every engineering decision has a cost. Provability is no exception. But the cost is lower than most engineers expect because we are not doing ZK proofs (which cost milliseconds to seconds per proof) or blockchain transactions (which cost gas and block confirmation time). We are doing hash computations and PQ signatures. Here are the actual numbers.

Provability costs 2ms on writes and zero on reads. That is the price of evidence.

To put this in context: a single Redis round-trip over localhost is approximately 300 microseconds. A Redis round-trip over a VPC is 500-800 microseconds. A PostgreSQL query on an indexed table is 1-5 milliseconds. The write-path overhead of provability -- 2 milliseconds -- is within the noise of a single database query. And on reads, if you do not need verification, the cost is literally zero additional overhead. The 31-nanosecond in-process read does not touch the signatures. It returns the cached value from memory. Verification is opt-in per read.

For the reads that do need verification -- and compliance-sensitive reads should verify -- the 3ms cost is competitive with a Redis round-trip. You are trading one Redis hop for full three-family post-quantum signature verification. That is not a cost. That is a bargain.

The Architecture in Code

The following configuration shows how provable computation is enabled in a Cachee deployment. Every setting maps to one of the layers described above.

# cachee.toml — provable computation configuration

[provability]
enabled = true
fingerprint_hash = "SHA3-256"
fingerprint_fields = ["input", "computation", "parameters", "version", "hardware_class"]

[signatures]
algorithms = ["ML-DSA-65", "FALCON-512", "SLH-DSA-SHA2-128f"]
verify_on_read = "opt-in"       # GETVERIFIED checks all 3; GET skips
sign_on_write = "always"        # every write produces 3 signatures
reject_on_any_failure = true    # single sig failure = reject

[storage]
engine = "sled"
content_addressed = true        # address = SHA3-256(value_hash || fingerprint)
crash_safe = true

[audit_chain]
enabled = true
hash_algorithm = "SHA3-256"
link_previous = true            # every entry hashes the previous entry
record_reads = true             # reads are audit events too
record_state_transitions = true

[lifecycle]
states = ["Active", "Superseded", "Revoked", "Expired", "Deprecated"]
require_transition_authority = true
require_transition_proof = true
terminal_states = ["Revoked", "Expired"]

[merkle_anchor]
enabled = true
interval_seconds = 3600         # anchor every hour (configurable)
anchor_hash = "SHA3-256"

The [provability] section enables fingerprinting. The [signatures] section configures the three PQ families and the verification behavior. The [storage] section enables content-addressed persistence. The [audit_chain] section creates the hash-linked event sequence. The [lifecycle] section enforces the state machine. The [merkle_anchor] section schedules periodic integrity snapshots.

This is not a configuration for a proof-of-concept. This is production configuration. Every setting corresponds to shipping code with tests.

What's Next

The provability foundation is built. What comes next is enforcement -- taking the evidence that the system produces and making it actionable at every layer.

Command-level signature enforcement. Today, GETVERIFIED verifies signatures on read. The next step is enforcing signatures at the command level: every command that touches a provable entry must present a valid key, and the command itself is signed and recorded. This closes the gap between "we recorded what happened" and "every operation was authorized."

Per-key access control. Owner, Regulator, and Auditor keys with different capabilities. Owners can read and write. Regulators can query metadata and verify signatures without reading values. Auditors can verify that computations were cached and attested without accessing the cached data itself. The key hierarchy maps directly to compliance separation-of-duties requirements.

H33-74 anchoring. The Merkle anchor currently produces a 32-byte root hash. H33-74 compresses this into a 74-byte attestation bundle that includes the Merkle root plus post-quantum attestation metadata. 74 bytes. Any computation. Post-quantum attested. Forever. This is the bridge between local provability and global verifiability.

The foundation is built. The evidence is real. The enforcement layer is coming.