Verification

Not verified after the fact. Constructed so the proofs come first.

Honeycomb’s differentiated asset is a construction method: the architecture contract, the executable semantics, the refinement proofs, and the RTL generator are one Lean codebase, checked together by a single lake build. Verifiability is not a feature bolted onto finished silicon — it is how the machine is built.

One artifact

A conventional flow keeps the specification, the simulator, the RTL, and the physical design as separate artifacts, reconciled by test suites and review. Honeycomb collapses them: the ISA is a Lean function, each cell implementation is a Lean model proved to refine that function, the SystemVerilog is rendered from Lean definitions, and the golden simulation programs are Lean values whose expected results are themselves checked in Lean. When a definition changes, everything downstream either re-proves and re-emits, or the build fails. CI rebuilds the proofs, re-emits the RTL, rejects drift against the checked-in files, and runs the golden simulations on every push.

There are no sorrys and no axioms in the book: every theorem is closed, and the load-bearing ones quantify over all instructions and states, not test vectors.

What is proved

The proof stack, from the inside out:

The evidence taxonomy

Every public claim carries one of four tags, and the status board tracks all of them:

Numbers on this site are not hand-maintained prose. The Lean build emits them to a data file the site reads, and CI fails if the site’s numbers drift from the book’s. Physical-design figures are recorded from tool reports; the taxonomy exists precisely so a routed-estimate number can never masquerade as measured silicon.

The boundary, stated plainly

A verification story is only as good as its stated edges. These are Honeycomb’s, kept current as they move:

Each edge is either a permanent, declared non-goal (parser-level text equivalence) or has a tracked path in the roadmap. The discipline is the point: the boundary moves outward by proof, never by prose.

Why this matters

For most buyers, hardware assurance today means auditing a vendor’s process. Honeycomb offers something structurally different: the isolation mechanism, the boot chain, and the delivery path are theorems you can read, about definitions the RTL is generated from, in a repository you can rebuild. Determinism compounds the value — exact integer arithmetic and proved delivery timing make results reproducible bit-for-bit across runs and hardware revisions, which is a property no driver-stack can promise.

The book contains every definition and theorem referenced here, with the evidence tables generated from the same build.