History-Aware Verifier (HAVE)

Updated 9 July 2026

HAVE is a generator–verifier framework that resolves ambiguity in robotic manipulation by utilizing historical interaction data.
It employs a diffusion-based generator to propose diverse actions and a history-aware verifier to rank candidates using past outcomes.
Empirical evaluations show significant improvements on articulated objects, multi-modal doors, and uneven object lifting over baseline methods.

Searching arXiv for recent and directly relevant papers on “History-Aware VErifier (HAVE)” and closely related history-aware verification frameworks. History-Aware VErifier (HAVE) most directly denotes a generator–verifier framework for robotic manipulation under partial observability, introduced to disambiguate uncertain scenarios online by leveraging past interactions. It addresses settings in which the correct action cannot be inferred from a single visual observation and only becomes clear after physical interaction, such as multi-modal doors, articulated objects, and uneven object pick-up. HAVE explicitly separates action generation from action verification: an unconditional diffusion-based generator proposes multiple candidate actions from the current observation, and a history-aware verifier ranks those candidates by reasoning over prior actions and their outcomes (Li et al., 29 Aug 2025).

1. Conceptual basis and problem class

HAVE is designed for ambiguous manipulation problems in which ambiguity is interaction-resolved rather than observation-resolved. The central examples are doors that look identical but require pushing rather than pulling, doors with four opening modes—push-left, push-right, pull-left, pull-right—and objects with hidden mass distributions whose correct lift point is only partially revealed by previous failed or tilted lifts. In these settings, the current observation alone is insufficient; the disambiguating signal lies in the sequence of prior actions and observed consequences (Li et al., 29 Aug 2025).

The formal setting is a partially observable Markov decision process in which the transition function itself is drawn from a distribution:

$\mathcal{T}: \mathcal{S} \times \mathcal{A} \to \Delta(\mathcal{S}), \qquad \mathcal{T} \sim \mathcal{P}_{\mathcal{T}}.$

This formulation is used to model object families whose members are visually similar but behave differently. At time $t$ , decision making is conditioned not only on the current observation $o_t$ , but on the full interaction history

