WebJudge Protocol

• WebJudge Protocol is a framework that evaluates the reliability of LLMs and MLLMs in judging web development artifacts.
• It formalizes static and dynamic assessment methods through query-specific rubric trees and human-annotated pairwise preferences.
• The protocol benchmarks automated judging by diagnosing bias, functional equivalence errors, and leveraging live interaction for nuanced evaluation.

The WebJudge protocol defines a systematic framework for evaluating the reliability and discriminative power of LLMs, multimodal LLMs (MLLMs), and @@@@1@@@@ when used as judges of web development artifacts. It formalizes both static (non-interactive) and dynamic (interactive) paradigms for assessment, grounded in query-specific rubric trees and anchored by human-annotated pairwise preference data. The protocol aims to rigorously measure agreement between automated judges and human experts, diagnose model failure modes such as bias and functional equivocation, and provide reproducible procedures for benchmarking automated web task evaluation (Li et al., 21 Oct 2025).

1. Formal Problem Definition and Objectives

WebJudge models the meta-evaluation problem as the analysis of a dataset:

$$D = \{ (Q_1, W_1^a, W_1^b, \ell_1), \ldots, (Q_N, W_N^a, W_N^b, \ell_N) \}$$

where for each instance: $Q_i$ is a user-specified web development query, $W_i^a$ and $W_i^b$ are two independently generated web implementations responsive to $Q_i$, and $\ell_i \in \{\text{a}, \text{b}, \text{tie}\}$ captures the human-annotated preference. A Judge $J(\cdot)$ receives $(Q, W^a, W^b)$ and a rubric set $R$, outputting a predicted label $\hat{\ell} \in \{\text{a}, \text{b}, \text{tie}\}$ or scores $s^a, s^b$ for grading.

The main objectives are to:

• Measure empirical agreement: $\hat{\ell} = \ell$
• Analyze error typologies (positional bias, functional equivalence misclassifications, feasibility errors)
• Contrast static and dynamic evaluation methodologies

2. Assessment Paradigms: Static and Dynamic

Static (Non-interactive) Protocol

The static paradigm operates on the fixed source code (and, optionally, a screenshot) for each implementation. Two canonical modes are used:

• Single-Answer Grading: For each $W$, the Judge computes a scalar score $s$. Pairwise preference is determined by thresholded differences:

$$\hat{\ell} = \begin{cases} \text{a} & \text{if } s^a - s^b > \delta \ \text{b} & \text{if } s^b - s^a > \delta \ \text{tie} & \text{otherwise} \end{cases}$$

• Pairwise Comparison: The Judge directly ingests $(Q, W^a, W^b)$ and outputs $\hat{\ell} \in \{\text{a}, \text{b}, \text{tie}\}$.

Pseudocode:

\begin{algorithmic}[1] \For{ each (Q, W^a, W^b) ∈ D } \State construct prompt ← (Q, code(W^a), code(W^b), instructions) \State ˆℓ ← \text{LLM}(prompt) \State record agreement ← [ˆℓ = ℓ] \EndFor \end{algorithmic}

A Likert-variant allows for scoring across Functionality, UI, Code, and Interactivity, producing summed scalar scores.

Dynamic (Interactive) Protocol

In the interactive setup, the Judge functions as an agent operating within a live browser environment $E(W)$ initialized with the candidate implementation $W$. The agent may issue actions (e.g., click, type, scroll, wait) and perceive the DOM tree and screenshot at each state $s_t$. Its workflow is decomposed into:

• Planner: Extracts testable tasks from the rubric.
• Executor: Conducts environmental interactions.
• Summarizer: Aggregates pass/fail task results.

Pseudocode:

\begin{algorithmic}[1] \Function{JudgeInteractive}{Q, W, R} \State E ← LaunchEnvironment(W) \State plan ← Planner(Q, R) \ForAll{task ∈ plan} \State result ← Executor(E, task) \EndFor \State summary ← Summarizer(plan, {result}) \State return summary \EndFunction \end{algorithmic}

Continuous operation allows adaptive task sequencing contingent on environment feedback.

3. Rubric Construction and Scoring Mechanisms

WebJudge employs query-grounded rubric trees $R(Q)$ shaped around three axes:

