Papers for

software testers

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Veritas reveals which tested branches really catch faults in Java

Covered Is Not Checked: Which Branch Outcomes Would Your Tests Notice?

Abstract: Code coverage reports what tests execute, not whether tests detect faults. Checked coverage addresses this gap by tracing code that influences test oracles through dynamic slicing, but slicing is costly, and Java slicers struggle with modern language features and complex programs. We present Veritas, a slicing-free approach that directly tests whether covered behavior is checked. We target object branch coverage (OBC), a compiled-code structural criterion with fault-detection effectiveness comparable to source-level Modified Condition/Decision Coverage (MC/DC), which is required at the highest assurance level of DO-178C. For each covered object-branch outcome, Veritas forces the opposite outcome and credits checking only when the change is executed, a previously passing test fails, and the failure is attributable to that outcome. Thus, Veritas distinguishes execution from demonstrated fault detection without dynamic dependence analysis. We evaluated Veritas on eleven open-source Java projects containing 51,382 object-branch outcomes. We find that 18% of covered outcomes can be changed without failing any test, exposing weaknesses hidden by coverage. Among surviving mutants, about half are never activated by test inputs, while the rest are activated but undetected. Compared with slicing-based checked coverage, Veritas identifies 4,763 cases where tests detect a change that slicing does not credit, while 19% of cases credited by slicing produce no detected failure when changed. Weakening assertions increases this gap and reduces fault detection in every project. Moreover, code locations controlled by weakly checked outcomes are 12.4--54.7 percentage points more likely to have an undetected independent fault than locations controlled by checked outcomes. These findings show that directly testing outcomes provides actionable evidence of oracle effectiveness beyond structural coverage.

Sat 24 OctSoftware Engineering
The gist
Knowing which parts of software get run by tests isn't the same as knowing if those tests can find bugs. The authors introduce Veritas, a method that checks if tests truly notice when certain code choices are changed. Veritas changes covered decisions in the program to see if tests fail as they should, revealing many cases where tests run code but miss faults. This method works without heavy program analysis and shows which code parts are weakly tested and more prone to hidden bugs.
Open → 2610.33708v1

Vision language models show varied sensitivity to image and text changes

Search-Based Testing of Modality Sensitivity in Vision Language Models

Abstract: Vision-language models (VLMs) process images and text jointly, yet robustness evaluations often perturb these inputs separately or assess only predefined corruption levels. Such evaluations provide limited evidence of which modality is more susceptible to perturbations and whether smaller changes across both modalities can jointly expose failures. We present MoST, a black-box testing framework that characterizes modality sensitivity by comparing image-only, text-only, and joint perturbations. MoST uses multi-objective search to select and combine perturbations and adjust their severity, seeking prediction degradation while limiting changes to images and prompts. We evaluate MoST on four VLMs performing object localization on ImageNet and driving images. The models exhibit distinct sensitivities: textual perturbations dominate for some, whereas others are susceptible across both modalities. In several configurations, joint perturbations match or exceed the effectiveness of single-modality perturbations with smaller modifications to each input. In a human study, 60-76% of assessments across models judge the perturbed inputs sufficiently understandable to perform the task, and human localization is more accurate than that of the corresponding VLMs. These results show that evaluating modalities separately can overlook failure-inducing combinations and that modality sensitivity provides a more detailed account of VLM robustness than aggregate failure rates alone.

Fri 23 OctComputer Vision and Pattern RecognitionSoftware Engineering
The gist
Vision-language models understand pictures and words together, but testing often changes pictures or words separately. The authors created a new way to test these models by changing images and text at the same time in small ways. This method finds that some models are more sensitive to changes in words, others to images, and some to both together. People can still understand the changed images and text better than the models can. This shows that testing both inputs together reveals weaknesses that separate tests might miss.
Open → 2610.32360v1

Benchmark tests language model safety under missing facts

EpiSEM-Bench: Evaluating Safety and Evidence Recovery in LLM Agents under Missing Evidence

Abstract: Tool-using language model agents rely on environmental facts to decide whether an action is permitted. When a tool response omits a safety-relevant fact, an agent may carry out a prohibited action even though the user request is benign and every returned statement is true. We introduce \bench{}, an executable benchmark for evaluating unsafe execution, safety boundaries, and evidence recovery in LLM agents under missing evidence. It contains 300 matched unsafe/safe task pairs across six domains. By systematically suppressing critical facts, the benchmark measures unsafe execution under critical evidence omission and determines the minimum observed failure cardinality, including failures with full evidence and cases with no observed failure after exhaustive testing. An independent audit tool tests whether agents seek missing facts and then withhold prohibited actions while completing permissible tasks. The benchmark reveals substantial variation across the ten models in omission robustness, evidence acquisition, and appropriate action. Resistance to missing evidence does not necessarily translate into useful recovery. Recovery access reduces unsafe execution for all ten models, but agents differ in whether they actively obtain the missing facts and use them to act appropriately in both worlds.

Thu 22 OctArtificial IntelligenceMachine Learning
The gist
Sometimes AI models use tools to get facts before acting. If some important facts are missing, the AI might do something unsafe even if the user’s request is harmless. The authors created a test called EpiSEM-Bench that checks how well different AI models handle missing facts and avoid unsafe actions. Their tests show that some models are better at finding missing information and acting safely, but there is still lots of variation.
Open → 2610.31650v1

Typed template fuzzing improves software testing across many languages

Typed Template Fuzzing

Abstract: Fuzzing software with complex inputs has been a longstanding challenge. Traditionally, fuzzers either programmatically encode language constraints, requiring significant engineering effort, or rely on users to declare grammars and constraints. Recent LLM-based fuzzers address these drawbacks but introduce new issues. Some use LLMs for test generation, sacrificing throughput and producing invalid inputs when the LLM makes mistakes. Others rely on language-specific parsers, static analysis, and AST manipulation libraries. We introduce Typed Template Fuzzing (TTF), a lightweight LLM-based fuzzing methodology. The key idea is to use LLMs in a preprocessing step to transform seeds into typed templates. The typed templates then enable semantically aware, mutation-based fuzzing without language-specific parsers, type checkers, or further LLM queries during fuzzing. By exploiting the correspondence between seeds and templates, TTF can moreover repair LLM mistakes. We have implemented TTF in our tool Typos, which we evaluate across 21 input languages, including C, C++, Go, Rust, SystemVerilog, Scala, and Java, as well as libraries such as PyTorch and Qiskit. In a six-month fuzzing campaign, we reported 135 bugs, 128 of which were previously unknown. Perhaps most notably, on average 96% of Typos's mutants are valid, coming close to the validity rates of domain-specific fuzzers. Our evaluation further shows Typos's benefits over the state of the art.

Thu 22 OctSoftware EngineeringProgramming Languages
The gist
Testing software with complicated inputs is hard because those inputs need to follow special rules. The authors created a new method called Typed Template Fuzzing that uses language models just once to prepare templates, then quickly mutates these templates to create many valid tests. This approach works well for many programming languages without extra language-specific tools, finds many bugs, and keeps almost all tests valid. Their tool Typos showed good results by finding many new bugs and maintaining high test validity.
Open → 2610.31342v1

Benchmark measures AI agents creating playable video games across five engines

From Code to Playable Systems: CEGame-Bench for Long-Horizon Game Creation Agents

