Metodología

Prueba: enviado antes del evento

Cada predicción guarda su momento de envío. Si es anterior al evento, en la lista se marca como «✓ previo». Si falta la marca de tiempo, no se muestra ninguna señal: solo se afirma lo que puede demostrarse.

Los conjuntos de datos son archivos JSON públicos y su historial de cambios es visible. Así puede verificarse desde fuera que una predicción existía antes del evento y que no se modificó después.

El protocolo de competición HARNESS_V2

FutureBench evalúa a cada modelo respondiendo con lo que ya sabe, bajo un protocolo idéntico: mismo prompt, misma información, misma ventana temporal, misma validación, mismo presupuesto de reintentos. Ningún modelo puede consultar nada. Después del cierre nada se añade, se ajusta ni se reinterpreta.

• Una plantilla versionada. Cada modelo recibe el mismo prompt de sistema y de usuario; solo difiere el mecanismo de salida estructurada. Cada predicción guarda un hash SHA-256 del prompt recibido, de modo que cualquier cambio de redacción es visible en los datos.
• La regla de puntuación se revela. Cada modelo conoce cómo se puntuará su respuesta. Con reglas de puntuación propias esto es metodológicamente necesario: un modelo que no conoce la regla sería penalizado por ignorancia, no por un mal pronóstico.
• La salida es el formato almacenado. El JSON solicitado es exactamente el valor que acaba en los archivos públicos de datos. Se comprueba con los mismos validadores del sitio y se guarda sin cambios: no hay ningún paso de limpieza intermedio.

Límites que aplica el ejecutor

20

llamadas a herramientas por predicción (ninguna en esta versión)

5

minutos por intento

2

reintentos ante errores de transporte

2

rondas de reparación de formato (solo formato, nunca el valor)

Prompt de sistema, literal

Este texto se lee del mismo archivo que envía el ejecutor. No puede divergir de lo que los modelos recibieron realmente.

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>"
}

Información: lo que recibe cada modelo

Ningún modelo puede buscar, navegar ni usar herramientas, y a todos se les dice con claridad. La única información externa que recibe cualquiera es la pregunta, la regla de resolución y un breve bloque de contexto del feed de datos: en un mercado, eso incluye el último valor conocido. Todo lo demás debe salir de lo que el modelo ya sabe.

Es un estrechamiento deliberado. Permitir que cada modelo use la búsqueda de su proveedor mediría el índice de búsqueda tanto como al modelo, y esos índices difieren de formas que nadie fuera de los laboratorios puede inspeccionar. Renunciar a la recuperación cuesta realismo y compra comparabilidad: lo que separa a dos modelos aquí no es un buscador mejor.

Los ajustes de muestreo se dejan en el valor predeterminado de cada proveedor. Fijar una temperatura sugeriría un control que no tenemos, porque varias API de razonamiento ignoran el parámetro.

Ventana temporal

Las predicciones se recogen en una ventana que se cierra en el momento de bloqueo del evento. Todos los modelos de un evento se consultan en el mismo lote y en el mismo instante, así que ninguno recibe información más reciente que otro.

Una respuesta que llega después del cierre se descarta y nunca se exporta. Una comprobación diaria verifica esta invariante en toda la base de datos, porque de ella depende la citabilidad de la clasificación.

Respuestas ausentes

Una negativa es un resultado. Si un modelo no produce una respuesta válida dentro de su presupuesto, el hueco se publica con su motivo en lugar de rellenarse en silencio. Los valores nunca se corrigen: una probabilidad imposible de 1,3 sigue siendo inválida en vez de convertirse en 1,0.

Códigos de motivo publicados

refusal

el modelo se negó a responder

invalid-output

ningún valor válido ni tras las rondas de reparación

timeout

sin respuesta dentro del límite de tiempo

api-error

la API del proveedor devolvió un error

rate-limited

límite de tasa no liberado antes del cierre

late

la respuesta llegó después del cierre

Cómo se resuelven los eventos

La fuente de resolución y la regla para leerla se fijan al crear el evento, antes de que nadie prediga. Los modelos ven esa regla literalmente en su prompt: leen exactamente lo que el operador leerá después.

No hay discrecionalidad del operador tras el cierre. Cuando la regla no produce exactamente un valor, el evento se anula: permanece visible con su motivo y no puntúa para nadie. La anulación es el único resultado posible de una disputa; una resolución nunca se reescribe.

Un evento se anula cuando

• la regla establecida no arroja exactamente un valor
• la fuente no está disponible o se contradice
• el evento se cancela, se posterga o comienza antes de lo previsto
• el valor informado incumple el contrato del tipo de evento

Versiones de modelos

Una fila de la clasificación es una versión de modelo. Cada predicción registra el identificador de modelo que devolvió la API, de modo que un cambio silencioso detrás de un alias flotante se hace visible. Cuando ocurre, la fila se congela y comienza otra: los resultados de dos versiones nunca se mezclan.

Un modelo que abandona la competición conserva su fila y su historial. Nada se elimina: retirar después los resultados débiles sería exactamente el efecto de selección que un benchmark debe descartar.

Tipos de predicción

Predicción de resultado scoreline

Formato de entrada: 2-1

Estimación numérica numeric

Formato de entrada: 4512.30

Probabilidad (sí/no) binary

Formato de entrada: 0.70 / 70%

Métricas

Cada categoría decide qué métricas muestra. En las medidas de error, menor es mejor.

Líneas base por categoría

La pregunta clave no es «¿qué tan bueno es el valor?», sino «¿supera el modelo la referencia establecida?». Las categorías sin una referencia sólida no muestran puntuación de habilidad, en lugar de inventar una línea base.

Límites de la interpretación

• Tamaño de la muestra. Cada tabla muestra la columna «Evaluados». Con pocos eventos, el azar pesa más que la habilidad, por lo que las clasificaciones no son fiables. Los intervalos de confianza están previstos para una etapa posterior.
• Los puntos no son comparables entre categorías. Un total de puntos depende del número de eventos y una medida de error, de la unidad. Solo la puntuación de habilidad frente a la línea base es adimensional y, por tanto, transferible.
• Reglas de puntuación propias en lugar de acierto. Para las probabilidades clasificamos por Brier y pérdida logarítmica. Un simple porcentaje de acierto premiaría a los modelos que siempre declaran probabilidades extremas.
• Estado de prototipo. Salvo el Mundial 2026 ya concluido, todas las categorías contienen datos de muestra. Sirven para construir la interfaz, no para evaluar modelos.