Methodik

Nachweis: vor dem Ereignis abgegeben

Jede Vorhersage speichert ihren Abgabezeitpunkt. Liegt er vor dem Ereigniszeitpunkt, wird sie in der Event-Liste als „✓ vorab" markiert. Fehlt der Zeitstempel, erscheint bewusst keine Markierung – behauptet wird nur, was belegt ist.

Die Datensätze liegen offen als JSON-Dateien und ihre Änderungshistorie ist öffentlich einsehbar. Damit ist von außen prüfbar, dass eine Vorhersage tatsächlich vor dem Ereignis existierte und nachträglich nicht verändert wurde.

Das Wettkampf-Harness HARNESS_V2

FutureBench bewertet das ausgelieferte Produkt, nicht das nackte Modell – jedes Modell antwortet aus dem, was es ohnehin weiß, unter einem identischen Protokoll: gleicher Prompt, gleiche Informationen, gleiches Zeitfenster, gleiche Validierung, gleiches Wiederholungsbudget. Kein Modell darf etwas nachschlagen. Nach dem Lock wird nichts nachgereicht, nichts zurechtgebogen, nichts neu ausgelegt.

• Ein versioniertes Template. Jedes Modell erhält denselben System- und User-Prompt; nur der Mechanismus für strukturierte Ausgabe unterscheidet sich. Zu jeder Vorhersage wird der SHA-256-Hash des gesendeten Prompts gespeichert – jede Wortänderung ist so in den Daten sichtbar.
• Die Wertungsregel wird offengelegt. Jedes Modell erfährt, wie seine Antwort gewertet wird. Bei Proper Scoring Rules ist das methodisch geboten: Ein Modell, das die Regel nicht kennt, würde für Unwissen bestraft, nicht für eine schlechte Prognose.
• Die Ausgabe ist das Speicherformat. Das geforderte JSON ist exakt der Wert, der in den öffentlichen Datendateien landet. Geprüft wird mit denselben Validatoren wie auf der Seite, gespeichert wird unverändert – es gibt keinen Zwischenschritt, der etwas glättet.

Vom Runner erzwungene Grenzen

20

Werkzeugaufrufe je Vorhersage (in dieser Version keine verfügbar)

5

Minuten je Versuch

2

Wiederholungen bei Transportfehlern

2

Format-Reparaturrunden (nur Format, nie der Wert)

System-Prompt im Wortlaut

Dieser Text wird aus derselben Datei gelesen, die der Runner sendet. Er kann nicht von dem abweichen, was die Modelle tatsächlich erhalten haben.

You are competing in FutureBench, a public prediction benchmark for language models.

Real events are scored publicly. Your prediction is committed to a public git repository BEFORE the event begins, so it cannot be changed afterwards. Other frontier models answer the exact same question under the exact same protocol, and the leaderboard is citable.

You have NO access to the internet, to search, or to any tool. Every competitor runs under this same restriction, so nobody can look anything up. The only external information anyone gets is what appears in this message: the question, how it will be resolved, and the context block below. Everything else must come from what you already know.

How to compete well:
- Your knowledge has a cutoff and this event lies after it. Reason from durable structure — relative strength, base rates, historical distributions, how such things usually resolve — rather than from any specific recent report you think you remember.
- Use the context block as the anchor when it gives you one. A stated last known value is the single most informative number you have.
- Do not invent sources, headlines or figures to justify an answer. A confident fabrication scores no better than an honest guess and is visible in the published record.
- Commit to the single answer that maximises your expected score under the stated scoring rule.
- Be calibrated, not brave. Overconfidence is punished by the scoring rule; so is refusing to commit.
- Answer even when uncertain. A missing answer scores nothing at all and is recorded publicly as a failure to answer.

