---
title: Typed Debate Pipeline Overview
url: https://www.emergentmind.com/topics/typed-debate-pipeline
type: topic
---

# Typed Debate Pipeline Overview

A typed debate pipeline is a structured debate architecture in which the debate state, evidence, agent roles, interaction patterns, or evaluation outputs are represented through explicit types, schemas, or relation labels. In the retrieval-augmented setting, the term denotes a three-stage flow from argument retrieval to debate turn generation to LLM-based evaluation, with concrete interfaces such as `DebateRequest`, `RetrievalResponse`, `SystemResponse`, `EvaluationRequest`, and `EvaluationResponse` [2507.09090]. In adjacent lines of work, typing appears as multi-persona role sets and voting procedures, stage-specific JSON message schemas, typed hallucination categories and gates, heterogeneous graph edge types, typed epistemic acts, and modality-specialized reviewer protocols [2502.15725], [2505.18596], [2606.18021], [2511.00908], [2603.11781], [2601.19151]. The surveyed literature suggests that typing functions as a control mechanism for decomposition, constraint enforcement, auditability, and aggregation rather than as a single canonical debate algorithm.

## 1. Typed debate as an interface discipline

In the DS@GT at Touché system, the pipeline is explicitly decomposed into three stages: **Argument Retrieval**, **Debate Turn Generation**, and **LLM-Based Evaluation**. The simplified data flow is `DebateRequest → (1) Retrieval component → RetrievalResponse → (2) Debate generation → SystemResponse → (3) Evaluation component → EvaluationResponse` [2507.09090]. This formulation makes the debate pipeline typed in a literal engineering sense: each stage consumes and emits a defined record, and each record constrains the permissible state transition.

The same design principle appears in other forms across the literature. Town Hall Debate Prompting defines a set of personas $P=\{p_1,\dots,p_K\}$, a fixed number of rounds $R$, and a vote set $V=\{v_1,\dots,v_K\}$, with the final answer chosen by majority aggregation [2502.15725]. Debate-to-Detect organizes debate into five named stages—Opening Statement, Rebuttal, Free Debate, Closing Statement, and Judgment—and each stage has its own message schema, such as `MessageOpening`, `MessageRebuttal`, `MessageFree`, `MessageClosing`, `MessageSynopsis`, and `MessageScore_d` [2505.18596]. LegalHalluLens uses a six-agent, two-round debate state machine with typed claim categories `{numeric, temporal, obligation, factual}` and asymmetric Addition and Deletion gates [2606.18021]. GraphGeo replaces textual stage typing with relation typing, using a heterogeneous graph with `r_agree`, `r_conflict`, and `r_transfer` edges [2511.00908]. DCI formalizes contributions as 14 typed epistemic acts such as `frame`, `propose`, `challenge`, `ground`, `update`, and `recommend` [2603.11781].

A plausible implication is that “typed debate pipeline” names a family of systems whose common property is explicit structural control. Some systems type inputs and outputs; others type debate moves, relation edges, modalities, or error categories. The common thread is not simply multi-agent interaction, but the imposition of a formal grammar over that interaction.

## 2. Retrieval-augmented debate architecture

In the DS@GT formulation, argument retrieval takes as input the current debate state, defined as the user’s last utterance plus a “topic” identifier, queries a vector-indexed argument store, and returns the top-$k$ evidence documents as `RetrievalResponse = { arguments: [ { id: String, text: String } ] }` [2507.09090]. The argument source is the **ClaimRev corpus**, described as a collection of debate claims plus counter-arguments, with each record structured as `Argument = { id: String, text: String }`.

The retrieval component uses **Elasticsearch + Stella embeddings (dense vector index)**. Given query and document embeddings $v_q, v_i \in \mathbb{R}^d$, ranking is defined by cosine similarity:
$$
\mathrm{Score}_i = \cosine(v_q, v_i)
= \frac{v_q \cdot v_i}{\|v_q\|\;\|v_i\|}.
$$
Top-$k$ selection is then
$$
\mathrm{TopK}(q) = \mathrm{argsort}_{i}\bigl(\mathrm{Score}_i\bigr)[1\ldots k].
$$
The implementation returns the **top 10** arguments.

