Writing Your Touché 2026 Working-Notes Paper

These guidelines help you structure your paper, sharpen its focus, and avoid the issues we most often see across submissions.

As a general rule, do not assume that your reader is familiar with every term, abbreviation, or method you mention. Introduce all key concepts briefly and, where appropriate, support them with references.

The guidelines have two parts:

  1. How to write the paper — general advice on structure and what belongs in each section.
  2. Task requirements and reference — the concrete rules, citations, dataset details, and formatting specific to this shared task.

A short submission checklist at the end collects the mandatory items.

Part 1 — How to Write the Paper

General Structure

A paper is typically made up of a few standard parts, each with a distinct job: an abstract (a short overview of the whole paper), an introduction (problem, motivation, and your contribution), a body (usually dataset, experiments, and results), and a conclusion (what your work showed). For this task, a required AI-usage section follows the conclusion. The subsections below explain what belongs in each of these parts.

A well-structured paper progresses from the general to the specific. Begin by introducing the broader topic and its motivation, then move on to your specific approach, task, data, and experimental setup.

Throughout the paper, include only information that is actually necessary. Ask yourself whether each point is relevant to your method, experiments, or findings. For example, you do not need to describe every field in the dataset unless you used all of them in your experiments.

Abstract

The abstract is usually the first part of the paper that readers see, so it should give a clear and concise overview of the main idea. State the problem, the approach, and the main findings — briefly.

Avoid too much detail. Do not describe the shared task extensively, and do not explain your models, methods, or experimental setup in depth; those details belong in the main sections. The abstract should convey the paper's topic, main idea, and key contribution, even to a reader with only minimal prior knowledge.

Introduction

The introduction should set up the problem and explain why it matters. In particular, it should:

  • Define what fallacies are, and explain why detecting and classifying them matters.
  • Introduce the shared task as the setting for this problem, and briefly say what the task asks participants to do.
  • State your contribution clearly. This is the central idea of your paper: what are you proposing, and why do you believe it helps with fallacy detection and classification?

Do not use the introduction to describe your full experimental setup in detail — that belongs in the experiments section. The introduction motivates the work, explains the task briefly, and clearly presents the main idea behind your approach.

Body of the Paper

The remaining sections provide the details needed to understand and evaluate your work.

Dataset. The body usually begins with a dataset subsection. For a shared task, a short description of the shared-task dataset is enough: state how large it is and which fields you actually used. You need not describe fields you did not use — but briefly explain every field or term you do mention. For example, if you refer to “enhanced” fields, say what “enhanced” means, since it is not self-explanatory.

Approach & Experiments. Next, present your approach in detail and explain why you designed it this way. Make sure the reader can follow the main steps without having to guess what each model, feature, or abbreviation means. Describe how you trained your models and how you evaluated them: data splits, evaluation metrics, models, baselines, and any important implementation details. If you run experiments on your own data — for example, a development set — explain how that set was created and what kind of experiment you run on it. The goal is to make the experiments understandable and, where possible, reproducible. Very specific details, such as hyperparameters or prompts, can be moved to the appendix if they make the main section too long.

Results. Present the scores clearly and discuss what they show. These can be the results of your own experiments (for example, on your development set) or the official shared-task results on the test set. Do not only list numbers — explain what they mean. State whether the results support your main idea, and discuss any limitations or unexpected findings.

Conclusion

The conclusion summarizes what the paper has shown. Think of it as closing the circle opened by the introduction: return to the main research question or shared-task objective and state what answer your work provides. In the context of a shared task, explain whether your approach worked and what can be learned from the results.

Do not introduce new methods, experiments, or results in the conclusion. Briefly summarize the contribution, the main findings, and any important limitations or directions for future work.

AI Usage

Each paper is required to include a section on AI usage. It comes after your conclusion and is not a regular part of the paper's narrative. See the official guidance.

Part 2 — Task Requirements and Reference

The Task

This work is part of the Touché Lab at CLEF 2026, which includes several shared tasks on argumentation. One of them is Fallacy Detection, which consists of three subtasks: fallacy detection, fallacy classification, and argument scheme classification.

Citations

  • Cite the official Touché and task overview papers as specified on the Touché 2026 website. According to the official instructions, cite Touché and the task with \cite{kiesel:2026c,kiesel:2026d}. If you use TIRA, cite it with \cite{froebe:2023}.
  • If you use any models, cite or reference the corresponding model cards or documentation.
  • Explain abbreviations when first introduced, unless they are very widely known (e.g., BERT, LLM).
  • Do not use a citation as a noun or as the subject of a sentence — the number is not a substitute for the author name. Write “Smith et al. [4]” rather than “by [4]”, and “As stated by Smith et al. [4], …” rather than “As stated in [4], …”.

