&Truth Raises $70M, but Code Proofs Still Depend on the Specification

&Truth emerged October 29 with a $70 million seed round, according to Unite.AI's October 30 report. Founded in early 2026 by Clark Barrett and Ilya Sergey, the company is pursuing formal verification for code. The announcement puts funding behind a question that becomes more important as businesses accept more AI-generated software: what evidence supports a claim that the program behaves correctly?

The company claims AI can accelerate proof work by 100x or more, with automation contributing another 100x. Neither claim is an independently validated, universal speedup. The relevant distinction is between producing a proof faster and establishing that the thing being proved is the thing a buyer needs.

The Specification Sets the Boundary

Formal verification relates an implementation to a specification under stated assumptions. A result can be mathematically sound while the specification omits an important business rule. For a buyer, the specification is therefore part of the product evaluation, not supporting paperwork to inspect after the demonstration succeeds.

Consider a proposed payment component. A requirement about preserving balances would not, by itself, describe who is authorized to initiate a payment. That is an illustrative distinction, not a reported &Truth deployment. It shows why a proof claim needs an accompanying explanation of the property checked and the behaviors left outside the claim.

The company's $70 million round establishes financing, as reported by Unite.AI. It does not establish that buyers have already solved requirements capture. Before discussing faster proof generation, a team needs to identify the decisions that its specification expresses and the assumptions that connect that specification to its actual application.

Independent Checking Changes the Buying Question

The reported approach includes independently checkable verification proofs. That matters because a buyer need not treat an AI system's confident explanation as the final authority on its own work. The evidence can be subjected to a separate checking process, provided the buyer understands the checker and the claim it accepts.

Independent checking still has a defined boundary. It does not automatically establish that an external service behaves as assumed or that deployment configuration matches the model used for verification. An evaluation should distinguish the proof artifact from the surrounding operational claims, rather than presenting them as an undivided assurance package.

The companion essay references Turing in 1949, placing the effort within a long-running program-verification discussion. That history is context, not evidence of present language coverage. The announced goal should not become a procurement statement that every language or existing repository is already supported; demonstrated scope needs to be requested directly.

The Cost Moves Into Defining Correctness

The cost of verification includes deciding what correctness means. Domain specialists may need to explain rules that were previously implicit, while engineers identify where those rules meet implementation details. A faster proof workflow does not remove disagreement over a requirement or decide which operational assumptions are acceptable to the business.

The 100x-or-more AI claim and the separate 100x automation claim should remain separate claims in an evaluation. There is no basis here for multiplying them into a promised delivery improvement. Buyers need the workload definition, the comparison being made, and an account of human effort before interpreting either figure as a project forecast.

There is also a maintenance question. When code or requirements change, the team needs a process for determining which proof claims still apply. That is a question to put into a pilot agreement, not a reported deficiency in &Truth's system. Without a clear change process, a checkable artifact can be mistaken for permanent assurance about a changing application.

A useful scope document should also say what the proof does not attempt to establish. Ask whether an unmodeled behavior is rejected, left to testing, or assigned to another control. Those answers make the assurance boundary inspectable by the person approving deployment, rather than leaving interpretation to whoever watched the demonstration.

What To Do About It

• Write the property first: Choose an existing code path and have its owner state the business rule without relying on the vendor's demonstration language. Record assumptions and exclusions in a shared Markdown specification.
• Ask for the checking path: Request an explanation of how an independent party checks the produced proof and what that check actually establishes. Keep the proof, specification, and checker instructions together in Git.
• Separate speedup evidence: Ask which work is included in the AI acceleration claim and which work belongs to automation, including human specification effort. Keep the claims separate in your assessment of 100x.
• Test the change process: Propose a requirement revision and ask what must be rechecked before the result can support a release decision. Capture the answer as an acceptance checklist in your issue tracker.

The Bottom Line

&Truth's reported $70 million seed round makes formal verification a concrete purchasing conversation rather than just an abstract response to AI coding risk. Independently checkable proofs can provide a different kind of evidence from model-generated explanations. Their value still depends on the property being proved and the assumptions surrounding it. Buyers should purchase a clear assurance boundary, not convert company speedup claims into a blanket correctness guarantee.