What TLA+ Can And Can’t Check

TL;DR

Prime Big Deal Days · Oct 6–7Offer from Amazon

Get school and study supplies delivered free — and shop member deals

• Fast, free delivery on millions of items
• Access to Prime Big Deal Days deals on October 6–7
• Prime Video, Amazon Music and more included

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

A report by TLA+ educator Hillel Wayne explains that TLA+ can check formal properties of modeled systems, including safety and liveness, but only when those properties can be expressed in its logic. It cannot by itself prove that an implementation matches its model, express every multi-step or real-time requirement, or establish claims that depend on comparing multiple possible executions.

TLA+ can help engineers check whether a formal model of a system satisfies specified safety and liveness properties, but it cannot verify requirements that cannot be expressed in its logic or guarantee that the resulting code matches the model. That distinction is the focus of a report by TLA+ educator Hillel Wayne, prompted by online discussion after Boris Cherny said Opus had used TLA+ to find race conditions in code.

Wayne describes TLA+ as a language for representing a system through behaviors, each a sequence of states. A state might record which traffic light is green; a behavior captures how those states change. Engineers can then formulate properties and check whether the model satisfies them across its behaviors. The results concern the model and the stated property, not every possible question about the real system.

Among the properties TLA+ can check are invariants, which say that a condition remains true in every state, and action properties, which describe how values change from one state to the next. These are examples of safety properties: roughly, assertions that something bad never happens. TLA+ can also express liveness requirements, in which something good eventually happens—for example, that a system eventually reaches agreement after a leader election.

Wayne identifies several limits. A property must first be expressible as a logical formula; TLA+ cannot formalize an unclear human requirement on its own. Its described safety checks focus on individual states or single steps, so requirements spanning multiple steps can be difficult to state natively. The report also says TLA+ works with logical rather than real time and does not define properties over floating-point operations. In addition, properties are evaluated over individual behaviors, which rules out some claims about whether a behavior is possible or how multiple behaviors compare.

What Model Checks Can Establish

The distinction matters as software teams consider using formal methods alongside AI coding tools. Finding a race condition in a model can reveal a concurrency flaw represented there, but it does not show that every relevant requirement has been captured, that the model includes every implementation detail, or that generated code faithfully follows the model. Wayne explicitly cautions that a correct design does not automatically produce correct code.

For readers evaluating claims about formal verification, the practical question is not simply whether a tool checked a system. It is which property was checked, against which model, and whether that model corresponds to the deployed implementation. TLA+ can give strong assurances about properties within that scope; it does not turn unspecified expectations into proven guarantees.

From Opus Claim to TLA+ Limits

Wayne’s report says the discussion followed a comment by Boris Cherny, identified as Claude Code’s inventor, that Opus had used TLA+ to find race conditions in code. Wayne welcomes the interest in the method but warns against claims that formal methods could solve the problems of agentic software development once and for all. His report shifts attention from familiar gaps between a design and its implementation to a more basic issue: the limits of properties that can be stated and checked.

In TLA+, an invariant such as “at most one light is green” can be checked across all modeled states. Liveness formulas can capture patterns such as a request eventually receiving a response. But a specification is not a complete description of reality by default. Engineers have to decide what the system’s states and transitions represent, what assumptions apply, and which requirements matter. The check answers the formal question supplied; it does not independently validate those choices.

Limits Beyond the Model

The supplied report excerpt ends while Wayne is discussing properties over sets of behaviors, called hyperproperties. It introduces the topic but does not include the rest of his explanation, so the particular examples and conclusions in that section cannot be established from the available text. The excerpt also does not give technical details about Opus’s reported use of TLA+, the code it examined, or how the race conditions were identified.

More generally, the source does not specify which model, assumptions, or verification workflow were used in the reported coding example. It therefore does not establish how broadly the result applies to other projects or whether the model was checked against the final implementation. Those questions remain open on the information provided.

Questions for Future Verification Claims

The next useful detail in any similar report would be the property being checked, the model’s scope, and the relationship between that model and the delivered code. Without those details, a statement that a tool “found a race condition” signals a potentially useful result but does not define the full assurance provided.

For teams using TLA+, the work proceeds by specifying system states and transitions, writing properties that capture requirements, and checking the model against them. Any claim about a verified system should name those boundaries. The source gives no timetable for additional information about Opus’s use of the language, so whether further technical detail will be published is unclear.

Key Questions

What can TLA+ check?

TLA+ can check formal properties of a modeled system, including invariants that must hold in every state, action properties describing single-step changes, and liveness properties requiring something eventually to happen.

Does a TLA+ check prove the code is correct?

Not on its own. A check establishes whether the model satisfies a specified property. It does not automatically prove that the model captures every requirement or that the implementation matches the model.

What happens if a requirement cannot be written as a formula?

TLA+ cannot check it as a formal property until it has been expressed in a form the method can evaluate. The source says this limitation applies to formal methods more broadly, not just TLA+.

Can TLA+ verify real-time requirements?

Wayne’s report says TLA+ uses logical time, not real time, and describes limits on expressing requirements that span several steps, such as a response within a fixed number of steps.

What was reported about Opus and TLA+?

Wayne says Boris Cherny commented that Opus had used TLA+ to find race conditions in code. The available source does not provide the model, code, or verification details behind that report.

Source: hn