🤖 AI

Neurosymbolic Auditing of Natural-Language Software Requirements

This paper introduces VERIMED, a neurosymbolic pipeline that leverages large language models and SMT solvers to audit natural-language software requirements by detecting ambiguity through stochastic formalization variations and verifying consistency and safety via counterexample-guided repair, achieving a significant accuracy boost in medical-device safety requirements.

Original authors: Bethel Hall, William Eiers

Published 2026-05-14

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Bethel Hall, William Eiers

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the architect of a life-saving machine, like a dialysis device that cleans blood for patients. You write down the rules for how this machine should behave in plain English: "If the blood flow stops, sound the alarm."

The problem is that human language is messy. Words can be vague, sentences can contradict each other, or a rule might be impossible to follow without anyone noticing. If a computer program tries to build this machine based on your messy notes, it might build something that looks perfect on paper but is actually dangerous in real life.

This paper introduces VERIMED, a new "neurosymbolic" system (a fancy term for a team-up between a creative AI and a rigid logic robot) designed to act as a super-auditor for these safety rules.

Here is how VERIMED works, explained through everyday analogies:

1. The Translator and the Logic Robot

Think of the system as having two parts:

The Translator (The LLM): This is a creative AI that reads your English rules and tries to translate them into a strict, mathematical language (SMT) that a computer can verify.
The Logic Robot (The SMT Solver): This is a rigid, unyielding machine that checks the math. It doesn't care about "feelings" or "intent"; it only cares if the rules make logical sense.

2. The "Stress Test" for Rules

Before the machine is built, VERIMED runs four specific tests on the translated rules to find hidden defects:

The "Can It Happen?" Test (Vacuousness): Imagine a rule says, "If the machine is underwater, turn off the power." If the machine is never supposed to be underwater, this rule is useless. The Logic Robot checks: "Is it actually possible for the machine to be underwater?" If the answer is "No," the robot flags the rule as a ghost—it exists but never does anything.
The "Can It Break?" Test (Violatability): The robot tries to break the rules. It asks, "Can I make the machine do something unsafe while still following the rules?" If it finds a way to break the safety, it shows you exactly how (a "counterexample"), like a proof that says, "See? If you set the dial to 50, the alarm doesn't go off, even though you said it should."
The "Double-Bookkeeping" Test (Redundancy): Sometimes, you write two rules that say the exact same thing. One might be, "Don't let the pressure go above 200," and another says, "Don't let the pressure go above 200." The robot finds these duplicates and says, "You're repeating yourself. Do you mean to have both, or is one of them wrong?"
The "Global Harmony" Test (Consistency): The robot checks if all the rules fight each other. If Rule A says "Turn the pump on" and Rule B says "The pump must be off," and both are supposed to happen at the same time, the robot screams, "This is impossible!"

3. The "Ambiguity Detector" (The Magic Trick)

This is the paper's most creative idea. Sometimes, a sentence is so vague that it can be interpreted in two different ways.

The Analogy: Imagine you tell a chef, "Cook the steak until it's done." The chef might think "done" means medium-rare, while you meant well-done.
How VERIMED catches this: Instead of asking the AI to translate the rule once, it asks the AI to translate the same rule five different times, like asking five different chefs to interpret "done."
- If all five chefs write down the exact same recipe, the rule is clear.
- If one chef writes "medium-rare" and another writes "well-done," the system spots the disagreement. It then says to the human: "Hey, your rule is ambiguous! Here are two different ways your sentence could be read. Please clarify."

4. The "Repair Shop"

When the Logic Robot finds a mistake or an ambiguity, it doesn't just say "Error." It acts like a helpful mechanic:

For broken logic: It shows the AI the exact scenario where the rule failed (the counterexample). The AI then rewrites the rule to fix that specific hole.
For vague language: It shows the human the specific point of confusion (e.g., "Is 200 degrees included or excluded?"). The human clarifies, and the system re-translates until everyone agrees.

What Did They Find?

The researchers tested this on a set of 64 safety rules for a dialysis machine.

The Results: The system found that 2 rules were redundant (duplicates) and 12 rules were ambiguous (could be read in multiple ways).
The Fix: When they used the "counterexample" feedback (showing the AI exactly how it failed), the AI's ability to answer safety questions jumped from about 55% accuracy to nearly 99%.
The Ambiguity Fix: After the system flagged the vague rules and humans clarified them, the AI stopped producing conflicting translations. The "ambiguity" dropped to zero.

The Bottom Line

VERIMED is a safety net. It uses a creative AI to translate human rules into math, and a rigid logic robot to check if those math rules are consistent, unambiguous, and actually safe. It doesn't just check if the code works; it checks if the instructions for the code make sense before the machine is ever built.

Important Note: The paper explicitly states this was tested on medical device requirements (dialysis machines) and a pain-management pump. The authors warn that this system is a tool for experts to review requirements, not a replacement for human experts, and it should not be used in real life without independent human review.

Technical Summary: Neurosymbolic Auditing of Natural-Language Software Requirements

Problem Statement