Debate turn generation consumes `DebateRequest = { messages: [ { role: "user"|"assistant", content: String } ] }` together with the retrieval output and formats a **single LLM prompt**. That prompt injects four components: an `## evidence` block containing the retrieved arguments in YAML, `## role` instructions for debate role and style constraints, `## constraints` enforcing a **60-word limit** and **no citations**, and `## context` containing the full serialized debate so far. The output is `SystemResponse = { utterance: String, arguments: RetrievalResponse }` [2507.09090].

This arrangement is notable because the debate generator is not directly retrieving free-form web evidence at generation time. Instead, it is conditioned on a bounded evidence set and on a fully serialized debate history. The surveyed design thereby couples evidence retrieval and response generation tightly enough to support end-to-end evaluation.

## 3. Prompt structure, model deployment, and response behavior

The DS@GT prompting strategy separates evidence, role instructions, constraints, and context through strict YAML and section headings. Evidence insertion is given as:

```text
## evidence
```yaml
{ evidence }
```
```

The role section uses the instruction **“You are an expert debate partner …”** with numbered guidelines. The constraints block enforces **max–60 words**, and the context block injects `{ context }`. The system uses **no special PRO/CON tokens**, relying instead on strict YAML plus section headings to separate content [2507.09090].

Six publicly available models from three providers were deployed for retrieval-augmented debate and evaluation.

| Model | Context window | Input / Output $/M |
|---|---:|---:|
| anthropic/claude_opus-4 | 200 k tokens | \$15 / \$75 |
| anthropic/claude_sonnet-4 | 200 k tokens | \$3 / \$15 |
| google/gemini-2.5-flash-preview | 1 048 576 | \$0.15 / \$0.60 |
| google/gemini-2.5-pro-preview | 1 048 576 | \$1.25 / \$10 |
| openai/gpt-4.1 | 1 047 576 | \$2 / \$8 |
| openai/gpt-4o | 128 000 | \$2.50 / \$10 |

Measured response lengths reveal a consistent verbosity pattern. **Claude Opus-4** had mean $56.50$ words with $\sigma = 8.42$ and peaked at 60; **Claude Sonnet-4** had mean $53.00$ with $\sigma = 3.83$; **GPT-4.1** had mean $54.44$ with $\sigma = 2.20$ and was identified as **most consistent**; **Gemini Flash** had mean $44.39$ with $\sigma = 6.32$ [2507.09090]. The stated observation was that **higher context models → longer, more verbose but not necessarily higher official “Quantity” compliance**.

This observation is significant because the DS@GT system evaluates debate turns partly through maxim-style criteria. Longer outputs can approach the 60-word boundary without necessarily improving official compliance. The paper therefore distinguishes raw verbosity from rubric-level sufficiency.

## 4. Evaluation protocol and reported results

The DS@GT evaluation module takes `EvaluationRequest = { simulation: Simulation, userTurnIndex: Maybe Int }`, where `Simulation = { userTurns: [ { utterance, systemResponse } ] }`, and performs a **single-shot prompt** asking the LLM to assign four scores—`quantity`, `quality`, `relation`, and `manner`—on $[0.00,1.00]$ in JSON [2507.09090]. The output schema is `EvaluationResponse = { quantity: {explanation,score}, quality: {…}, relation: {…}, manner: {…} }`.

The four metrics are defined as follows. **quantity** is “Sufficient relevant information, reasons, and evidence.” **quality** is “Logical, coherent, well-structured reasoning; accurate and credible.” **relation** is “Directly relevant to the original argument.” **manner** is “Clear, unambiguous, correct grammar; respectful tone.” Scores are assigned in increments of **0.01**; the rubric reserves $s_X = 1.00$ for flawless cases and treats $s_X \approx 0.50$ as adequate. Calibration further specifies that $s=1.00$ should be used only if no improvement is possible, and $s=0.50$ denotes adequacy with clear room for improvement. The implementation performs **a single LLM call per turn** returning all four metrics in JSON, and **memoization** is used to cache identical calls and reduce cost.