Writing Style

  • Do not start a sentence with a number or an acronym. Reword so the sentence opens with a word — e.g., “42 examples were labeled” → “We labeled 42 examples”, or spell the number out.

The Dataset

The dataset used in this task is based on the dataset by Sahai et al. For our experiments, we used a subset of it and created enhanced versions of the underlying data using Claude Opus 4.6.

  • Text versions. We first created a text_base version, in which the original comment, parent comment, and topic are combined into a single, more self-contained text. We then created a text_enhanced version: the same text_base rewritten so that the scheme dimensions (argument goal and basis) become clearly identifiable from the text and — if the instance contains a fallacy — the fallacious reasoning pattern is made more explicit and central. The rewrite is constrained to stay natural and plausible, still reading like a real person's comment rather than a contrived textbook example, and it preserves the original tone and stance.
  • Argument versions. We also created argument_base and argument_enhanced versions. These represent the argument as a claim together with supporting premises. In the dataset, the supporting premises are labeled support to signal that the filtering process may be noisy; in terms of argumentation theory, this field is intended to capture the premises that support the claim.

The full dataset, including the official test set and its gold labels, is available on Zenodo.

Argumentation Background

  • An argument consists of a claim and one or more premises. The premises provide support for the claim. In the dataset we label them support rather than premises, only to emphasize that — because they were extracted automatically — the claims and premises may not be perfect.
  • An argument may or may not be fallacious. A fallacy is an argument that appears convincing or valid at first glance but is flawed. Such flaws can arise for different reasons — for example, the argument may rely on premises that are not generally accepted, or the inference from the premises to the claim may be too broad, too weak, or otherwise unjustified.
  • Arguments can often be grouped by recurring patterns, known as argumentation schemes. For example, an argument from expert opinion follows the general pattern that an expert states something, and this statement is then used as support for a claim.
  • In this task, however, we focus on more general dimensions of arguments rather than only on specific schemes. These dimensions include whether an argument is practical or epistemic, and whether it is internal or external. Every argumentation scheme can be mapped to these dimensions: the dimensions are a generalization of the schemes, based on the theory of Macagno (2015).
  • Task 3 asks participants to propose an argumentation scheme for non-fallacious arguments. From a theoretical perspective, every argument can be assigned to these dimensions, regardless of whether it is fallacious; requiring this for non-fallacious arguments is not a theoretical necessity but arose only from the symmetry with Task 2.

Formatting

  • Title: <Your Team Name> at Touché: <Brief Description of your Approach>
  • Subtitle: Touché at CLEF 2026 (as per the official template).
  • Full submission information: Touché 2026 paper submission.

Tables and Figures

  • Make tables self-contained. Explain abbreviations and shortcuts directly in the table or its caption. A table should be understandable on its own, since readers often look at tables before reading the surrounding text — so it is acceptable, and often helpful, for a table to repeat information already in the main text.
  • Every table and figure should have a clear, informative caption.
  • Avoid figure overflow. Place and size figures so they fit cleanly into the layout and do not disrupt the surrounding text.

Numerical Precision

Use at most three digits after the decimal point. Differences beyond that are usually not meaningful — no one can reasonably conclude that one model is better than another based on a difference in the fourth or fifth decimal place.

Literature

Submission Checklist

  • Title follows <Team Name> at Touché: <Brief Description>; subtitle is Touché at CLEF 2026.
  • Abstract states problem, approach, and main findings — without setup details.
  • Introduction defines fallacies, introduces the task, and states your contribution.
  • Dataset subsection states size and the fields you actually used; every mentioned field/term is explained.
  • Experiments cover data splits, metrics, models, baselines, and key implementation details (hyperparameters/prompts can go to the appendix).
  • Results are interpreted, not just listed.
  • Conclusion closes the circle from the introduction; no new results.
  • Touché and task cited via \cite{kiesel:2026c,kiesel:2026d}; TIRA via \cite{froebe:2023} if used.
  • Models cited via their model cards / documentation.
  • Citations use author names, not bare numbers, and are never used as a noun (“As stated by Smith et al. [4]”, not “As stated in [4]”).
  • No sentence starts with a number or an acronym.
  • Results rounded to at most three decimal places.
  • Tables and figures are self-contained, captioned, and do not overflow.
  • AI-usage section included after the conclusion.

If you have any questions, please do not hesitate to contact us.