Specification language

Before anyone writes a program, it must be clear what the program is supposed to do. Such requirements are often noted down in plain English, for instance: “An ATM must never dispense more money than is in the account.” That is exactly where the problem lies, because everyday language is ambiguous and leaves gaps open. A specification language is an artificial language with strictly fixed rules in which the same requirement can be written down unambiguously. It describes the desired behavior, not the path to get there. The difference from a programming language is important: programming languages tell a computer step by step what to do. A specification language only states what result must hold in the end.

Why unambiguity in software can be a matter of life and death

Most severe software errors do not arise while typing the code. They arise much earlier, because two people involved understood the same requirement differently. A sentence like “The system should respond quickly” means one second to one person and one minute to another. A specification language forces such details to be made precise before money flows into development.

This becomes especially important wherever an error is expensive or dangerous. Braking systems in cars, control systems in aircraft, chips in data centers, and banking software are therefore often formally specified. A famous example is a computation error in an Intel processor from 1994. The recall cost the company around 475 million US dollars at the time. Since then, chip manufacturers have systematically checked their designs against formal descriptions.

A second advantage is checkability. Because a specification is mathematically unambiguous, software can automatically compare it to the actual program. This is called formal verification. Testing only ever shows that nothing went wrong in the cases examined. Verification, by contrast, can show that an error does not occur in any case.

Assertions, states, and the checker’s perspective

Most specification languages build on logic and set theory, that is, on mathematics taught in school. Typically three things are described: the precondition, the postcondition, and the invariant. The precondition states what must hold for a function to be called at all. The postcondition states what must hold afterward. An invariant is a statement that must remain true at every point in time.

For the ATM, the invariant would be: the account balance is never negative. The precondition for a withdrawal would be: the requested amount is less than or equal to the balance. The postcondition would be: the new account balance is the old one minus the amount paid out. A verification program now works through all possible cases. If it finds a sequence that violates the invariant, it reports a counterexample.

One can imagine this like a building plan with a structural analysis. The plan does not say in which order the workers do their tasks. It specifies which loads the building must be able to withstand. A common misconception is that a specification makes errors impossible. It only guarantees that the program matches the description. If the description itself is conceived incorrectly, even the best verification will not help.

From TLA+ to the prompt: Where formal descriptions show up

Well-known representatives are TLA+, Z, Alloy, and the language VDM. Amazon has been using TLA+ for years to check the workflows of its cloud services. Engineers used it to find errors that would have remained undetected by ordinary testing for years. In chip development, the language SystemVerilog Assertions is standard. Anyone who reads reports about semiconductors or cloud infrastructure regularly encounters these terms.

Weaker forms are also common in everyday life. When a web API precisely defines which data it expects and returns, that is a specification in textual form. Formats such as OpenAPI or JSON Schema fulfill this task without requiring full mathematics.

The topic is gaining new momentum through AI coding assistants. Models now write large amounts of code that no one reads line by line anymore. This makes it more important to determine what standard is even used to judge whether this code is correct. Some researchers therefore see specification as the actual work of humans. The human precisely describes the goal, the machine generates and checks the path.