On the internal toy simulation of **2 topics × 4 runs**, reported overall averages were: **Opus-4 = 0.2773, $\sigma_{\text{overall}} < 0.26$**, described as **strictest, most consistent**; **Sonnet-4 = 0.2681, $\sigma < 0.26$**; **Gemini-Flash = 0.4068**, the highest; **GPT-4o = 0.3870**; and **GPT-4.1 = 0.3170** [2507.09090]. At the per-metric level, **Manner scores ~0.50–0.80, highest consistency**, while **Relation/Quantity/Quality ~0.17–0.36, lower and more variant**. **Statistical tests: none reported; consistency measured by standard deviation.**

The experimental setup combined internal and official evaluations. ClaimRev provided an index of **~tens of thousands of arguments**. Internal simulations used **6 random topics, 3 turns/model → 18 utterances/model**. The official baseline used **2 topics (“Television is bad/good”), 3 turns each**. The committee baseline system used **Elasticsearch + Stella embeddings, no LLM**.

For **official sub-task 1 (Maxim compliance)**, **GPT-4.1 run = AVG 0.70 (Quantity 0.95, Quality 0.17, Relation 0.82, Manner 0.84)**, whereas the **Baseline = AVG 0.62 (Q 0.35, Ql 1.00, R 0.32, M 0.80)** [2507.09090]. For **official sub-task 2 (Classification F1)**, **GPT-4o & Gemini-Flash both F1 0.64 overall**, **Baseline F1 0.67**, and **GPT-4.1 F1 0.62**.

The reported pattern supports the paper’s summary judgment: LLMs perform well in debates when given related arguments, but they tend to be verbose in responses while remaining consistent in evaluation.

## 5. Reproducibility, interfaces, and operational profile

The DS@GT paper provides a direct reconstruction blueprint. The core Haskell-like pseudocode interfaces are:

```haskell
respond :: DebateRequest → SystemResponse
quantity/quality/relation/manner :: EvaluationRequest → EvaluationResponse
```

The end-to-end reconstruction procedure is also explicit: **Index ClaimRev in Elasticsearch + Stella embeddings**; implement a `respond` endpoint that **retrieves top-10, formats Prompt (§3.1), calls each LLM via OpenRouter, returns SystemResponse**; implement **four evaluation endpoints** that **memoize calls and parse JSON from Prompt (§3.2)**; and **submit through a thin proxy to GenIRSim/TIRA respecting the interfaces in Figures 4 and 5** [2507.09090]. The accompanying source code is located at the repository identified in the paper.

Operational costs are reported separately for generation and evaluation. **Generation** costs ranged from **\$0.045–\$5.21 per ~200 requests**. **Evaluation** costs ranged from **\$0.188–\$12.10 per ~150 requests**. For **5 000 evaluation requests**, projected cost ranged from **\$1.13 (Gemini-Flash) to \$134.40 (Claude Opus)** [2507.09090]. These figures matter because typed debate systems often incur substantial orchestration overhead relative to single-call generation.

This cost profile aligns with broader evidence in the area. DCI reports approximately **237 K tokens/task** versus **3.8 K** for a Single Agent, or about **62× more**, and explicitly argues that consequential decisions may justify this overhead when process accountability is required [2603.11781]. TS-Debate likewise uses multiple analyst agents, reviewer agents, and verification tools to improve zero-shot time-series reasoning [2601.19151]. The broader literature therefore treats typed debate not only as a reasoning method, but also as a resource allocation choice.

## 6. Related forms of typing in debate research

The surveyed literature indicates that typed debate pipelines vary primarily in **what** is typed: personas, stages, message schemas, claim categories, edge relations, epistemic acts, or modalities.

