An arXiv preprint on VDM operations reports a lower share of generated proof obligations marked “UNCHECKED” in a corpus comparison: 2.4%, compared with 9.6% for the earlier approach. The paper presents the result as further progress toward generating and checking obligations for operations. But the comparison is descriptive: it comes with no confidence interval, significance test or specification-level breakdown. The paper also does not establish that the 2.4% figure applies to other specification corpora.
Why operation proofs are difficult
The work focuses on a bottleneck in formal software specification: one operation may have several possible paths, and each path can create conditions that need to be checked. In this setting, a proof obligation is a condition generated from an operation specification that must be discharged to show that the specified rules hold. The baseline approach described by the authors handled control-flow complexity by analyzing possible paths, ignoring loops, and creating obligations for each path to an obligation point. The new paper asks how that process can be extended to loop, operation-call and recursive-measure cases.
The update adds two named annotations: @LoopMeasure for loop-variant obligations and @OperationMeasure for recursive-operation measure obligations. The labels make those two kinds of progress visible to the generator and the surrounding tools. The paper does not report independent validation of every supported construct, so these additions describe an expanded method rather than a complete assessment of how it performs.
Making loops and calls explicit
For loops, the design defines a variant as a natural-number expression, in effect a non-negative count, that decreases toward zero. It also uses ghost state - bookkeeping used in the proof rather than the program’s ordinary output - to represent which elements have already been processed in set and sequence loops. That lets the generated conditions refer both to progress and to the part of a collection already handled. The paper discusses runtime checking separately and does not report formal discharge rates for loop obligations.
For simple operation calls, the generator quantifies possible updated-state values and qualifies them with the called operation’s precondition and postcondition. The same support covers implicit operation definitions and specification statements. Calls that return a value add the return value to that quantified picture, alongside possible state updates, with the called operation’s precondition and postcondition still constraining the result. The description is about how obligations are formed; it is not an independent benchmark of operation-call coverage.
Recursive operations use @OperationMeasure. The mechanism creates a measure function for the recursive operation and generates obligations analogous to recursive-function checks, but with a state argument included. In practical terms, the measure gives the proof process an explicit quantity to track as the operation calls itself. The paper does not report a systematic termination-validation benchmark, so the examples show the mechanism rather than a measured result across a broad test set.
Testing the update
Repeated testing used a large corpus of VDM-SL specifications distributed with the tool and produced over 7,000 obligations. In that reported comparison, 9.6% of obligations were marked “UNCHECKED” under the earlier work, while 2.4% were marked that way with the latest work. These percentages are descriptive: the paper gives no confidence interval, significance test or specification-level breakdown. The corpus is described as distributed with the tool.
QuickCheck is used to probe generated conditions and report counterexamples. In a factorial example, the test exposes a boundary-condition failure at zero: the recursive exit check is written as a = 1 rather than a <= 1, so a zero argument fails. The example shows how a specific flaw can surface in the workflow, but it is illustrative rather than a general estimate of defect detection.
That workflow is also reflected in the editor integration. VDM-VSCode adds constraint-focused CodeLens filtering and presents QuickCheck results in context within the proof-obligation view. The paper reports these as tooling features, not as measured improvements in usability or debugging efficiency.
Where the method still stops
Several hard cases remain. Expressions with statically indeterminate call order are left unresolved, while inter-module calls whose local-state updates cannot be determined produce obligations the paper describes as under-qualified. Those gaps mark the boundary of what the reported update handles, and they mean the 2.4% figure should not be read as a universal coverage rate.
The document is an arXiv version-one record dated 20 August 2026; no journal or peer-review publication status is reported in the supplied record. The acknowledgements identify support from the European Union, Aarhus University, Newcastle University and the Grundfos Foundation.
Paper data and sources
Original title: Further Progress Towards Operation Proof Obligation Generation for VDM
Authors: Nick Battle, Carlo Rende, Peter Gorm Larsen
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-20
DOI: Not available
Original paper · Full text