Abstract: A game ships when a player can launch it, finish it, and return to a saved world, none of which a successful build guarantees, yet game-creation agents are mostly tested on one engine or on one-prompt browser games. We present CEGame-Bench, the first long-horizon benchmark for complete-game creation across five production engines: Defold, Godot, Roblox Studio, Unity, and Unreal Engine. Agents build each game from an empty project and a design document in runs averaging up to 295 steps and 65M tokens; the document doubles as a contract, and a hidden evaluator accepts a game only by real-input play. Under four scaffolds, agents earn most integration points but usually under half the gameplay points, and their games reach the ending in only 16% of runs, while references built by engineers with coding agents score near the maximum, which places this artifact-to-play gap in the agents. No two engines rank configurations alike (Kendall's tau 0.14-0.62), and the same game usually scores higher on Unity and Unreal Engine, which check more before play. We release Game Completion Boost, an agent skill for requirement-driven playtesting and repair that raises the execution-based score of three models by 14.1-24.3 points.

Mon 19 OctArtificial Intelligence
The gist
Making a video game that you can start, finish, and save is hard, and computer programs that create games usually only work with simple tools or very short games. The authors created CEGame-Bench, a test environment where AI agents build full games from scratch using five popular game engines and detailed instructions. The agents often get many parts right but usually fail to create games that can be fully played through, unlike human engineers assisted by AI. They also made a new AI skill that improves the agents’ ability to playtest and fix games, helping them complete more games successfully.
Open → 2610.26098v1

Random clocks on computation paths reveal new time reach limits

Random Clocks on Computation Paths]{Random Clocks on Computation Paths: How Far Can They Reach, and When Does Stepping Back Help?

Abstract: We watch a computation only at moments chosen by a random clock that can leap ahead, pause, or step back, and we count looks rather than steps. How far can such a clock reliably see with polynomially many looks, and does stepping back help? Rare long leaps reach exponential and doubly exponential time, with infinitely many levels between polynomial and exponential time. A clock that tends to fall back sees only the start of the input, and below polynomial time we find infinitely many incomparable levels. Stepping back can help decisively. For clocks whose long leaps occur only at rare positions, no forward-only clock goes beyond polynomial time, while even single steps back raise the reach to exponential time. Stepping back cannot help, however, when the clock's leaps ignore its position.

Mon 19 OctComputational Complexity
The gist
This work studies a special kind of 'random clock' that watches computer programs at unpredictable moments, including jumping forward, pausing, or stepping backward. The authors explore how far these clocks can see into the computation with limited looks and whether stepping back can help. They find that rare long jumps let the clock glimpse very far, even exponentially far in time, while clocks that frequently step back see less. Interestingly, stepping back can significantly extend how far the clock sees when jumps happen rarely, but not when jumps ignore position.
Open → 2610.25830v1

Agent automatically builds test setups to catch software bugs

Towards Agentic Proof Harness Engineering

Abstract: Formal verification of real-world projects requires substantial manual effort, from specifying correctness properties to constructing the infrastructure needed to check them. We envision verification agents that assist developers throughout this process. Among the many tasks involved, one stands out as both foundational and amenable to automation: proof-harness engineering. A proof harness defines an isolated verification environment for a program unit, such as a function or module, by providing symbolic inputs, initialization code, and models of its dependencies. Today, proof-harness engineering remains largely a manual task performed by verification engineers. To explore the potential of coding agents for this task, we propose an agentic proof-harness engineer that automatically constructs verifier-ready harnesses from a software project and a designated verification target. We combine the agent with formal soundness and precision guards to validate generated abstractions and guide their refinement. We evaluate the feasibility of our approach in an exploratory case study on curl and libuv, using three historical assertion violations already embedded in the source code as verification properties. Our results show that the agent successfully constructs proof harnesses that enable CBMC to detect all three violations. We further demonstrate the potential for reusing these harnesses with other verification tools.

Fri 16 OctSoftware Engineering
The gist
Checking if software works correctly often requires experts to create special test environments called proof harnesses, which take a lot of manual work. The authors developed an automated agent that builds these proof harnesses by analyzing a software project and its components. They tested this approach on real software and showed that the agent helped find three known bugs successfully. This method could save time and effort in making software more reliable by automating a tricky part of the verification process.
Open → 2610.23241v1

Transformer program inspection reveals hidden errors beyond token accuracy

What Accuracy Hides In Learned Transformer Programs

Abstract: Transformer Programs (TP) (Friedman et al., 2023) constrain a Transformer's architecture so that its learned computation can be extracted as readable Python code. TP expose learned computations, but token accuracy can hide incorrect complete answers. In this work, we examine how program inspection provides insights beyond accuracy scores and helps guide training. We first evaluated TP on nine algorithmic tasks. We compared token accuracy with accuracy on complete output sequences and checked for failures missed by sampled tests. Further, we assessed training data improvements informed by program inspection and failure analysis, finding gains in sequence accuracy on several tasks. We examined a counting task where a program achieved 100% accuracy on sampled test sequences but failed on another input using the symbols and lengths allowed during training. The program counted correctly, but the required answer was missing from its output labels. After adding training examples with larger counts, the retrained models passed exhaustive evaluation over the bounded domain. In the frequency ranking task, inspection showed how correct counts contributed to incorrect answers in programs trained before and after changes to the training data. Finally, we studied constraints imposed by TP training and operations. The TP training process can lead to accuracy losses late in training. Our reference constructions also show how composing the restricted TP operations can use many layers or large lookup tables.

Fri 16 OctMachine Learning
The gist
Transformer Programs are designed so their learned computations can be turned into readable Python code. The authors found that looking only at token accuracy can hide mistakes in full answers. They showed how carefully inspecting these programs reveals errors missed by standard tests, which helped improve training by adding targeted examples. Sometimes programs scored perfectly on sample tests but failed on other valid inputs, a problem uncovered only by thorough program inspection. This extra insight can help make transformer learning more reliable on algorithmic tasks.
Open → 2610.22891v1

AuditKIT unifies large language model and agent evaluation metrics

AuditKIT: A Unified Evaluation Spine for Benchmarking, Judging, and Comparing Large Language Models and Agentic Systems

Abstract: Evaluating language models and agents requires combining benchmark accuracy, judge-based assessment, runtime performance, tool-use behavior, and retrieval quality. Differences in interfaces, metric semantics, and trace formats complicate these comparisons and can hide failures in agentic workflows. We present AuditKIT, a source-available evaluation library that records these measurements in one result representation, with direction-aware metric contracts, configuration fingerprints, and extensible metrics and backends. For agents, it provides turn-aware tool-call matching, separates parallel from sequential execution, and distinguishes verified task outcomes from trajectory-level diagnostics. Missing or unobservable evidence is marked unscored rather than counted as failure. For retrieval-augmented generation, it combines ranked retrieval metrics, judged grounding, and deterministic evidence checks. Seven case studies spanning model comparison, serving runtimes, retrieval, tool calling, and interoperability show how answer extraction, runtime behavior, and metric selection change evaluation outcomes.

Thu 15 OctComputation and LanguageArtificial IntelligenceInformation Retrieval
The gist
Evaluating language models and AI agents is complicated because different tests measure different things in different ways, making it hard to compare results or find mistakes. The authors created AuditKIT, a tool that collects all evaluation details into one system that can handle different types of tests together. This tool can watch tools the AI uses, check if answers are correct, and handle uncertain or missing information carefully. They showed through examples that how metrics and runtimes are chosen can change evaluation results a lot.
Open → 2610.22511v1

Stateful testing exposes hidden bugs in deep learning compilers

Stateful Testing for Deep Learning Compilers

Abstract: Modern deep learning compilers compile models lazily and cache artifacts across invocations. Retained compiler state can make a later invocation incorrect even when it is correct in isolation. An analysis of 26 publicly reported issues in PyTorch, JAX, and TensorFlow shows that detecting such bugs requires sequences that first establish compiler state and then expose a failure. We present Rondo, a stateful testing method that represents each test case as a model paired with an invocation sequence. Rondo mutates invocation sequences and uses a Markov chain Monte Carlo sampler guided by compilation behavior to favor rarely observed behaviors. Its three-way differential oracle compares execution without compilation, compiled execution with compiler state reset, and compiled execution with state retained. It confirms stateful bugs by replaying the same invocation with state retained and reset while preserving inputs and program state, then shortens sequences while preserving the original bug. We evaluate Rondo on four deep learning frameworks using 24 common model architectures. Rondo detects 117 bugs, including 35 stateful bugs. We submit 39 bug reports, including 18 for stateful bugs; developers confirm 35 reports, including 16 for stateful bugs, and fix 18 bugs, including 11 stateful bugs. Rondo achieves the highest behavior coverage and compiler Python source-line coverage among the compared methods, with 99.26% alarm precision. It shortens 44 of 117 invocation sequences, reducing the lengths of these 44 sequences by 83.34% on average.

Thu 15 OctSoftware EngineeringMachine Learning
The gist
Deep learning compilers often keep some information between runs, which can cause errors that don't show up when you run things just once. The authors studied many such bugs in popular frameworks like PyTorch and TensorFlow and built a new tool called Rondo to find them. Rondo tests sequences of compiler runs that first set up the compiler state and then try to trigger a bug. It uses smart mutations and comparisons to find bugs related to compiler state and can shorten the test cases to make debugging easier. This method found and helped fix many real bugs in widely used systems.
Open → 2610.22003v1

GPT tool use shows retry permission errors separate from recovery success

RetryBench: Separating Retry Permission from Recovery Outcomes in GPT Tool Use

Abstract: False retry permission (FRP) occurs when an agent retries a timed-out tool call without support from the visible contract. RetryBench separates this error from realized recovery. Successful protected recovery does not imply reliable rejection of unsupported retries. In a 720-response key control, valid keys usually enabled safe progress, but offered changed keys elicited unsupported retries in Sol (1/80), Terra (55/80), and Luna (60/80). A later 240-response control removed the candidate and required models to supply a key. Luna still made 8/80 unsupported dispatches; Sol and Terra made none in 80 responses each. Accepting a displayed bad key therefore cannot explain all observed errors, although changed output requirements and conditions preclude a pure display-effect comparison. Removing the weak-contract label increased retries in Sol and Terra's coded-action conditions in a six-endpoint study. A separate 1,536-response canonical-action block also found a positive Terra contrast (115/128 versus 124/128 retries), concentrated in two task/order conditions; the other five contrasts remained unresolved after multiplicity correction. An explicit-contract cue control elicited deferral in all 762 returned responses, leaving recovery unresolved. These results support reporting permission and recovery together across declared interface variants. The evidence covers four purposive tasks, fixed GPT endpoints, and one recovery decision; it identifies neither internal mechanisms nor episode-level safety.

Sun 11 OctArtificial IntelligenceCryptography and Security
The gist
Sometimes GPT models try again to use a tool even when they shouldn't, causing errors. The authors show that successful recovery when a tool fails doesn’t mean the model knows when it’s allowed to retry. They tested different GPT versions with tasks involving keys and found some kept retrying without permission. This work helps understand how AI decides to retry actions and recover from failures.
Open → 2610.15884v1

Mobile gui agents improve task success by reusing parts of past actions

DeltaReplay: Task-Relative Memory Reuse for Mobile GUI Agents

Abstract: Memory-augmented mobile GUI agents store successful execution trajectories and reuse them in later tasks, but a stored trajectory rarely matches a new task exactly. The new task may use different parameters, share only some of its steps with a stored trajectory, or have no relevant record in memory. Forcing the agent to use irrelevant memory can mislead it, whereas discarding memory that may still be useful deprives it of guidance from past experience. To address this dilemma, we propose DeltaReplay, a step-level memory reuse framework that decides how to use existing memory without modifying it. We observe that the reusable part of a stored record is determined not by the record itself but by its relation to the new task, mainly through two factors: page-level consistency and action-level generality. We therefore store execution trajectories as paths in a transition graph, whose nodes (pages) and edges (actions between pages) capture these two factors. At reuse time, the action on each edge is split into a task-independent operation and task-specific parameters. DeltaReplay then compares each recorded step with the new task and the current screen, and decides whether to follow it, execute it after replacing its parameters, or leave it to the base agent. On AndroidWorld and SPA-Bench, DeltaReplay improves the task success rate over a base agent with the same backbone by up to 10.3 and 25.0 percentage points, respectively. These results indicate that deciding at each step how to use retrieved memory lets agents benefit even from partially matching trajectories.

Thu 8 OctArtificial Intelligence
The gist
Mobile apps comprise many actions on different screens, and software agents that help automate tasks learn from past tries. But old successful actions rarely match new tasks exactly, which can confuse the agent. The authors propose DeltaReplay, a system that breaks down tasks into steps and decides which parts of old experiences still apply by comparing screens and actions. This step-by-step reuse approach helps the agent accomplish new tasks more accurately, as shown in tests with Android apps and benchmark suites.
Open → 2610.11707v1

AppWorld and WorkArena verifiers fail to detect some wrong task results

Finding Blind Spots in AppWorld and WorkArena Task Verifiers

Abstract: Execution-based task verifiers decide whether an agent succeeded. We audit shipped AppWorld and WorkArena verifiers with source-informed mutation tests. The main audit never modifies a shipped checker. In AppWorld, duplicating a non-idempotent write creates an extra record while preserving every checked field value. The verifier accepts all three task variants from two of five eligible generators: 6/15 constructed effects. A cardinality patch applied to checker copies after the census makes all six cells fail while preserving valid controls. In WorkArena, we prospectively rerun 23 extra-field candidates selected for earlier checker-PASS outcomes. Independent Table API readback confirms nondefault persisted values in 21, while all 23 receive PASS. Two requested strings are aliases of stored defaults. The 21 confirmed wrong effects span three form templates. These selected cases confirm wrong effects under the audit's protocol; they do not estimate a population rate. No other construction produces an independently confirmed false accept. Other checker-PASS cases are effect-correct degeneracies. We report zero-PASS families separately because retained evidence differs. In fixed intent-swap grids, the checkers return no PASS on 2,689 off-diagonal executions. This is a rejection census: 57 WorkArena cells use session-scoped evidence; the other 2,632 lack classified rejection causes and independent target ground truth. Each increment is specified before its own cells are scored. A supplement accompanies the OpenReview submission with the construction grammar, evidence, content-bound stage lineage and count reproducer.

Tue 6 OctArtificial IntelligenceSoftware Engineering
The gist
Software that checks if tasks succeed can sometimes miss errors. The authors studied two such checkers used in popular apps, AppWorld and WorkArena, by carefully changing data and seeing if the checkers noticed. They found cases where wrong changes were accepted as correct, revealing blind spots. Their tests help reveal how reliable these checkers are and where they might need improvement.
Open → 2610.09142v1

Trust layer reveals many AI agent test results are unreliable

A Trust Layer for Agent Evaluation

Abstract: Deterministic benchmark scores show that an agent received credit, but not whether that credit was earned, reported honestly, or would hold on a second run. We introduce a Trust Layer for Agent Evaluation, an additive post-hoc framework that reports, beside each recorded score, whether it should be believed. It verifies four properties: whether the result is supported by the benchmark's own grading logic, whether a passing answer was earned through traceable computation, whether the agent's completion claim matches what occurred, and whether the result is stable under repeated execution. The first three use only saved artifacts; the fourth re-runs the agent. Model judgments only label evidence under majority voting; all verdicts follow deterministic rules and never modify the recorded score. Applied to five agent configurations on 108 tasks from Agents' Last Exam, every model shows passing runs with no traceable computation (at rates varying tenfold), confirmed false completion claims, and unstable results: 18-46% of tasks do not stay in one score band over five runs. Only 22.6% of recorded passes clear all four checks (95% CI 15.0-32.6, n=84). Measuring what an agent can do and verifying that it did it are different problems, and current benchmarks address only the first.

Mon 5 OctArtificial Intelligence
The gist
Many tests give AI agents scores without checking if they truly earned them or if scores are consistent. The authors introduce a trust layer that reviews each score to see if it really reflects what the AI did and if it would get the same score again. They found that a large portion of AI test passes might not be trustworthy or stable. This shows that current tests measure ability but don’t always confirm honest, repeatable performance.
Open → 2610.07274v1

LLM-agent security shows identical attack failure rates but different guarantees

The Same Zero: Why Identical ASR Can Imply Different Guarantees in LLM-Agent Security

Abstract: LLM-agent security has produced a dense landscape of defenses - prompt hardening, content filters, permission gates, sandboxes - yet no framework tells a deployer what a defense actually guarantees, or where that guarantee comes from. We apply Verification Autonomy Levels (VAL) - L0: LLM self-declaration; L1: deterministic rules; L2: objective ground truth; L3/L4: decidable completeness; L5: impossible - to 22 agent-security defenses; the taxonomy is falsifiable (10/10 prediction hits on frozen cards, flagged). We run the first controlled deployment-value comparison: at equal budget, a VAL-guided stack (confirmation gate + schema sandbox) versus a mainstream intuition stack (prompt hardening + keyword filter), 50 scenarios, 12 attack variants, adaptive/white-box/PAIR escalation (~7,000 testbed calls; ~10,000 harness calls on AgentDojo/JADE). The VAL stack holds 0.000 attack success at 1.000 benign success (0.5% ASR at 79.7% utility on AgentDojo banking vs 4.3% undefended); the intuition stack reaches 0.000 ASR but kills all benign actions - security by model-behavior luck, not structure. Across testbeds of rising attack-surface hardness the intuition stack's zero drifts (0->1.9%->6.2%, n=16 on JADE) while the VAL stack's holds within its ODD (0->0->0), its only breach a disclosed out-of-ODD password gap (0.5%). The same zero, two different guarantees: zero is an outcome, not a guarantee.

Sat 3 OctCryptography and SecurityComputation and Language
The gist
LLM-agent security uses different methods to protect AI assistants, but it’s unclear what each method really guarantees. The authors used a special classification system to compare 22 defenses and tested two defense setups in many attack scenarios. They found that two setups both stopped attacks, but only one kept helping normal users work efficiently. This shows that having zero attacks doesn’t always mean the same level of security, depending on the defense’s underlying guarantees.
Open → 2610.04504v1

Benchmark measures how well agents act like real users

AgentPersonaBench: Benchmarking Persona-Driven User Simulation

Abstract: We introduce AgentPersonaBench (APB), a benchmark evaluating whether persona conditioning faithfully steers downstream agent behavior. While language models are increasingly deployed for persona-driven user simulation, existing benchmarks primarily evaluate conversational styling or self-reports rather than authentic behavioral fidelity. APB evaluates latent persona adherence one trait at a time, embedding each target trait within a complete synthetic profile without explicitly naming the trait or disclosing the test. Ground-truth adherence is verified strictly from observable actions across four interaction surfaces of increasing realism: survey, chat, web (interactive web environments), and app (desktop software environments). APB comprises 2,460 tasks spanning 867 traits, verified through automated audits and expert review. Our evaluation of 20 frontier model arms demonstrates that high-fidelity user simulation is already attainable: leading models achieve up to 84.7% full-pass adherence under unprompted conditions. At the same time, APB identifies clear behavioral boundaries: adherence drops across interaction modalities (only 37.9-64.3% pass all four surfaces), multi-attribute demands degrade retention, and competing model families exhibit pronounced behavioral divergence.

Sat 3 OctArtificial Intelligence
The gist
Simulating realistic users for testing software is hard, especially when the user has a distinct personality or traits. The authors created a benchmark called AgentPersonaBench that tests if AI agents truly behave according to a specific trait, using realistic tasks across surveys, chats, websites, and apps. Their tests show some AI models can convincingly simulate these personas, but performance drops with more complex settings. This helps understand how well AI can mimic users with personality.
Open → 2610.04379v1

Improving test coverage reveals hidden flaws in agent verification suites

Discriminating Fixture Coverage in Agent-Infrastructure Verification Suites

Abstract: Invariant suites and runtime monitors increasingly gate agent deployment decisions, and the evidence offered for any particular suite is almost always a single observation: it passes an implementation believed correct and fails one believed broken. We measure what that observation is worth. Applying mutation analysis to an invariant suite for a multi-session agent state-projection layer, we first find that this standard validation certifies a suite in which a first-order mutant removing event-identity deduplication survives every check. We then freeze the repaired twelve-check suite, record its hash, and run it once against ten mutants specified by an adversarial reader who designed none of its fixtures: it kills five. Instrumenting the five survivors against the reference shows they fail in two distinct ways, not one. Three are never activated, because no fixture supplies an input on which the mutated code behaves differently at all. The other two corrupt internal state that no oracle in the suite can observe. The two modes need different repairs, and neither is visible from a pass/fail report. Treating the missing inputs as a coverage question, we enumerate seven discriminating dimensions of the input space, register in advance which are uncovered and which survivors they should explain, and add one fixture per uncovered dimension while reusing the existing oracles verbatim. All five survivors then die, each to the check written for its predicted dimension. We report this as a repair result on the same challenge set rather than a second held-out estimate, and give the artifact, including the frozen hash, the registered predictions, all mutants and the run logs, so the distinction is checkable.

Fri 2 OctSoftware EngineeringArtificial IntelligenceMachine Learning
The gist
Testing whether software works often involves checking if it passes certain tests and fails broken versions. The researchers show that just passing or failing these tests doesn't always catch all the problems. They found that some tests miss important cases where bugs hide because the test inputs don’t cover all possibilities. By adding new, carefully chosen test cases, they made the tests catch all hidden problems. This approach helps make software checking more thorough and reliable.
Open → 2610.02928v1

Evaluation metrics predict test effectiveness for combinatorial testing

An Extensive Empirical Study on Evaluation Metrics for Combinatorial Interaction Testing

Abstract: Combinatorial interaction testing (CIT) is a black-box testing method that has received extensive attention in both research and practice over recent years. Its primary objective is to construct an effective combinatorial test suite that detects software failures caused by parameter interactions. As a fundamental component of the CIT testing process, the evaluation metric plays a critical role in assessing and comparing combinatorial test suites, as well as in evaluating various test generation techniques. For CIT practitioners, selecting an appropriate evaluation metric is both important and challenging, given the wide variety of available options. Nevertheless, no prior work has systematically addressed this problem. To fill this gap, this paper first provides a comprehensive survey of black-box evaluation metrics for combinatorial test suites, offering rigorous definitions, clear classifications, illustrative examples, and complexity analyses. We then conduct an extensive empirical study involving eight open-source projects, encompassing 32 test scenarios and 295,624 combinatorial test suites. In this study, we examine the correlation between each static evaluation metric and fault-detection effectiveness using two correlation measures. Experimental results show that the Value Combination Coverage (VCC) metric serves as a valid predictor for test-suite evaluation. However, distribution-based metrics generally incur lower computational costs than interaction coverage-based ones. The choice of an appropriate metric should also account for the test suite's inherent properties, as these characteristics can substantially influence the effectiveness of the evaluation. Finally, we provide practical guidelines to assist CIT practitioners in selecting suitable evaluation metrics for assessing or comparing combinatorial test suites.

Thu 1 OctSoftware Engineering
The gist
Software testers use combinatorial interaction testing to find bugs caused by how different settings interact. But choosing the best way to measure the quality of these test sets is tricky because many options exist. The authors studied many such measurement methods across real software projects and found that some metrics predict bug finding better than others. They also show that some metrics are cheaper to calculate and that test set features affect these metrics' usefulness. They offer practical advice to help testers pick the right measurement for their needs.
Open → 2610.02560v1

Meta agent training challenges revealed by task and verifier issues

When Terminal-Agent Training Stalls: Demystifying Data Generation and Verification Challenge

Abstract: Using a frontier model like Claude Opus as a meta-agent to generate terminal tasks and verifiers for RL training is increasingly common. Yet a runnable Docker image and executable test suite do not guarantee a faithful end-to-end pipeline for terminal agent training. We present a meta-agent pipeline motivated by this gap, diagnosing three classes of failure: benchmark invalidity, harness brittleness, and reward misalignment. Prompt redesign and context extension raise baseline solvability 5.6 times, but a 9B model saturates at 81.3% mean pass@2 within 20 steps on Claude Opus-generated tasks. Adding hard tasks reduces mean pass@2 to 20.6% without changing the training configuration, a strong evidence that the solvability band is model-specific. These findings demonstrate that meta-agent reliability requires solvability-band calibration, verifier audits, and infrastructure error accounting as first-class evaluation criteria, not post-hoc diagnost.

Thu 1 OctArtificial Intelligence
The gist
Training AI agents to solve tasks end-to-end can run into hidden problems. The authors found that just having a runnable setup does not ensure everything works smoothly. They identified three main problems: invalid benchmarks, fragile testing setups, and misaligned rewards. By improving prompts and context, they made tasks easier to solve, but the difficulty depends on the AI model’s capability. The study shows that careful checks and evaluations are needed throughout training to avoid hidden errors.
Open → 2610.02405v1

Gui agents improve themselves by optimizing task control harness

GUI-HARVEST: Self-Improving GUI Agents through Evidence-Driven Harness Evolution

Abstract: The executable harness surrounding a GUI model determines how observations are assembled, actions are executed, and verification, recovery, and termination are controlled. Compared with harness optimization for non-GUI agents, automatically optimizing this harness poses three coupled challenges: reconciling model intent with observed visual effects, diagnosing failures under variable execution outcomes, and identifying recurrent failure patterns across tasks and translating them into reusable runtime changes. We introduce GUI-HARVEST, an automatic harness optimizer that enables self-improving GUI agents with frozen backbone models. First, to ground diagnosis in observed action effects, it aligns model outputs and executed actions with before-and-after screenshots, tying findings to specific interface transitions. Second, to account for execution variability, it treats repeated runs of the same task as a joint evidence unit, using within-task comparisons to locate outcome-relevant behavioral differences. Third, it consolidates verified findings across tasks into recurring failure patterns, maps them to bounded source-code edits with predictions recorded before evaluation, and checks the predicted behavioral effects alongside task performance through repeated execution. Experiments on OSWorld-Verified show consistent held-out gains across six general-purpose open, GUI-specialized open, and proprietary backbone models; Qwen3-VL-32B-Instruct gains 12.33 points on the full suite. Frozen-harness transfer improves GPT-5 by 13.87 percentage points on WindowsAgentArena at 50 steps without further optimization. With the same backbone and initial harness, GUI-HARVEST outperforms Self-Harness and Meta-Harness, suggesting that GUI-specific diagnosis and validation help harness improvements generalize to unseen tasks. The code is available at https://github.com/GaryYang12345/GUI-HARVEST.

Thu 1 OctMachine LearningArtificial Intelligence
The gist
Automated agents that interact with computer interfaces sometimes fail because the way their tasks are set up doesn’t perfectly match what they see on the screen or how the interface behaves. The authors present GUI-HARVEST, a system that helps these agents fix themselves by analyzing screenshots before and after actions, spotting where things go wrong repeatedly, and making practical changes to how tasks are controlled. This approach lets agents get better at completing tasks without changing the underlying AI model. Tests showed it improved performance across various AI models and task types.
Open → 2610.00948v1

Testing correctness of structured parentheses requires many queries

Query Complexity of Testing Structured Parenthesis Languages

Abstract: We study the query complexity of testing membership in structured string languages, focusing on Dyck languages and natural generalizations. A tester receives query access to a word and must distinguish valid inputs from words that are far in Hamming distance, while inspecting only a sublinear number of positions. Our results sharpen the boundary between constant-query testability and polynomial query complexity. First, we prove an $Ω(n^{2/5})$ lower bound for testing Dyck languages $D_m$ with any fixed number $m\ge2$ of parenthesis types, improving the previous $Ω(n^{1/5})$ lower bound of Fischer, Magniez, and Starikovskaya (SODA `18) and nearly matching their upper bound of $O(n^{2/5+o(1)})$. Furthermore, we show that all nonadaptive algorithms for these problems require $Ω(n^{1/2})$ queries. Our lower bounds use a Pólya-urn process to construct the hard distribution; Second, we identify a broad class of weighted-parenthesis languages, which we call {\em excursion languages,} that remain constant-query testable. These languages encode bounded-step walks that stay nonnegative and return to zero. For every fixed excursion language, we give a nonadaptive tester with query complexity $O(1/\varepsilon^2)$, and we prove this dependence on $\varepsilon$ is optimal, even for adaptive algorithms. As a special case, we obtain the tight $Θ(1/\varepsilon^2)$ query complexity of testing $D_1$, improving the previous $O(\log(1/\varepsilon)/\varepsilon^2)$ upper bound and giving the first matching two-sided-error lower bound. Third, we construct a simple hard language, Hidden String, that is generated by a deterministic linear grammar but nevertheless requires $Ω(n^{2/5})$ adaptive queries and $Ω(n^{1/2})$ nonadaptive queries to test. This shows that polynomial query complexity appears even for highly restricted string languages.

Tue 29 SeptData Structures and AlgorithmsComputational Complexity
The gist
This paper studies how hard it is to check if a string of parentheses is correctly matched by inspecting only parts of it. The authors find that for complex cases with multiple types of parentheses, any test must look at a substantial portion of the string to be reliable, but for simpler, well-structured cases, quick tests are possible. They improve previous understanding of which structured languages need many checks and which don't. They also identify a special kind of language that, despite being simple, still resists fast testing.
Open → 2609.37431v1

Agent benchmarks often misjudge actions due to tool defects and assumptions

Do Agent Benchmarks Do What They Say? An Executable-Contract Audit of Tool-Using Agent Environments

Abstract: Tool-using agents are entering settings where a wrong action carries real cost, and the benchmarks certifying them grade what each simulated tool call reports having done, assuming the tool did what its interface advertises. The audit taxonomies we survey publish no category for that assumption, and a defect beneath a score is present on every rerun. We treat a tool's advertised surfaces as an executable contract, check the implementation against it, and trace each score's provenance through the task files and evaluator code to the verdicts that derive from state a defective tool should have written. Across 34 audited mutating tools in four benchmarks we confirm seven tool defects and one evaluator property at pinned commits. On injected defects the checker raised no false positive in 25 flags, flagged 2 of 5 negative controls, and missed most: in 29 of 33 scored misses a clause covered the defect but no probe revealed it. The checker's own static half, run alone, flags 14 of 17 confirmed sites, so on these findings the dynamic half confirms and traces rather than discovers. Twelve further AgentDojo tools, with six held-out tools and the seven audited first, complete its 25-tool mutating surface, on which at least 5 tools diverge from their advertised surface as our contracts read it, a rate for AgentDojo alone. No gold trajectory reaches either tau2-bench defect; on 1,120 paths built to isolate the telecom defect, a number fixed by construction, the evaluator rewards a refuel of a suspended line and fails the repaired tool. The clearest case is a clinical benchmark whose tool tells the agent each write executed under a documented no-write design its interface does not disclose; its grader takes that message as evidence, so its action success rate records whether a request carried the expected payload, not whether any record changed.

Tue 29 SeptSoftware EngineeringArtificial IntelligenceMachine Learning
The gist
Benchmarks that test AI agents using tools usually trust that these tools work exactly as advertised, but this paper finds that many tools have hidden defects that benchmarks don't catch. The authors checked whether the tools actually do what they claim by treating tool interfaces like contracts and tracing how benchmark scores depend on tool behaviors. They found several real tool flaws and cases where benchmarks gave misleading scores because they trusted incorrect messages from tools. This shows that current benchmarks may not reliably measure how well tool-using agents perform in real tasks.
Open → 2609.37315v1

Near optimal limits found for testing balanced parentheses and string equality

Near-Optimal Bounds for Testing Residual-String Equality and Parenthesis Languages

Abstract: Residual-String Equality, denoted $\texttt{ResStringEq}$, is the property consisting of all pairs of strings over $\{0,1,*\}$ that are equal after deleting all `$*$' symbols from them. This property was first introduced by Fischer, Magniez, and Starikovskaya (SODA 2018), who used it to show a lower bound on testing the $\texttt{Dyck}$ languages, where $\texttt{Dyck}_m$ is the language consisting of balanced sequences of parentheses over $m$ parenthesis types. They showed that testing $\texttt{ResStringEq}$ on inputs of length $n$ requires $Ω(n^{1/5})$ queries, and presented a reduction from testing $\texttt{ResStringEq}$ to testing $\texttt{Dyck}_m$ where $m \geq 2$. Furthermore, they showed that $\texttt{Dyck}_m$ can be tested with $O(n^{2/5+δ})$ queries for every constant proximity parameter, where $δ>0$ is an arbitrarily small constant. In this work, we nearly close the remaining gap, by showing that testing $\texttt{ResStringEq}$, and hence $\texttt{Dyck}_m$ where $m\geq 2$, requires $Ω(n^{2/5})$ queries. We also show a stronger lower bound of $Ω(\sqrt{n})$ for testers that make non-adaptive queries. We establish that the $Ω(\sqrt{n})$ bound is nearly tight, by presenting a non-adaptive tester for $\texttt{ResStringEq}$ that uses $O(n^{1/2+δ})$ queries for an arbitrarily small constant $δ>0$. Furthermore, we extend this non-adaptive tester to the $\texttt{Dyck}$ languages, with the same query complexity. Finally, we improve the dependence on the proximity parameter $ε$ in the tester of Fischer, Magniez, and Starikovskaya, reducing it from $O(1/ε)^{\mathrm{poly}(1/δ)}$ to $O(1/ε)^{O(\log(1/δ))}$.

Mon 28 SeptData Structures and Algorithms
The gist
The paper studies how hard it is to check if two special strings match when ignoring certain placeholder symbols, and if a sequence of parentheses is properly balanced. The authors sharpen previous estimates, showing nearly exact boundaries on the number of checks needed to test these properties efficiently. They also provide better methods for testing these conditions without changing their strategy based on earlier answers, improving speed and precision. Additionally, they reduce the complexity of how the testing depends on how close an input must be to being correct.
Open → 2609.35746v1

WebPageBench verifies web agents by matching event logs across UI variants

WebPageBench: Event-Level Verification and Controlled UI-Variant Generation for Web Agents

Abstract: We present WebPageBench, an open framework for evaluating web agents in which every task is verified from the interface's own event log. Six instrumented mock sites with brand identifiers removed (a marketplace, a bookstore, a grocery service, rail ticketing, hotel search and a document cabinet) emit typed events with parameters as a user or an agent acts. A task declares the events it requires, and success is decided by matching them, with no judge model and no scraping of rendered pages. The same instrumentation supports controlled UI variation: one configuration switch re-renders a task through a different implementation of a single control while the prompt and the success conditions stay completely identical, so sensitivity to interface form can be measured under a fixed task specification. The WebPageBench release consists of three components: 152 tasks, divided into 65 canonical scenarios and 87 control variants across light/dark UI-modes; a common runner evaluated with six browser/DOM harness configurations and five screenshot-only GUI-agent families; and a public leaderboard of 24 model-harness pairs. On the public 152-task leaderboard the gap between what agents declare finished and what the log confirms reaches 41 points (one configuration declares every task finished and satisfies the conditions on 59%).

Mon 28 SeptArtificial IntelligenceComputation and Language
The gist
Many computer programs called web agents act on websites to do tasks, but testing if they really succeed is hard. The researchers built WebPageBench, a tool that tracks every action on test websites by logging the exact events triggered during the task. This helps check if agents truly complete tasks without just scraping pages. WebPageBench can also switch website controls’ designs to see how changes affect agent performance without changing the task itself.
Open → 2609.35026v1

Benchy creates a universal language to benchmark AI tasks easily

Benchy: towards a universal language for task-oriented AI benchmarks

Abstract: Benchy is a semantic language and execution engine for benchmarking AI programs. A benchmark is completely specified by a program, a scoring function, and a dataset, B=(P,S,D), and is separate from the AI-system taking it; a run binds the two, R=(B,AI). Benchmarks are authored as canonical YAML in which each semantic concept has one valid syntax, classified by a shared task/domain/language ontology, and deterministically compiled into a canonical JSON intermediate representation that the engine executes. Compilation changes representation, not meaning: it does not repair invalid definitions or inject hidden defaults. Programs use fixed schemas of named input and output fields, the leaf output fields are the scoring dimensions, and the engine exposes one universal runtime contract --- a named-field input object in, a named-field output object out --- to which external AI-systems adapt at the boundary, so integration mechanics never propagate into benchmark semantics. This paper gives the semantic object model, the ontology and task-to-program validation rule, the scoring and failure semantics, the compilation and execution architecture, and the scope of the current language. An appendix fixes the normative engineering contract for the first engine implementation.

Thu 24 SeptArtificial Intelligence
The gist
Benchy is a new way to describe and run tests that check how well AI programs work on specific tasks. It uses a simple and clear language that is the same no matter who writes the test or what AI system takes it. The language is written in a neat file format and then turned into a standard code form that a special engine understands to run the test. This setup keeps the test descriptions separate from the AI systems, making it easier to compare different AI fairly and consistently.
Open → 2609.30550v1

Requirement smells reduce correctness in AI-generated code

On the Impact of Requirement Smells in LLM-Based Code Generation

Abstract: Software requirements are typically incorporated into prompts used in LLM-assisted software development. Recent work has shown that requirement smells can affect automated traceability between requirements and code, but empirical evidence on their effects in code generation remains limited. To address this gap, we build upon a prior study on automated traceability by reusing its dataset and requirement smell taxonomy, while extending it to evaluate the functional correctness of LLM-generated code. Using a benchmark consisting of requirements and corresponding system tests for four applications, we progressively introduced semantic, syntactic, and lexical smells into otherwise clear requirements and analyzed their influence on generated implementations. Our results suggest that increasing \textit{smell density} was generally associated with lower test-suite-based functional correctness, although non-smelly requirements could still produce faulty code. We also found that different smell categories had similar effects. These findings provide additional empirical evidence of the importance of requirement quality in LLM-assisted code generation, while showing that high-quality requirements alone do not guarantee correctness, as these depends on several factors, including the LLM. Compared with previous work, our results suggest that the impact of requirement smells depends on the software engineering task: whereas their effects on traceability were modest, code generation appears more sensitive. Overall, this work motivates further investigation into task-dependent quality effects in LLM-assisted software engineering.

Thu 24 SeptSoftware Engineering
The gist
Poorly written software requirements can confuse AI code generators, leading to more bugs in the code they produce. The authors studied how different types of unclear language, called "requirement smells," affect the accuracy of AI-generated programs by testing various applications. They found that as the number of these smells increased, the generated code was more likely to fail tests. However, even clear requirements sometimes produced faulty code, showing that many factors influence AI coding quality. The study highlights that while good requirements help, they don’t guarantee perfect AI-generated software.
Open → 2609.29208v1

Verified algorithm design supports intent-based transport network control

From Intents to Algorithms: Verified Algorithm Discovery for Transport Networks

Abstract: Intent-based networking decouples desired outcomes from device-level configuration, but most systems still map intents to parameters of an algorithm selected in advance. Large language models (LLMs) create an opportunity to automate algorithm design, yet unrestricted generated code is unsuitable for transport-network control because feasibility, reproducibility, and robustness must be enforced independently of the model. We present VERA-TN, a verification-guided framework that compiles a network intent into a bounded algorithm-design specification. The target architecture uses an LLM as a semantic variation operator over typed request-ordering and path-ranking programs; generated logic remains separated from a trusted allocator that enforces path validity, latency, capacity, and single-path constraints. We prove feasibility preservation under explicit assumptions and establish a sufficient bound for the lexicographic latency tie-break in the exact reference model. The released proof-of-concept instantiates the same interface with a bounded ten-parameter numerical candidate and deterministic replay, rather than a completed live-LLM/AST study. Across 150 certified held-out cases on a 28-node TEFNET24-derived hierarchy, evolutionary search reaches a mean priority-utility ratio of 0.958, compared with 0.952 for equal-budget random search and 0.940 for priority-greedy routing. The gain over random search is small but statistically detectable (Holm- adjusted p = 0.0083). The candidate does not improve congestion relative to MILP-C, and the effect of failure-aware training is inconclusive at the 0.05 level (p = 0.051). Eight discovery runs on the official national topology and replay on 12 unseen metro-regional topologies show no stable intent-specific specialization. These results support the trust-boundary and numerical-evolution claims but do not establish a benefit from LLM generation.

Wed 23 SeptNetworking and Internet ArchitectureMultiagent Systems
The gist
Networks need to be set up so traffic flows efficiently, but making software that chooses the best way can be tricky and must be reliable. The authors created a system that uses rules and a small trusted program to check algorithms that decide how to route traffic, instead of relying only on AI-generated code, which can be unpredictable. They tested their approach on realistic network setups and found that their method can reliably produce good routing algorithms, though it didn’t show clear improvement from using AI to create the code. This work helps ensure network algorithms meet strict requirements for correctness and safety.
Open → 2609.27386v1

Computing minimal observation sets for exact governance decisions

Compiling Sufficient Governance Context from Declared Losses and Reachable States: Exact Observation-Contract Synthesis with Cardinality and Cost Objectives

Abstract: We call the object this paper derives and certifies a minimal sufficient governance context: given a finite reachable-state model, a deterministic declared verdict, and candidate observable attributes, we compute sufficient observation sets, distinguish attributes that are individually indispensable from contracts that are jointly sufficient, and select among sufficient contracts under a cardinality or declared-cost objective. An observation contract is a set of candidate attributes whose values determine the declared verdict on every reachable state; an authority contract is one selected under an objective and bound to a gate schema. We synthesize every inclusion-minimal sufficient contract where exhaustive enumeration is affordable, and a minimum-cardinality or minimum-cost contract by SAT/MaxSAT encoding otherwise, checking sufficiency directly. On a constructed code/cloud domain, the individually-indispensable core is not sufficient as an observation contract and two distinct reducts exist; a preregistered cost model separates them exactly. On a second, larger, constructed domain, the same pattern recurs, but that domain's cost model does not separate the alternatives: a fully explained cost tie, reported as found. We measure discernibility-family scaling where exhaustive enumeration is confirmed infeasible within a registered timeout, while SAT/MaxSAT synthesis solves in well under a second; MaxSAT showed no measured cardinality advantage over plain SAT. AuthorityBench compares four baselines across three domains; the declared-only baseline is not exactly sufficient on any. Every selected contract is checked for sufficiency, with a counterexample on failure and a check summary, not a portable certificate, on success -- the compiler-focused scope of a two-scope table; an independently specified end-to-end case study is registered follow-up work, not claimed here.

Tue 22 SeptSoftware EngineeringArtificial IntelligenceLogic in Computer Science
The gist
Some computer systems need to decide if certain rules are followed by looking at specific signals or data points, but not all data is useful or needed for making those decisions. This paper shows how to find the smallest and most cost-effective sets of observations that still allow the system to know the correct verdict on every possible state. The authors use logical methods to confirm which observations are essential alone and which groups work together to make decisions. Their method helps choose the best sets based on size or cost, tested on example scenarios where their approach quickly finds solutions.
Open → 2609.26016v1

Diversity guided testing finds more varied failures in large language model apps

Diversity-Guided Search-Based Testing of Large Language Model Applications

Abstract: Large Language Model (LLM)-based applications are increasingly deployed across domains including customer service, education, and mobility. These systems are prone to inaccurate, fictitious, or harmful responses, and their vast, high-dimensional input space makes systematic testing particularly challenging. In this paper, we present a search-based testing framework for LLM-based applications that incorporates failure diversity as an explicit optimization objective. Building on a discretization along stylistic, content-related, and perturbation dimensions, our framework maintains an archive of generated tests and rewards distance from that archive, while a repopulation operator periodically replaces non-failing tests in the population to sustain exploration. The repopulation operator is parameterized by its sampling strategy: replacement candidates are drawn either uniformly or by greedy distance maximization, two settings we compare empirically. We evaluate both against several baselines across three case studies---LLM safety, in-car navigation, and in-vehicle function control---covering five systems under test, eight LLMs, and 18 distinct test configurations, with over one million executed tests. Our results show that all guided variants detect substantially more failures than random and combinatorial search in nearly all configurations. Among them, diversified search detects fewer failures, but covers a broader range of failure types in all case studies, with greedy repopulation offering the best tradeoff.

Sat 19 SeptSoftware Engineering
The gist
Large language model applications, like chatbots and voice assistants, can give wrong or harmful replies and are hard to test due to many possible inputs. The authors created a testing method that tries different kinds of inputs while aiming to find many different kinds of errors. Their method keeps track of previous tests and focuses on exploring new input types, sometimes picking very different inputs to find new problems. Testing this on different apps and language models showed it finds more errors and a wider variety of problem types than random testing. They found a balanced strategy worked best to both find more errors and keep diversity in test cases.
Open → 2609.23209v1

PetriBench tests large language models on complex changing systems

PetriBench: Benchmarking LLM Reasoning over Dynamic State Spaces

Abstract: Characterizing LLM reasoning remains an open challenge, as many existing benchmarks isolate specific reasoning skills, rely on external knowledge, or are costly to extend. We introduce PetriBench, a compact, fully self-contained, and scalable benchmark for evaluating LLM reasoning over dynamic state spaces using Petri nets, a mature formalism for modeling real-world concurrent and distributed systems. PetriBench organizes reasoning into four task families varying by scope and temporal horizon, with Easy, Medium, and Hard levels generated by increasing structural complexity and evaluated against exact ground truth. Across a diverse set of proprietary and open-weight models, accuracy decreases consistently with difficulty, while harder instances expose increasingly distinct task-specific capability profiles. Additional analyses show that test-time compute improves performance but interacts differently with different reasoning tasks, and that procedural generation yields smooth scaling with structural complexity. Together, these results show that PetriBench provides a unified and extensible setting for probing the strengths, limits, and scaling behavior of LLM reasoning.

Thu 17 SeptComputation and LanguageArtificial IntelligenceLogic in Computer Science
The gist
Understanding how large language models (LLMs) reason through problems that involve changing situations is still hard. This paper introduces PetriBench, which uses a formal way to describe complex, changing systems called Petri nets to test LLM reasoning. The benchmark includes problems that vary in difficulty and length, with clear correct answers for evaluation. The researchers tested several LLMs and found that performance dropped as problems got harder, revealing different strengths depending on the task. They also discovered that more computing power at test time can help, but its effect changes with different problem types.
Open → 2609.19883v1

Frontier ai models differ in seeking safety evidence before acting

Do Frontier Models Seek Safety Evidence Before Acting?

Abstract: Frontier models are often evaluated on how they respond to safety information once it is already in context. We study an earlier decision point: whether models choose to acquire safety-relevant evidence before acting. We introduce SAFE, a controlled benchmark in which models make deployment decisions with optional evidence that varies in retrieval cost, probability, severity, and presentation. Across GPT-5.5, o3, Claude Opus 4.8, and Claude Sonnet 4.6, we find distinct evidence-acquisition policies: Opus inspects nearly by default, o3 is the most skip-heavy and threshold-sensitive, and GPT-5.5 and Sonnet occupy intermediate regimes. Inspection increases strongly with severity and decreases with retrieval cost, whereas probability has much weaker behavioral influence: increasing the stated likelihood of a problem from 10% to 70% changes inspection by at most 21 percentage points. Despite these differences, Stage 1 rationales are dominated by expected-value reasoning across models. A cost-obligation decomposition further shows that avoidance is driven primarily by retrieval friction and explicit threats to the deployment payoff rather than by the remediation duties created by knowing. Counterfactual interventions reveal a further mismatch between behavior and explanation: evidence framing can strongly change decisions near the inspection boundary while going largely unmentioned, whereas probability is frequently cited despite having little causal influence. These results suggest that deployment-time safety depends not only on how models respond to known risks, but also on whether they acquire the evidence needed to know that acting is safe.

Tue 15 SeptArtificial Intelligence
The gist
This paper looks at whether advanced AI models check for safety information before making decisions, rather than only responding to it once it is given. The researchers created a test where AI models decide to get extra safety evidence that varies in cost and severity before acting. They found that some models often check safety facts, some rarely do, and most fall in between. The models tended to avoid risky actions mainly because checking for evidence is costly, not because they are strongly influenced by how likely a problem is. This shows that AI safety depends not only on how models react to known risks but also on whether they choose to find out about those risks first.
Open → 2609.17865v1

Random graphs show sharp tipping point for adaptable 2-color edge patterns

On the Critical Window for Adaptable 2-Colorability

Abstract: We determine a sharp threshold for the adaptable 2-colorability of a random graph equipped with a uniformly random, not necessarily proper, red/blue coloring of the edges. To accomplish this, we characterize a family of subgraphs along with edge colorings whose inclusion or exclusion determines adaptable $2$-colorability. We further show that above the threshold, a long path with alternating edge colors is formed. We use this path to prove the existence of such a subgraph in the supercritical regime. We then provide and prove symmetric bounds on the critical window for $2$-adaptable colorability. Particularly, we prove bounds matching that of the critical windows for the giant component in the Erd$ő$s-R$é$nyi random graph model as well as the satisfiability of a random $2$-SAT instance. Finally, we show that below the critical window, the solution space of adaptable $2$-colorings remains connected, that is one can travel from one adaptable $2$-coloring to another by a sequence of $2$-colorings which differ on $O(\log{n})$ many vertices.

Thu 10 SeptDiscrete Mathematics
The gist
The paper studies when a network with edges colored red or blue can be recolored to avoid conflicts in a special way called adaptable 2-colorability. The authors find a precise tipping point where this property suddenly becomes likely in random graphs. They also identify key subgraphs and color patterns that determine if such recoloring is possible. Below this tipping point, all solutions are connected in a simple way, and above it, certain long alternating color paths appear.
Open → 2609.12214v1

Input metrics compared and improved for better software testing

An analysis of the relationship of input metrics

Abstract: Input metrics evaluate the progress of testing in terms of features of inputs present in a test suite. Previous works, as early as the 1950s, established a number of such metrics, but few endeavored to compare them. This paper does so by utilizing existing methods proposed for other metric classes in partition testing literature. After defining and reviewing common input metrics, we begin with a short case study revealing that typical empirical comparison strategies are fundamentally insufficient for comparing metrics. Then, we demonstrate how one rigorously improves a standard metric by defining and implementing $k$-alt-path, a new metric which reduces redundancy while improving sensitivity over $k$-path. Each of the other common input metrics are then systematically compared before discussing the implications of our findings. With these contributions, we bring forward partition testing analysis methods that justify and form a strategy for future research in refining input metrics.

Thu 10 SeptSoftware EngineeringFormal Languages and Automata Theory
The gist
Software testers use input metrics to measure how well their tests cover different input features. This paper looks at many of these metrics and finds that common ways to compare them don't work well. The authors create a better metric called k-alt-path that reduces overlap and detects differences more effectively. They then compare other input metrics systematically and suggest ways to improve future testing measures.
Open → 2609.11824v1

JarvisGUI enables coordinated workflows across multiple devices

JarvisGUI: Towards Cross-Device GUI Agents with Dynamic Task Composition

Abstract: Real-world GUI usage frequently involves workflows that span multiple devices and platforms, requiring the transfer of intermediate results, maintenance of shared state, and coordination across heterogeneous environments. However, existing GUI benchmarks overwhelmingly evaluate agents on single-device, statically defined tasks, thus leaving such cross-device capabilities largely unexamined, resulting in an overly optimistic assessment of agents' readiness for real-world usage. We introduce JarvisGUI, a dynamic benchmark that evaluates GUI agents on cross-device workflows requiring coordinated interaction across heterogeneous platforms, including Android, Windows, and Ubuntu. Specifically, JarvisGUI formulates GUI tasks as input-output transformations under a lightweight type system, which allows us to automatically compose multi-step, cross-device workflows and dynamically evaluate agent performance within a unified framework. By evaluating agents in virtual environments spanning multiple operating systems, JarvisGUI reveals that state-of-the-art open-source GUI agents struggle with the state-transfer awareness, cross-platform contextual reasoning, and long-horizon dependency management required for real-world workflows, exposing a critical capability gap invisible to existing benchmarks.

Wed 9 SeptArtificial Intelligence
The gist
Many tasks people do on computers involve working across different devices like phones, laptops, and desktops, but most testing for computer helpers only looks at one device at a time. The authors created JarvisGUI, a system that tests how well these helpers can work across several devices and operating systems by combining tasks in new ways. They found that current helpers struggle with remembering what happened on one device when moving to another and managing complicated, multi-step tasks. This shows that these helpers need to improve before they can help with real-world multi-device workflows.
Open → 2609.10451v1