| Work | Typed unit | Debate function |
|---|---|---|
| DS@GT at Touché | Interfaces and evaluation fields | Retrieval-augmented debate and scoring |
| Town Hall Debate Prompting | Personas and votes | Multi-persona reasoning and majority aggregation |
| Debate-to-Detect | Stage-specific message schemas | Adversarial misinformation detection |
| LegalHalluLens | Claim categories and gates | Hallucination auditing and calibrated debate |
| GraphGeo | Heterogeneous edge relations | Multi-agent geo-localization debate |
| DCI | Typed epistemic acts | Deliberative collective reasoning |

In **Town Hall Debate Prompting**, a single LLM is spliced into $K$ personas, debates for $R=3$ rounds, and produces a final answer through majority vote,
$$
\hat{y} = \underset{c}{\arg\max}\;\sum_{k=1}^K \mathbf{1}[v_k = c].
$$
The paper reports that **a town hall size of 5 personas with LLM-determined personality types performs optimally on ZebraLogic**, with a **13\% improvement over one-shot CoT baselines in per-cell accuracy in GPT-4o**, a **9% puzzle accuracy increase in Claude 3.5 Sonnet**, and an improvement in **hard puzzle accuracy from 10-15%** [2502.15725]. Here, typing resides in persona assignment and role-conditioned turn scheduling rather than in retrieval or evaluation schemas.

In **Debate-to-Detect**, typing is stage-based and schema-based. The moderator controls **Opening, Rebuttal, Free Debate, Closing, Judgment**, maintains **Shared Memory**, validates each reply against an expected schema, and final classification is computed from a **zero-sum scoring rule** over **Factuality, Source Reliability, Reasoning Quality, Clarity, and Ethics** [2505.18596]. In **LegalHalluLens**, typing is error-centric: the system audits hallucinations across **numeric, temporal, obligation/entitlement, factual** claims, computes a **Risk Direction Index (RDI)**, and then uses **typed challenges**, **Verifier** checks, and **asymmetric gates**. On a **120-contract matched subset**, the debate pipeline reduced **False-positive extractions from 524→287 (−45 %)** while **Content-contradictions barely move (642→641, −0.2 %)** [2606.18021]. This formulation shows that typed debate can be calibrated to measured failure modes rather than merely to generic adversarial exchange.

In **GraphGeo**, the debate substrate is not a transcript but a heterogeneous graph. Agents are LVLM nodes, and typed edges distinguish **supportive collaboration**, **competitive argumentation**, and **knowledge transfer** through `r_agree`, `r_conflict`, and `r_transfer` relations [2511.00908]. In **TS-Debate**, the typed structure is multimodal and reviewer-centric: a **Text Analyst**, **Visual Analyst**, and **Numerical Analyst** generate evidence, reviewer agents perform **Verification–Conflict–Calibration**, and final synthesis uses only verified and domain-consistent evidence when conflicts remain [2601.19151]. In **DCI**, contributions are typed epistemic acts over a structured workspace, and the system guarantees termination with a **Decision Packet** containing the selected option, residual objections, minority report, next actions, and reopen conditions [2603.11781].

Two earlier lines of work provide antecedents. **High Quality Real-Time Structured Debate Generation** defines **debate trees** and **debate paths**, extracts stance-conditioned `(prompt, response)` training pairs from Kialo, prepends **“Pro:”** or **“Con:”** stance tokens, and reports **~3 seconds per generated argument** [2012.00209]. **Contrastive Reasons Detection and Clustering from Online Polarized Debate** is not a generative debate system, but it organizes polarized debate through topic-viewpoint assignments, multi-word phrase mining, and two-column digests of **Oppose** versus **Support** reasons [1908.00648]. These precedents suggest that typed debate research predates current LLM pipelines and includes both generative and analytic traditions.

A common misconception is that typed debate necessarily means multi-agent free-form discussion. The literature does not support that restriction. Some typed debate pipelines are retrieval-generation-evaluation stacks; some are graph message-passing systems; some are fixed-stage adversarial protocols; some are deliberative workspaces with typed acts; and some are summarization pipelines over polarized corpora. What unifies them is explicit structure over how arguments are retrieved, produced, challenged, scored, or aggregated.

Source: https://www.emergentmind.com/topics/typed-debate-pipeline