Papers
Topics
Authors
Recent
Search
2000 character limit reached

Typed Debate Pipeline Overview

Updated 4 July 2026
  • Typed debate pipelines are structured architectures that use explicit types, schemas, and relation labels to organize debate exchanges.
  • They integrate three key stages – argument retrieval, debate turn generation, and LLM-based evaluation – to ensure controlled and auditable interactions.
  • These systems enforce role-based instructions and message schemas to implement constraints, enhance consistency, and improve overall debate quality.

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 (Miyaguchi et al., 12 Jul 2025). 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 (Sandwar et al., 28 Jan 2025, Han et al., 24 May 2025, Yadav et al., 16 Jun 2026, Zheng et al., 2 Nov 2025, Prakash, 12 Mar 2026, Trirat et al., 27 Jan 2026). 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 (Miyaguchi et al., 12 Jul 2025). 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={p1,,pK}P=\{p_1,\dots,p_K\}, a fixed number of rounds RR, and a vote set V={v1,,vK}V=\{v_1,\dots,v_K\}, with the final answer chosen by majority aggregation (Sandwar et al., 28 Jan 2025). 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 (Han et al., 24 May 2025). LegalHalluLens uses a six-agent, two-round debate state machine with typed claim categories {numeric, temporal, obligation, factual} and asymmetric Addition and Deletion gates (Yadav et al., 16 Jun 2026). GraphGeo replaces textual stage typing with relation typing, using a heterogeneous graph with r_agree, r_conflict, and r_transfer edges (Zheng et al., 2 Nov 2025). DCI formalizes contributions as 14 typed epistemic acts such as frame, propose, challenge, ground, update, and recommend (Prakash, 12 Mar 2026).

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-kk evidence documents as RetrievalResponse = { arguments: [ { id: String, text: String } ] } (Miyaguchi et al., 12 Jul 2025). 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 vq,viRdv_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-kk selection is then

TopK(q)=argsorti(Scorei)[1k].\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 } (Miyaguchi et al., 12 Jul 2025).

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:

RR4yaml { evidence } RR5haskell 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 (Miyaguchi et al., 12 Jul 2025). 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 \$R$0134.40 (Claude Opus) (Miyaguchi et al., 12 Jul 2025). 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 (Prakash, 12 Mar 2026). TS-Debate likewise uses multiple analyst agents, reviewer agents, and verification tools to improve zero-shot time-series reasoning (Trirat et al., 27 Jan 2026). The broader literature therefore treats typed debate not only as a reasoning method, but also as a resource allocation choice.

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 RR1 personas, debates for RR2 rounds, and produces a final answer through majority vote,

RR3

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% (Sandwar et al., 28 Jan 2025). 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 (Han et al., 24 May 2025). 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 %) (Yadav et al., 16 Jun 2026). 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 (Zheng et al., 2 Nov 2025). 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 (Trirat et al., 27 Jan 2026). 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 (Prakash, 12 Mar 2026).

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 (Bolton et al., 2020). 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 (Trabelsi et al., 2019). 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.

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to Typed Debate Pipeline.