On Building Things That Cannot Lie

I did not start building systems because I wanted a career. I started because I found something deeply satisfying in the act of making a thing that works — not works-for-now, not works-on-my-machine, but provably, verifiably, repeatably works.

Most human endeavors are interpretive. A speech can be spun. A relationship can be reframed. A business outcome can be attributed to a dozen causes. But software, at the lowest level, does not interpret. A zero-knowledge proof either proves what it claims to prove, or it does not. A consensus protocol either maintains safety and liveness under the specified fault model, or it does not.

There is a kind of honesty in that which I find rare in the world.

I am drawn to infrastructure rather than applications for a reason I have thought about for a long time.

Applications are visible. They get the credit when things go right and the blame when they go wrong. Infrastructure is invisible. When it works, nobody notices. When it fails, everything downstream fails simultaneously and nobody is sure why.

This is why infrastructure is the honest work. You cannot fake it. You cannot hide it behind a beautiful UI. Either the consensus is maintained across Byzantine faults or it is not. Either the ZK proof is sound or it is not. Either the eBPF monitor catches every TCP connection or it misses some and you are blind.

I think the reason most engineers avoid infrastructure is precisely this exposure. There is nowhere to hide. Every claim is checkable. Every guarantee is either provable or it is not a guarantee — it is a hope.

I find that clarifying rather than frightening. The world has enough beautiful interfaces over unreliable foundations.

The phrase "don't trust, verify" was invented in the context of cryptography and distributed systems. It describes a system design principle: do not rely on the good intentions of participants. Instead, design protocols where correct behavior can be verified independently of intent.

This is also, I believe, the correct philosophy for building AI systems.

The dominant approach to AI trust today is behavioral: we observe what the model does, we monitor its outputs, we hope it continues to behave well. This is trust as a bet on continued good behavior. It is fragile because the conditions that produced good behavior are not constant. Models change, distributions shift, adversaries probe edges.

The correct approach is structural: design agent systems where every action produces a cryptographic proof of what was computed, on what input, producing what output. Proof-first, not observation-first.

This is not a technical preference. It is a philosophical one. I believe that systems designed for auditability — where every action leaves behind an irrefutable record — produce better behavior over time than systems designed for opacity. Not because the technology forces better behavior, but because auditability changes the relationship between the system and the humans who operate it. You cannot ignore a ZK receipt. You cannot attribute the anomaly to noise. The receipt is there. The math is there. Either it matches what you expected or it does not.

Accountability, in any system — human or automated — requires that actions leave permanent, verifiable traces.

There is a view, common among careful engineers, that speed is the enemy of correctness. Ship slower, think longer, test more thoroughly.

I disagree with this, and I disagree with it philosophically, not just technically.

Moving slowly is not a virtue when the thing you are building is the substrate on which other people's systems will run. If I spend three months building an agent coordination protocol that could have been done in three weeks, I have not made it more correct. I have delayed its existence by six weeks while other people built on less reliable foundations.

Speed, in infrastructure, is a form of care. It means getting the correct thing into existence faster so it can do the work it was designed to do. The correct measure is not "how carefully did you move?" but "how quickly did you produce something that actually works?"

This requires a specific kind of clarity: know what you are building before you start. Understand the failure modes. Write the invariants before the code. Then move fast within those constraints.

Fast is not reckless. Reckless is not knowing what you are trying to prove.

I am trying to build a world where AI systems are not trusted because they are familiar, or because they come from a reputable vendor, or because they have not failed yet.

I want AI systems that are trusted because every action they take is accompanied by a mathematical proof of correctness. Where "trust me" is replaced by "here is the receipt." Where sovereignty — the ability to own, audit, and replace any component of the system — is a property of the architecture, not a negotiation with the platform.

This is not a distant goal. It is the system I am building right now, in Rust, with ZK proofs and post-quantum cryptography and eBPF kernel monitors.

The philosophical position and the engineering implementation are the same thing. I build verifiable systems because I believe verifiability is what honesty looks like in software.

Every proof is a form of truth-telling. I intend to keep telling it.