Organizations: AIT Austrian Institute of Technology, Vienna, Austria · Aristotle University of Thessaloniki, Thessaloniki, Greece · Northeatern University, Boston, MA, USA
Translating informal requirements into formal specifications is challenging due to the ambiguity and variability of natural language (NL). This challenge is particularly pronounced when relying on compact (small and medium) language models, which may lack robust knowledge of temporal logic and thus struggle to produce syntactically valid and consistent formal specifications. In this work, we focus on enabling resource-efficient open-weight models (4B--14B parameters) to generate correct linear temporal logic (LTL) specifications from informal requirements. We present LTLGuard, a modular toolchain that combines constrained generation with formal consistency checking to generate conflict-free LTL specifications from informal input. Our method integrates the generative capabilities of model languages with lightweight automated reasoning tools to iteratively refine candidate specifications, understand the origin of the conflicts and thus help in eliminating inconsistencies. We demonstrate the usability and the effectiveness of our approach and perform quantitative evaluation of the resulting framework.
Figures & tables
Figure 1: Overview of the specification formalization approach.
Sentence
Expected
Actual
The system shall eventually reach a safe state.
GFsafe
Fsafe
p and q should not be both true.
G¬(p∧q)
¬(p∧q)
After p , always q .
G(p→Gq)
G(p→XGq)
Table 2: Ambiguous requirements where the generated formula differs from the expected one.
ARR
Group
RR
1. Every request is eventually granted.
G1
a. Every request is eventually granted.
2. Every message is eventually delivered.
b. No request remains ungranted.
3. Every button press is eventually processed.
c. Every request will eventually be granted.
4. Every order is eventually shipped.
G2
d. Every message is eventually delivered.
5. Every error is eventually logged.
e. No message is left undelivered.
6. Every task is eventually completed.
f. Every message will sooner or later be delivered.
Table 4: Robustness evaluation datasets.
Configuration
ARR
RR
( Qwen2.5-14B )
Group 1
Group 2
V1
3/6
3/3
2/3 †
V6
6/6
2/3
2/3
V7
4/6
3/3
1/3
Table 5: Robustness evaluation ( † : robust but incorrect translations for that group).
Req ID
Requirement
R1
every request must be granted
R2
requests will not be granted
R3
some request will be made
Table 6: Set of requirements: (left) original set and (right) variants of requirement R2