Source-linked AI summary
AI with Authority, from Application to Silicon
Jason Hickey
TL;DR
Machine verification has long been too costly for most software and hardware work, while generative AI makes producing candidate proofs and designs cheap without making them trustworthy. This paper presents the Salt method and reports a five-week, one-person demonstration from application code to RISC-V tapeout with kernel-checked verification throughout.
Problem
Machine verification has remained costly and impractical beyond exceptional artifacts, and generative AI has reduced proof production costs without resolving how to trust its outputs.
Method
The Salt method uses kernel-checked artifacts and named checkers for claims, reserving human review for statements, designs, and rulings rather than proofs.
Results
A single person used consumer products to develop a verified system stack from application to silicon tapeout in five weeks, with verification specified at each layer.
Takeaways & Limitations
In this measured regime, machine verification functions as a precondition for AI-scale development, while human attention can focus on statements and design decisions.
Takeaways & Limitations
The study concerns one expert practitioner and does not estimate outcomes for other researchers, teams, or domains.
Abstract
from arXiv · showhide
For sixty years, machine verification has been a major cost overhead, affordable only for exceptional artifacts. Here we report that generative AI inverts this relationship: at AI speed, machine verification is not only economical but essential to productivity --- it is the incorruptible referee that lets one person safely direct autonomous machine work at scale. In five weeks, one researcher on consumer AI subscriptions directed a small fleet of AI agents from application code, through a verified compiler and executive, to a RISC-V processor taped out on a community silicon shuttle; no proof passed through human review, and no RTL was written by a human. The working discipline --- the Salt method --- rests on a proof kernel no hallucinated proof can pass: mathematical claims travel between agents as kernel-checked artifacts, and human attention is reserved for statements, designs, and rulings. Verification is stated link by link, from the Lean 4 kernel to SAT-checked equivalence at the silicon boundary. We publish the complete accounting: theorem provenance, a pre-registered token meter, floor-bounded human time, and an error ledger whose catch numbering runs to #256 --- a monotone counter over the mathematics campaign's append-only flags ledger, maintained 2026-07-07 to 2026-07-20 (one number, #79, was never assigned; later catches are recorded un-numbered) --- against zero incorrect proofs reaching the record.
1. Introduction — a personal journey
The Salt method combines generative AI with formal verification to make highly autonomous development auditable from application code through silicon tapeout. This paper presents a five-week, one-person case study and its measured, replayable accounting while explicitly making no claim of optimality, typicality, or generalizability.
- Salt method: The Salt method addresses verification’s longstanding cost and impracticality by grounding AI-generated software and hardware development in formal methods.Generative AI lowers the cost of producing candidate proofs and designs, but the supplied passage does not claim it independently solves assurance.
- Personal journey: The author frames the work as the completion of a decades-long mission linking a 1990 switching-network theorem with AI-directed software and hardware development.The mission to build AI that develops software was formed in 1992 after concluding that software development was the central bottleneck.
- Demonstration: One person using consumer subscriptions directed an AI fleet from a proved 1990 theorem to a network taped out on a community silicon shuttle in five weeks.The work was completed in evenings and weekends, with the AI fleet grounded in formal methods.
- Baseline: The case study begins from empty repositories atop public mathlib and is positioned against verified stacks such as CompCert, seL4, and CakeML.Those landmark systems were built by expert teams over years, whereas this demonstration uses consumer products in five weeks.
- Scope and limitations: The paper makes no claim that this configuration is optimal, typical, or generalizable to other researchers.Its documentation claim covers kernel-checked, replayable mathematical claims, commit-verified theorem provenance, metered economics, and append-only error logs.
- Contributions: The paper contributes a full-stack demonstration, stated verification grades, and complete accounting of economics, theorem provenance, and logged errors.Its reference configuration and required invariants are also stated in full.
Results · 2. Salt — the methodology
The Salt method treats trustworthy verification as a two-sided problem: machine-checking implementations is insufficient unless humans can understand and validate the specifications being proved. It therefore combines five agent-produced artifacts, kernel-checked certificates, adversarial controls, and explicit human responsibility for specification meaning and irreversible actions.
- 2. Salt — the methodology: Salt addresses both implementation correctness and specification correctness, because a machine-checked proof is only as trustworthy as the statement it proves.The method therefore treats formal specifications as objects requiring human comprehension, not merely as inputs to verification.
- 2. Salt — the methodology: At every scale, an English prompt yields an implementation, specification, kernel-checked proof, adversarial tests, and a simplified formal certificate.The certificate restates the specification in accessible vocabulary, while its kernel-checked implication contract links the restatement to the proved statement.
- 2. Salt — the methodology: The certificate layer makes statement-level review tractable, while active interrogation lets humans demand kernel-checked evidence for binders, hypotheses, and changed assumptions.Review is presented as an ongoing exchange with the system rather than a one-time reading of certificates.
- 2. Salt — the methodology: Tests can be promoted into theorems, with per-round kernel fixtures providing the method’s concrete mechanism for turning routine engineering checks into proofs.The workflow retains familiar testing practice while adding theorem promotion as an extra operation.
- 2. Salt — the methodology: Humans alone determine whether a specification matches their intent and whether a proved statement means what its reader thinks it means.Salt treats these limits of verification as an explicit discipline rather than an assumption.
- 2. Salt — the methodology: Salt commits to kernel-only truth, structured opposition for what the kernel cannot check, and deliberate conservation of scarce human attention.The method includes adversarial refutation before execution, independent witnessing of landings, command-linked measurements, and controls designed to fail.
- 2. Salt — the methodology: The method specifies six required invariants and six advisory articles, with a tool-agnostic required tier and a measured reference configuration for the advisory tier.Its requirements also reserve irreversible outward-facing acts to humans and require conditional objectives to declare their hypotheses and dispositions.
THE SALT METHOD
The Salt method makes machine checking the foundation of truth, uses structured opposition for what the kernel cannot verify, and reserves human attention as the scarcest resource. Its required invariants define the method, while advisory articles describe the configuration run and measured in this case study.
- Machine checking establishes truth, structured opposition checks what the kernel cannot, and human attention is treated as the scarcest resource.
- Required elements are mandatory, whereas the configuration as run is advisory.
- The method separates six required invariants from six advisory articles describing the reference configuration.Required states what the method is; Advisory states what this case study ran and measured.
3. The referee — the ground it stands on · 4. The fleet — the methodology in practice
The workflow makes the Lean 4 kernel the sole arbiter of mathematical claims, while hardware correctness is established through a deliberately nonuniform chain of Lean and SAT-based checks. In practice, one human directs five specialized AI seats whose cross-checking and adversarial review produce an auditable error ledger.
- 3. The referee — the ground it stands on: The Lean 4 kernel checks every mathematical claim against mathlib [26], with per-theorem axiom audits and no custom axioms or native_decide.The workflow’s trust base rests on a compact independent kernel and the statement, not on the model or its explanation.
- 3. The referee — the ground it stands on: Hardware correctness uses three independent checkers: specification-to-artifact links are Lean-checked, while Verilog and netlist correspondence links use SAT-based Yosys equivalence checks.The checking chain is explicitly nonuniform because no general Verilog-to-Lean importer existed as of 2026-08-11.
- 4. The fleet — the methodology in practice: Five long-running AI seats—coordinator, mathematics, compiler, silicon, and evidence—share a repository and append-only message bus under one human’s direction.The seats operate under written laws enabled by the kernel’s ground truth; every landing is independently witnessed by a second seat.
- 4. The fleet — the methodology in practice: Designs receive adversarial refuter passes before execution consumes them, and the campaign records the resulting incidents as an observable error record.The ledger’s unit is the incident rather than each mention, and it is constituted at the pre-publication freeze.
- 4. The fleet — the methodology in practice: The mathematics campaign’s adversarial layers caught design errors in a single incident ledger whose monotone numbering runs to #256.The append-only flags ledger was maintained 2026-07-07 to 2026-07-20; #79 was never assigned.
- 4. The fleet — the methodology in practice: The method returns implementation, specification, kernel-checked proof, adversarial tests, and a kernel-checked certificate for each objective, leaving the human to review and interrogate the certificate.Figure 2 describes the shared repository, append-only message bus, and kernel as the fleet’s operating structure.
5. The spine — the demonstration, from application to silicon tapeout
The demonstration builds a verified systems stack in seven days, within the program’s five weeks, carrying one chain of custody from theorem statement through compiler and executive to a taped-out physical design. Its central contribution is this end-to-end verification case study, not hardware novelty, with trust boundaries named at each link.
- 5. The spine — the demonstration, from application to silicon tapeout: The seven-day stack carries one chain of custody from a theorem statement through a verified compiler and executive to a taped-out physical design.The paper presents the spine as a systems-stack demonstration rather than a hardware contribution, with verification stated link by link and trust boundaries named at each link.
- 5. The spine — the demonstration, from application to silicon tapeout: The design includes a compiler from a structured language to a small instruction set, simulation proofs for its components, 352 kernel-emitted flip-flops, and 1,468 sequential cells in synthesis records.The fourth island is tied disabled in the reported configuration.
- 5. The spine — the demonstration, from application to silicon tapeout: The 1990 switching-network theorem proves the routing schedule’s full rotation closure in the kernel and drives the submitted switch.The paper identifies this theorem as riding on the design and points to Fig. 3.
- 5. The spine — the demonstration, from application to silicon tapeout: No die-level provenance ratio is stated because the structural join has not been re-run on the shipped design’s GDS.This limitation applies specifically to the shipped run’s GDS and does not negate the link-by-link verification account.
- 5. The spine — the demonstration, from application to silicon tapeout: 1,884 Lean lines of certificates and 22,679 agent-written Verilog lines across 71 files instantiate the systems and silicon portions of the stack.The reported silicon-side accounting excludes 294,232 flow-generated netlist lines across 48 files.
6. The forge — the mathematical foundations
The mathematical campaign forged the Salt method from documented failures under kernel checking, while producing a large, machine-checked Lean corpus. Its stated ambition—the twin prime conjecture—remains unproved, but the corpus formalizes substantial sieve results and delimits the method’s reach.
- Method formation: The method’s rules accumulated as case law from practical failures, including hallucinated results, wrong designs, and measurements quoted beyond scope.The ledger records the incident behind every law rather than applying a predesigned rule set.
- Method formation: The twin-prime foundation was accidental: any domain combining fast generation with an incorruptible checker could have forged the same laws.The author chose twin primes because hard mathematics under a kernel was an unforgiving proving ground.
- Corpus: Over 320,000 lines of Lean 4 were produced in 37 days, equal to 29.3% of mathlib under the identical extractor.The paper also publishes a raw-count figure of 658,103 lines and reports 3,466 commits with zero silent days.
- Formalized mathematics: The corpus machine-checks proofs of major sieve results that public proof-assistant artifacts had not previously established, while identifying independent formalizations rather than claiming firsts where concurrent artifacts existed.The surveyed claims include Siegel–Walfisz, the large sieve, Bombieri–Vinogradov, a lower-bound sieve, and Chen’s theorem; independent formalizations include Vaughan’s identity, the Maynard–Tao sieve, and the Montgomery–Vaughan Hilbert inequality.
- Limits and reach: The twin prime conjecture remains unproved: it is represented as a definition, while conditional results name their hypotheses and the corpus instead proves limits on the relevant Maynard-class and parity-invariant sieve certificates.The reported kernel results include M_2 ≤ 2 log 2 < 2 and the least k with M_k > 2 being five [25].
7. The economics
The economics section reports only costs and productivity measures supported by the records, while explicitly declining unsupported dollar-per-theorem and attribution claims. It documents 37 h 21 m of human engagement within a 116 h 40 m window, substantial unattended operation, and a governance model centered on periodic human rulings rather than proof review.
- Measurement limits: The records cannot derive a dollar cost per theorem, model-hours, per-account attribution, or a generated-versus-authored split of the Lean corpus.The section limits its quantitative claims to figures directly supported by the project records.
- Unattended operation: 43.0% of mathematics commits landed in silence windows of at least one hour, including a longest 20 h 56 m window carrying 26 commits and 12,310 inserted Lean lines.At four and eight hours, the mathematics shares were 14.5% and 8.8%; the systems repository was more interactive, with 24.4% at one hour and 4.6% at four hours.
- Human time: 37 h 21 m of human engagement occurred within a 116 h 40 m metered window, with machine-authored keystrokes excluded by the published correlation instrument.The estimate covers 45 engagement blocks and has a stated 4-minute uncertainty band.
- The human’s role: 20 council sittings produced recorded rulings, while the human took 7 irreversible acts, declined 5 further acts, issued 1 design veto, and performed 9 source verifications.Between periodic rulings, the fleet worked autonomously at the execution layer, with no proof passing through human review.
- Retraction: A verification-cost ratio was retracted after a second of three runs changed it by a factor of 52, demonstrating that the configuration’s value depends on governed numbers rather than impressive unsupported figures.One run fell within the 10–100× overhead range that the original claim had denied, and the retraction was retained in the ledger.
8. What the referee exports
The case study finds that a kernel-anchored ground truth reshaped AI-agent behavior: agents caught one another’s scope errors, retracted claims at the source, and turned incidents into written laws.
- 8. What the referee exports: Kernel-anchored ground truth enabled AI agents to catch one another’s confident scope errors and retract them at the source.The finding is that the kernel’s epistemics leak outward into the agents’ working culture.
- 8. What the referee exports: The agents converted campaign incidents into written laws because an incorruptible ground truth anchored their culture.
- 8. What the referee exports: The error ledger records recurring classes including measurements published with the scope of laws and registers asserting world-state instead of measuring it.
Discussion
The discussion argues that fast, cheap, fallible generation can reverse the traditional development-cost burden of formal verification, while emphasizing that the study demonstrates a specific regime rather than a general theory of research productivity. It also stresses that the work formalizes known mathematics and reports a single-practitioner case with explicit scope limitations.
- Interpretation: Formal verification, historically costly from Floyd and Hoare’s program logics onward, is presented as potentially practical when generation is fast, cheap, and fallible.The paper contrasts this regime with formal development being practical mainly for compilers, microkernels, and landmark theorems [9, 14, 16].
- Scope and limitations: The study contributes no new headline mathematics: the twin prime conjecture is untouched, and its celebrated theorems formalize known results.
- Scope and limitations: The evidence is bounded to one expert practitioner, makes no claims about other researchers, teams, domains, or labor markets, and includes named SAT-only links in the verified-hardware chain.Priority claims are dated because the field is changing on a timescale of weeks.
Methods
The methods define a five-seat fleet architecture with pinned Lean 4/mathlib dependencies [26], audited axioms, and a tool-versioned verification chain. They also preregister token and human-time accounting, specify a survey protocol, and disclose the use of Claude-family agents under consumer subscriptions.
- Methods: The fleet method specifies five seats, a bus, governing laws, published protocol documents, Lean 4/mathlib pins [26], and an axiom-audit protocol.The verification chain is documented link by link with its tools and versions.
- Methods: The study preregisters a token meter and defines a human-time rubric for accounting.
- Methods: The survey method for §6 uses five adversarial search lanes and per-claim evidence files.
- Methods: The AI-use disclosure identifies Claude-family models operated under consumer subscriptions, following journal policy.
Funding
The work received no external funding.
- The authors report that this work received no external funding.