1. Intention: Core end-user features.
2. Static Quality: UI components, layout, code structure.
3. Dynamic Behavior: Interactive task functionality.

Each non-leaf rubric subdivides into finer bits; leaves represent atomic, binary-checked criteria. For a leaf $r \in R$:

$f_r(W, Q): (W, Q) \to \{0,1\}$

where 1 if $W$ implements $r$ under $Q$, 0 otherwise.

Aggregates:

• Dimension score:

$$\text{score}_d(W, Q) = \frac{1}{|R_d|} \sum_{r \in R_d} f_r(W, Q)$$

• Overall rubric score (default uniform weights $w_d = 1$):

$$S_{\mathrm{rubric}}(W, Q) = \sum_{d} w_d \cdot \text{score}_d(W, Q)$$

Each rubric tree $R(Q_i)$ is specialized to $Q_i$ and LLM-generated, then manually validated for consistency.

4. Data Resource and Human Preference Annotation

WebJudge's base dataset derives from "webdev-arena-preference-10k", curated through a rigorous two-phase filtering:

• Query Filtering: Removal of duplicates, unsafe/infeasible/ambiguous queries.
• Environment Filtering: Deploy in a controlled Next.js setup; exclude load failures or blank renders (via screenshot validation).

Annotations involve two expert raters, each conducting rubric-guided preference assignments over $(Q, W^a, W^b)$ tuples. Emphasis is placed on:

• Functionality prioritized over UI aesthetics
• Avoiding ties except in cases of strict equivalence
• Allowing for functionally equivalent, non-identical structural solutions

Inter-annotator raw agreement $p_o=0.897$. Cohen’s kappa is calculated as:

$\kappa = \frac{p_o - p_e}{1 - p_e}$

with $p_e$ as chance-agreement.

5. Metrics and Analytical Approaches

The protocol prescribes several evaluative metrics:

• Agreement Accuracy:

$$\mathrm{Acc} = \frac{1}{N}\sum_{i=1}^N \mathbf{1}[\hat{\ell}_i = \ell_i]$$

• Spearman’s $\rho$ (scalar score ranking correlation):

$\rho = 1 - \frac{6\sum_i d_i^2}{N(N^2-1)}$

• Precision, Recall, F1 for specific rubric dimensions (e.g., feasibility):

$$P = \frac{TP}{TP+FP},\quad R = \frac{TP}{TP+FN},\quad F_1 = \frac{2PR}{P+R}$$

• Statistical significance assessments: bootstrap confidence intervals for Acc; McNemar’s test for judge comparison.

6. Execution in Dynamic Environments and Agentic Workflow Specification

The $E(W)$ environment is instantiated via a headless or GUI browser under standard Next.js runtime constraints. Judge agent actions comprise an LLM-to-action translation layer (such as ReAct paradigm) producing commands (click, type, scroll, wait) interpretable by control frameworks like pyautogui.

The agentic loop repeatedly observes $s_t$, consults $R(Q)$, plans and executes next tasks, then aggregates outcomes for final summarization. This enables real-time adaptation to environment feedback and more nuanced, context-sensitive evaluation.

7. Model Limitations and Error Taxonomy

Multiple systematic failure modes are identified:

• Positional Bias: Automated judges systematically overprefer the first or second implementation by approximately 5–10%, irrespective of checklist instructions.
• Functional Equivalence Failure: Judges frequently penalize solutions solely due to naming or presentation variations, despite identical underlying semantics (e.g., labeling “Presentation” versus “Demonstration”).
• Feasibility Verification Shortcomings: Static judges achieve high recall for feasibility at the cost of low precision, largely due to reliance on code patterns rather than live execution. Interactive agents invert this trend, demonstrating high precision but low recall, most often attributable to brittle navigation or rendering failures.
• Error Accumulation in Agentic Pipeline: Weaknesses in the plan–execute–summarize sequence, such as erroneous planning or execution, propagate, culminating in compounded evaluation errors.

Collectively, these constraints underscore substantive reliability gaps between current (M)LLM judges and human experts. The protocol thereby establishes comprehensive benchmarks, highlighting both methodological advances and the extant challenges for automated web task evaluation (Li et al., 21 Oct 2025).