$(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$

A key motivation of the method is that simply conditioning a generative policy on history is not sufficient in practice. The paper argues that although a sufficiently strong history-conditioned generator could theoretically adapt online, history-conditioned diffusion policies remain suboptimal in ambiguous multimodal settings, especially when identical observations can correspond to multiple correct action modes under different hidden dynamics (Li et al., 29 Aug 2025).

This leads to the method’s core decomposition. Generation is responsible for preserving multimodality and proposing diverse plausible actions. Verification is responsible for deciding which action is most promising for the current object instance given the accumulated evidence from prior interactions. The paper frames this as a response to the “generation-verification gap”: when targets are heterogeneous for the same input, direct supervised generation is statistically less efficient than verification-based selection (Li et al., 29 Aug 2025).

2. Generator–verifier architecture

HAVE contains two learned components: an unconditional diffusion-based action generator $G_\phi$ , conditioned only on the current observation, and a history-aware verifier $V_\theta$ , conditioned on the current observation together with prior actions and outcomes. At inference time, the generator samples

$a_t^{(0)}, \dots, a_t^{(N-1)} \sim G_\phi(o_t),$

the verifier assigns scores

$s_t^{(0)}, \dots, s_t^{(N-1)},$

and the executed action is selected by

$\hat{i} = \arg\max_i s_t^{(i)}.$

The method is therefore an online reranking mechanism rather than a one-shot policy (Li et al., 29 Aug 2025).

For articulated manipulation, the generator follows a FlowBotHD-style architecture built from a PointNet++ encoder and a Diffusion Transformer denoiser. The appendix specifies point cloud size $N = 1200$ , embedding dimension $t$ 0, DiT depth $t$ 1, hidden size $t$ 2, heads $t$ 3, AdamW optimization, learning rate $t$ 4, weight decay $t$ 5, batch size 32, and 400 epochs. The generator predicts 3D articulation flow and converts it to an executable action by taking the point of largest-magnitude flow as the action point and its flow direction as the action direction (Li et al., 29 Aug 2025).

The verifier represents history as action–result triples

$t$ 6

Candidate and historical actions are embedded by an action encoder,

$t$ 7

while observation transitions are encoded by

$t$ 8

After separate transformer processing of action embeddings and observation-result embeddings, the verifier uses an explicit dot-product attention mechanism between the candidate action and historical actions:

$t$ 9

where $o_t$ 0, $o_t$ 1, $o_t$ 2, and $o_t$ 3 is an unconditional fallback branch. The final scalar score is produced by

$o_t$ 4

The intended function of this design is explicit retrieval of outcomes from prior similar actions, with the unconditional branch serving when no relevant historical analogue exists (Li et al., 29 Aug 2025).

A distinctive representation choice is the dense action field. Given point cloud $o_t$ 5, action contact point $o_t$ 6, direction $o_t$ 7, and constant $o_t$ 8, each point is augmented with

$o_t$ 9

The paper argues that this dense, spatially smooth representation is easier to process than sparse action tokens, and ablations support that claim (Li et al., 29 Aug 2025).

3. Training procedure and theoretical analysis

The generator and verifier are trained separately. Verifier training is simulation-heavy and offline. For each object, the data pipeline generates 200 history trajectories per object, with history lengths from 1 to 30 for articulated objects and from 1 to 10 for uneven pick-up. Each trajectory includes 10 random actions, ground-truth actions, and transformed history actions. Proposal sets contain the ground-truth action, random actions, and history actions transformed into the current state; each proposal is simulated to obtain reward labels. The verifier is trained for 50 epochs or early stopping with AdamW at learning rate $(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 0 (Li et al., 29 Aug 2025).

Verifier supervision operates on three score pathways. The final predicted score $(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 1 for the candidate proposal is trained with an MSE loss against the ground-truth score. The unconditional embedding $(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 2 is also decoded by the score head and supervised. The history result embeddings $(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 3 are likewise decoded and supervised with corresponding ground-truth rewards. The paper does not present a single displayed total-loss equation, but it explicitly states that all three pathways receive MSE supervision (Li et al., 29 Aug 2025).

Ground-truth reward definitions are task-specific. For articulated objects, reward is the relative amount the action opens the object compared to the ground-truth action at the same state. For uneven object lifting, reward is the signed distance between the lift point and the mass center. This makes the verifier a task-conditioned action-quality predictor rather than a binary success classifier (Li et al., 29 Aug 2025).

The paper also provides an explicit theoretical analysis of verifier-based selection. In the binary-reward case, with generator success probability $(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 4 and verifier accuracy $(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 5, naive single-sample execution has expectation

$(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 6

When $(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 7 actions are sampled and the verifier selects the highest-scoring one, the expected reward improves whenever

$(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 8

In the asymmetric case, with separate verifier accuracies on positive and negative actions,

$(o_0, a_0, o_1, a_1, \dots, o_{t-1}, a_{t-1}, o_t).$ 9

the improvement condition becomes

$G_\phi$ 0

For continuous rewards, with

$G_\phi$ 1

the verifier-induced improvement is

$G_\phi$ 2

The paper interprets this as showing that the benefit grows with proposal count $G_\phi$ 3, increases with reward spread $G_\phi$ 4, and decreases as verifier noise $G_\phi$ 5 rises (Li et al., 29 Aug 2025).

4. Empirical evaluation

The main evaluation covers three manipulation families: general articulated objects in simulation, multi-modal doors in simulation and on real hardware, and uneven object pick-up with hidden mass centers. The general articulated-object experiments use the PartNet-Mobility train/test split with objects initially fully closed and a 30-step budget. The reported metric is Failure Rate, defined as the percentage of objects opened less than 90% within 30 steps. Each object is tested five times, and the verifier receives 30 samples per step. Baselines include FlowBot3D, FlowBotHD without consistency check, FlowBotHD with consistency check, Generator Only, and Conditional Diffusion (Li et al., 29 Aug 2025).

Before the quantitative summary, two patterns are especially notable. First, HAVE is strongest in settings where visual ambiguity persists after unsuccessful actions, because history then becomes the only reliable disambiguating signal. Second, the oracle-sampler analysis shows that the verifier is not the sole bottleneck: if the proposal batch omits good actions, reranking cannot recover them. This is reflected by the oracle variant’s remaining gap relative to the standard sampler (Li et al., 29 Aug 2025).

Setting	Metric	HAVE result
General articulated objects	Failure Rate	2.5 with GT obs flow; 6.7 with estimated obs flow
Uneven object pick-up	Failure Rate	29.4 / 28.1 for HAVE + Cond
Articulated-object oracle sampler	Failure Rate	1.7

In the articulated-object benchmark, the full method substantially improves on all listed baselines. Reported Failure Rates are 13.4 for FlowBot3D, 21.9 for FlowBotHD without consistency check, 6.2 for FlowBotHD with consistency check, 22.8 for Generator Only, 19.7 for Conditional Diffusion, and 2.5 for HAVE with ground-truth observation flow; with estimated observation flow, HAVE achieves 6.7 (Li et al., 29 Aug 2025).

The multi-modal door benchmark duplicates door geometry while varying actuation mode across push-left, push-right, pull-left, and pull-right. The paper reports that HAVE significantly lowers both Failure Rate and Mean Steps to Open relative to baselines and most ablations. The real-world door experiment uses a Franka Emika Panda with a Schmalz Cobot Pump end effector, tests up to five steps per trial and five trials per mode, and reports higher success rate and lower mean steps to open across door modes. The qualitative pattern emphasized in the appendix is that after one failed mode, the generator may still frequently propose that same mode because the geometry changes little, whereas the verifier suppresses it using history (Li et al., 29 Aug 2025).

For uneven object pick-up, training uses ambiguous rods and testing includes unseen rods, bookmarks, irregular bookmarks, and knives. Failure is defined as tilt angle $G_\phi$ 6 radians or insufficient vertical center-of-mass lift, with a five-step budget and 20 action proposals per step. Reported Failure Rates are 41.2 / 36.8 for FlowBot3D, 36.5 / 37.6 for FlowBotHD without consistency check, 36.7 / 36.8 for Generator Only, 30.6 / 31.9 for Conditional Diffusion, 32.9 / 34.5 for HAVE + Uncond, 29.4 / 28.1 for HAVE + Cond, and 4.8 / 24.5 for the Oracle Sampler. In this simpler action space, the paper notes that conditional generator plus verifier works better than unconditional generator plus verifier (Li et al., 29 Aug 2025).

5. Ablations, interpretation, and limitations

The ablations show that HAVE does not use history merely as extra prompt context; it uses history as discriminative evidence. On the multimodal-door failure-history analysis, the valid rate of avoiding repeated failure modes is 99.79% for one-step history, 97.47% for two-step history, and 99.01% for three-step history. The paper also reports that with successful prior actions, the verifier can score plausible future actions even under heavy occlusion and at different object configurations, favoring better leverage points and directions close to the ground truth (Li et al., 29 Aug 2025).

Several implementation choices are empirically important. Sampling only 5 proposals already yields large gains, though more samples help with diminishing returns. Increasing history length from 1 to 5 improves performance significantly, while longer histories yield smaller and sometimes unstable gains because of redundancy. The explicit action-to-history attention is more robust to noisy estimated observation flow than a monolithic transformer that simply concatenates action and result tokens. Dense action fields outperform sparse action representations, and explicit observation-flow encoding outperforms using raw point clouds as result tokens. Auxiliary supervision on the unconditional score and history scores also improves performance slightly (Li et al., 29 Aug 2025).

The method’s practical strengths follow directly from these results. HAVE is well suited to latent physical ambiguity, online trial-and-error settings, multimodal action spaces, and regimes where a generator can propose diverse candidates but cannot reliably choose among them. A plausible implication is that HAVE is strongest when the dominant difficulty lies in test-time disambiguation rather than in one-shot action synthesis (Li et al., 29 Aug 2025).

The limitations are equally explicit. HAVE is bounded by the generator: if no good action appears in the sampled batch, the verifier cannot recover it. Training requires privileged supervision in simulation, including ground-truth actions and reward labels, which may be difficult to scale. The verifier performs one-step ranking rather than full planning over a long horizon. Generalization to unseen categories drops relative to seen distributions, and inference requires multiple diffusion samples and multiple verifier evaluations per step. The paper is also clear that HAVE is not planning over a long action horizon; it is an online reranking mechanism that improves one-step choice by exploiting test-time sampling and memory of previous outcomes (Li et al., 29 Aug 2025).

Although the robotic manipulation paper is the direct source of the name “History-Aware VErifier,” closely related ideas appear in several adjacent literatures. In computer-use agents, HiViG is a “History-aware Visually Grounded” test-time framework whose critic maintains macro-action history and performs visually grounded pre-execution critique. It is presented as a critic rather than a verifier, but it effectively instantiates a memory-conditioned verifier plus visually grounded pre-execution checker for GUI actions (Lee et al., 9 Jun 2026). In native GUI agents, HAR-GUI trains history-aware reasoning through reflective learning scenarios, tailored correction guidelines, and a Memory-Augmented Reward that explicitly checks whether the chain of thought contains historical interaction information. That work stops short of a standalone inference-time verifier, but it provides a direct precursor to one (Wang et al., 12 Nov 2025).

Verifier-like history conditioning also appears in theorem proving and retrieval. Leanabell-Prover-V2 uses verifier-integrated multi-turn reasoning in which prior failed proofs and prior Lean verifier outputs are concatenated into the next prompt, making the policy history-aware with respect to verifier interactions even though the Lean verifier itself is unchanged (Ji et al., 11 Jul 2025). HAConvDR, in conversational dense retrieval, performs a pseudo relevance judgment over prior turns based on actual downstream retrieval impact; this functions as an impact-based verifier over conversation history, selecting supportive history and turning harmful history into hard negatives (Mo et al., 2024).

In other domains, the same core motif recurs even when the term HAVE is not used. The personalized fashion model HAT is not called HAVE, but it acts as a history-conditioned outfit compatibility verifier or scorer, taking a shopper, their purchase history, and a candidate outfit, then predicting a personalized compatibility score (Jung et al., 2024). By contrast, another paper uses the acronym HAVE for something entirely different: the “Host Active Verification Engine,” an SDT extension that measures empirical compromise probabilities for attack-graph edges in Security Digital Twins. That usage shares the notions of history and verification only at the acronymic level; it is a security-digital-twin system rather than an action-ranking framework for robotics (Sammartino et al., 5 Jun 2026).

Two common misconceptions are therefore worth dispelling. First, HAVE in the robotics sense is not a monolithic history-conditioned policy; it is a decoupled generator–verifier system. Second, the acronym is not unique across “History-Aware VErifier” in robotics and “Host Active Verification Engine” in security denote distinct technical objects with different goals, architectures, and evaluation settings (Li et al., 29 Aug 2025).