Natural-language software requirements, particularly in safety-critical domains like medical devices, frequently suffer from ambiguity, inconsistency, and underspecification. These defects are dangerous because they propagate into formal models and implementations, potentially leading to the verification of incorrect specifications or the deployment of unsafe behavior. While Large Language Models (LLMs) have advanced the field of autoformalization (translating natural language to machine-verifiable specifications), syntactic validity alone is insufficient. A well-formed formal specification may still be globally inconsistent, contain unreachable trigger conditions (vacuousness), or admit multiple plausible interpretations of the source text. In the absence of a ground-truth formalization, there is no oracle to detect these semantic failures, as LLMs often default to the most statistically common reading or omit implicit constraints.

Methodology: The VERIMED Framework

The authors propose VERIMED, a neurosymbolic pipeline designed to audit natural-language requirements by translating them into a unified SMT (Satisfiability Modulo Theories) model and leveraging solver queries to detect defects. The framework operates on a fixed schema of typed state variables (Boolean control states and real-valued parameters) and domain constraints.

The pipeline consists of four stages:

Ambiguity Resolver: Before formalization, each requirement is screened for stability. The system samples $N$ independent formalizations from the LLM at elevated temperature. It performs bidirectional SMT equivalence checking between pairs of encodings. If the encodings are not equivalent, the requirement is flagged as ambiguity-sensitive. The solver generates concrete "witnesses" (specific states where the encodings disagree), which are fed back to the LLM to rewrite the requirement until all samples converge to a single encoding.
Autoformalizer: The disambiguated requirements are translated into a single SMT-LIB specification. The system employs a bounded syntactic repair loop where solver error messages guide the LLM to regenerate malformed code until a valid model is produced.
Property Verifier: This module executes four specific audit queries on the assembled model $M$ $M$ :
- Global Consistency: Checks if $M$ is satisfiable. If unsatisfiable, an unsat core identifies conflicting requirements.
- Vacuousness: For conditional requirements, checks if the trigger condition can ever be satisfied under domain constraints.
- Violatability: Checks if a requirement can be broken within the domain, returning a concrete violating assignment if possible.
- Redundancy: Checks if a requirement is already enforced by the rest of the specification.
Query Verifier: This stage verifies scenario-based safety questions. It checks if a proposed answer is entailed by the model ( $M \land s \land \neg a$ is unsatisfiable). If a violation is found, the solver returns a counterexample. This counterexample, along with the violated requirements, serves as feedback for a repair loop to correct the LLM's answer.

Key Contributions

The paper introduces the following contributions:

A Neurosymbolic Framework: VERIMED operationalizes the translation of natural-language requirements into a single SMT model, using solver outputs as the primary signal for downstream review.
Requirement-Level SMT Audits: The authors formulate four audits (consistency, vacuousness, violatability, redundancy) that operationalize established quality criteria.
Ambiguity Detection via Stochasticity: The paper introduces a method for detecting ambiguity by exploiting the stochastic nature of LLMs. By sampling multiple formalizations and checking for bidirectional SMT inequivalence, the system flags requirements that admit multiple plausible readings. Solver-generated witnesses then drive natural-language clarification.
Counterexample-Guided Repair (CEGR): The study demonstrates that the granularity of symbolic feedback significantly impacts repair effectiveness.

Experimental Results

The framework was evaluated on a corpus of 64 natural-language safety requirements from a hemodialysis machine specification, with secondary evaluation on a PCA pump specification.

Autoformalization and Audit: The system successfully generated a solver-checkable SMT model for all 64 requirements. The model was globally consistent and contained no vacuous requirements. The audit flagged 2 requirements (3.1%) as redundant. Round-trip semantic equivalence (translating SMT back to text and re-formalizing) was achieved for 100% of requirements, with a mean cosine similarity of 96.2% between original and reconstructed texts.
Mutation Detection: The pipeline detected 97.3% of 256 mutated requirements (representing faults like false-alarm suppression and limit violations) across four fault categories.
Counterexample-Guided Repair: In a question-answering task, the use of concrete SMT counterexamples as feedback (CEGR) raised verified accuracy from a baseline of 55.4% (no feedback) to 98.5%. Providing only the violated requirements (without the concrete counterexample) yielded 80.0% accuracy, demonstrating that the concrete witness state is the critical driver for repair.
Ambiguity Resolution: The ambiguity resolver flagged 12 of 64 requirements (18.8%) as producing multiple distinct encodings. After SMT-guided clarification, all flagged requirements converged to a single encoding (100% pairwise agreement), reducing the mean distinct encodings per requirement from 1.59 to 1.00.

Significance and Claims

The paper claims that VERIMED successfully operationalizes the auditing of software requirements through SMT-based queries, addressing the "invisible" nature of semantic defects in autoformalization. The authors emphasize that:

Stochastic variation is a signal: Disagreement across independent formalizations is a reliable indicator of ambiguity in the source text.
Granularity matters: The usefulness of symbolic feedback is highly dependent on its specificity; concrete counterexamples are significantly more effective for repair than abstract requirement lists.
Consistency is insufficient: Internal consistency of a formal model does not guarantee the absence of defects; behavioral preservation and ambiguity detection are necessary complements.

The authors maintain a modest scope, noting that their findings are specific to infusion-related medical devices and that the approach relies on proxy signals (consistency, mutation sensitivity, etc.) rather than a direct measure of intent faithfulness. They explicitly state that the results should not be used in safety-critical applications without independent expert review and that the current implementation does not support full temporal logic, approximating temporal requirements via current state conditions.