Output discipline:
- End your reply with exactly one fenced ```json code block containing your answer.
- The JSON schema is fixed and given below. No extra fields, no comments, no trailing text after the block.
- Your reasoning may precede the block in plain prose; only the JSON block is stored as your prediction.

PREDICTION TYPE: scoreline (final score of a two-sided match)

SCORING RULE (Kicktipp scheme, higher is better):
- 4 points: exact score
- 3 points: correct goal difference (but not the exact score)
- 2 points: correct outcome only (home win / draw / away win)
- 0 points: wrong outcome

Both goal counts must be non-negative integers. Predict the score at the end of the
period the question names — do not add extra time or penalties unless the question
explicitly asks for the result after them.

OUTPUT SCHEMA:
{
  "prediction": { "kind": "scoreline", "home": <integer >= 0>, "away": <integer >= 0> },
  "rationale": "<optional, max 500 characters>"
}

PREDICTION TYPE: numeric (a single point estimate)

SCORING RULE (lower is better): absolute error |your value − actual value|.
Aggregated across events as MAE, MAPE and RMSE, and compared against a reference
baseline via a skill score.

Because absolute error is minimised by the MEDIAN of your belief distribution — not
by the mean and not by a dramatic outlier — state the value you consider equally
likely to be too high as too low. Use the exact unit and precision the question
states. Give a plain number: no thousands separators, no currency symbols, no ranges.

OUTPUT SCHEMA:
{
  "prediction": { "kind": "numeric", "value": <number> },
  "rationale": "<optional, max 500 characters>"
}

PREDICTION TYPE: binary (probability that the statement turns out TRUE)

SCORING RULE (lower is better): Brier score (p − outcome)², plus log loss and
accuracy at the 0.5 threshold as secondary metrics.

These are proper scoring rules: your expected score is best when you report your
TRUE probability. Note that 0 and 1 are almost never optimal — under log loss a
confident wrong answer at exactly 0 or 1 is catastrophic. Do not round to 0.5 to
play safe either; that discards what you do know.

OUTPUT SCHEMA:
{
  "prediction": { "kind": "binary", "probability": <number between 0 and 1> },
  "rationale": "<optional, max 500 characters>"
}

Informationsstand: was jedes Modell bekommt

Kein Modell kann suchen, surfen oder ein Werkzeug aufrufen, und jedes erfährt das ausdrücklich. Die einzige Information von außen sind die Frage, die Auflösungsregel und ein kurzer Kontextblock aus dem Datenfeed – bei einem Markt gehört der letzte bekannte Kurs dazu. Alles Weitere muss aus dem kommen, was das Modell ohnehin weiß.

Das ist eine bewusste Verengung. Ließe man jedes Modell die Suche seines Anbieters nutzen, würde man den Suchindex mitmessen – und diese Indizes unterscheiden sich auf eine Weise, die außerhalb der Labore niemand prüfen kann. Der Verzicht auf Recherche kostet Realitätsnähe und kauft Vergleichbarkeit: Was zwei Modelle hier trennt, ist jedenfalls nicht die bessere Suchmaschine.

Sampling-Einstellungen bleiben beim Standard des jeweiligen Anbieters. Eine feste Temperatur würde eine Kontrolle vorgeben, die wir nicht haben – mehrere Reasoning-APIs ignorieren den Parameter.

Zeitfenster

Vorhersagen werden in einem Fenster erhoben, das mit dem Lock-Zeitpunkt des Events endet. Alle Modelle eines Events werden im selben Durchgang zum selben Moment befragt – niemand bekommt frischere Informationen als ein anderer.

Eine Antwort, die nach dem Lock eintrifft, wird verworfen und nie exportiert. Ein täglicher Check prüft diese Invariante gegen die gesamte Datenbank – die Zitierfähigkeit des Leaderboards hängt daran.

Fehlende Antworten

Eine Verweigerung ist ein Ergebnis. Liefert ein Modell innerhalb seines Budgets keine gültige Antwort, wird die Lücke mit Grund veröffentlicht statt stillschweigend gefüllt. Werte werden nie korrigiert: Eine unmögliche Wahrscheinlichkeit von 1,3 bleibt ungültig, statt zu 1,0 zu werden.

Veröffentlichte Grund-Codes

refusal

das Modell hat die Antwort verweigert

invalid-output

auch nach den Reparaturrunden kein gültiger Wert

timeout

keine Antwort innerhalb des Zeitlimits

api-error

die API des Anbieters meldete einen Fehler

rate-limited

Ratenlimit vor dem Lock nicht mehr freigegeben

late

Antwort kam nach dem Lock

Wie Events aufgelöst werden

Auflösungsquelle und Leseregel werden bei der Erstellung des Events festgelegt, bevor irgendwer getippt hat. Die Modelle sehen diese Regel wörtlich in ihrem Prompt – sie lesen genau das, was später auch der Betreiber liest.

Nach dem Lock gibt es keinen Ermessensspielraum. Wo die Regel nicht genau einen Wert liefert, wird das Event ungültig – es bleibt mit Grund sichtbar und wird für niemanden gewertet. Ungültigkeit ist der einzige mögliche Ausgang eines Streitfalls; eine Auflösung wird nie umgeschrieben.

Ein Event wird ungültig, wenn

• die festgelegte Regel nicht genau einen Wert liefert
• die Quelle nicht verfügbar ist oder sich widerspricht
• das Ereignis abgesagt, verschoben oder vorzeitig begonnen wurde
• der gemeldete Wert den Vertrag des Event-Typs verletzt

Modellversionen

Eine Leaderboard-Zeile ist eine Modellversion. Zu jeder Vorhersage wird die von der API zurückgemeldete Modell-ID gespeichert, sodass eine stille Änderung hinter einem gleitenden Alias sichtbar wird. Tritt das ein, wird die Zeile eingefroren und eine neue beginnt – Ergebnisse zweier Versionen werden nie vermischt.

Ein Modell, das den Wettkampf verlässt, behält seine Zeile und seine Historie. Gelöscht wird nichts – schwache Ergebnisse nachträglich zu entfernen wäre genau der Selektionseffekt, den ein Benchmark ausschließen muss.

Arten von Vorhersagen

Ergebnistipp scoreline

Eingabeformat: 2-1

Zahlenschätzung numeric

Eingabeformat: 4512.30

Wahrscheinlichkeit (Ja/Nein) binary

Eingabeformat: 0.70 / 70%

Metriken

Welche Metriken eine Kategorie anzeigt, entscheidet die Kategorie selbst. „Kleiner ist besser" ist bei Fehlermaßen der Normalfall.

Baselines je Kategorie

Die wichtigste Frage ist nicht „wie gut ist der Wert?", sondern „schlägt das Modell die etablierte Referenz?". Kategorien ohne belastbare Referenz zeigen bewusst keinen Skill-Score, statt eine Baseline zu erfinden.

Grenzen der Aussagekraft

• Stichprobengröße. Jede Tabelle zeigt die Spalte „Gewertet". Bei wenigen Events entscheidet Zufall mehr als Können – Rangfolgen sind dann nicht belastbar. Konfidenzintervalle sind für eine spätere Ausbaustufe vorgesehen.
• Punkte sind nicht kategorieübergreifend vergleichbar. Eine Punktsumme hängt von der Anzahl der Events ab, ein Fehlermaß von der Einheit. Nur der Skill-Score gegenüber der Baseline ist dimensionslos und damit übertragbar.
• Proper Scoring Rules statt Trefferquote. Bei Wahrscheinlichkeiten ranken wir nach Brier und Log-Loss. Eine reine Trefferquote würde Modelle belohnen, die grundsätzlich extreme Wahrscheinlichkeiten nennen.
• Prototyp-Status. Außer der abgeschlossenen Fußball-WM 2026 sind alle Kategorien derzeit mit Beispieldaten gefüllt. Sie dienen dem Aufbau der Oberfläche, nicht der Bewertung von Modellen.