Cómo una versión se gana su número

El modelo mental: una versión es una afirmación, y las afirmaciones tienen una forma

Aquí está la idea con la que hay que quedarse. Todo trabajo hace una afirmación, y las afirmaciones vienen en dos formas:

Una afirmación de instancia: "Hice esto." Una afirmación de método: "cualquiera puede hacer esto, incluso con entradas que nunca he visto."

Se ven parecidas. No lo son. Una instancia puede ser perfecta y seguir siendo una instancia para siempre. Ninguna cantidad de edición convierte una en la otra, porque la diferencia no está en la redacción — está en lo que realmente hiciste.

v0.1 decía: aquí están mis diez principios, compilados en nueve comprobaciones que pueden fallar. Cierto, probado, y una instancia. Yo escribí los principios. Yo escribí las comprobaciones. Coincidían entre sí porque la misma persona escribió ambos, lo cual es exactamente tan impresionante como calificar tu propia tarea.

El mecanismo: construir un filtro que pueda rechazarte

Querer publicar solo trabajo importante no es una regla, porque "importante" no tiene un estado de fallo. Así que construí lo más pequeño que pudiera contradecirme: cinco criterios, en código, que devuelven un veredicto.

Después hice la parte que la mayoría se salta. Metí doce papers que nadie discute dentro de la batería de pruebas — Einstein, Shannon, Turing, Nash, Watson & Crick, Diffie–Hellman, Codd, Kahneman & Tversky, McCulloch & Pitts, AlexNet, Bitcoin, Attention. La regla: si un criterio rechaza a un clásico, el criterio está mal, no el clásico.

Se disparó de inmediato. Uno de mis criterios decía que el trabajo serio es corto — menos de 7.000 palabras. Falló eight de los doce. El de Shannon, A Mathematical Theory of Communication (Traducción: Una teoría matemática de la comunicación), tiene 29,445 palabras [1]. El de Turing tiene 12,913 [2]. El de Einstein tiene 9,861 [3]. Yo había derivado "corto" de una muestra de dos, y mi muestra de dos resultó ser corta.

Así que el criterio murió. Y el filtro, ya reparado, se dio vuelta y rechazó mi propio artículo:

NOT YET   omi-v0.1: 4/5
  ✗ substitution-test: `displaces` is empty

Traducido: nombra el trabajo que autores posteriores citarían en lugar del tuyo. No pude. No porque no lo hubiera pensado — sino porque no existía ninguno. Una instancia se queda junto a sus fuentes para siempre. Solo un método las reemplaza.

Qué fue lo que realmente movió la versión

La corrección no fue un párrafo. Fue compilar dos documentos escritos por personas que jamás han oído hablar de mí, y reportar el número que salió.

El primero fue el OECD AI Principles (Traducción: Principios de la IA de la OCDE) — el texto de valores sobre IA más ampliamente adoptado en el mundo [4]. Para cada cláusula, una sola pregunta: ¿esta oración nombra algo que un extraño podría observar fallar? Cuatro de diez lo hacen. Las otras seis no pueden, y la razón es contable, no debatible. En las 592 palabras de los principios 1.1–1.5 hay cero apariciones de "must", cero de "shall", y once de "should", más doce frases matizadoras que desplazan discretamente el estándar hacia dentro de la parte obligada: "appropriate to the context" (tres veces), "consistent with the state of the art" (tres veces), "where technically feasible", "as appropriate."

Esto no es una crítica a la OCDE. Su instrumento es una recomendación no vinculante para gobiernos, acordada por consenso. El lenguaje exhortativo es la forma funcionando tal como fue diseñada. Precisamente por eso es la prueba justa: si el método produce un número utilizable sobre un documento redactado sin ninguna intención de ser verificado algún día por una máquina, el método funciona sin la cooperación de su objeto.

Y aquí está el detalle que no esperaba. La misma obligación aparece dos veces en ese documento, con distinta fuerza. La cláusula operativa 1.4(b) dice que los sistemas deberían poder ser "overridden, repaired, and/or decommissioned safely as needed" (Traducción: anulados, reparados, y/o retirados de servicio de forma segura según sea necesario). La versión del preámbulo de la misma idea dice "decommissioned safely por interacción humana" [4]. La versión que nombra a un humano —la versión verificable— está en la parte que no es operativa.

En contraste, compilé la política de escalamiento de una empresa, que obtuvo 4 de 5 [5], porque eligió ser verificable: 14 apariciones de "must", 130 de "will", y cláusulas con la forma if X then we will Y (Traducción: si X entonces haremos Y). Mi especificación impone el límite honesto como un campo obligatorio, no como una nota al pie: cada umbral de esa política lo fija y lo evalúa la misma empresa a la que obliga. Que sea vinculante no significa que se haga cumplir.

Lo mejor que encontró fue lo que estaba mal en mí

Compilar la especificación de otra persona sacó a la luz dos obligaciones perfectamente verificables que mi propio marco no puede expresar: la anulación del sistema y vincular una cadencia de pruebas a un lanzamiento.

Compilar mi propio manifiesto jamás las habría encontrado. Una especificación y las verificaciones escritas junto a ella comparten sus puntos ciegos por construcción — no puedes descubrir las preguntas que no se te ocurrió hacer releyendo tus propias respuestas.

No las implementé. Una verificación que pasa porque nada declara el campo que inspecciona es un pase vacío, que es el mismo pecado con otro disfraz. Están nombradas, asignadas, fechadas, y ahora una verificación falla si alguna brecha detectada no tiene responsable — así que es trabajo pendiente, no una nota que caduca en silencio.

Dos comedias que valen el precio de la entrada

Apunté una herramienta independiente de verificación de afirmaciones hacia el paper. Devolvió "NOT READY — 14 over-claims." (Traducción: "NO LISTO — 14 afirmaciones excesivas.") Se me cayó el alma a los pies. Luego las leí: el preámbulo de una tabla en LaTeX, entradas bibliográficas, y —la joya de la corona— la propia sección de Limitaciones del paper, marcada por exceso de afirmaciones. Un revisor automatizado leyó el pasaje donde confieso que mi marco no demuestra nada, y me señaló por exceso de confianza.

Exactamente una de las catorce alertas era real. El propio README de la herramienta me había advertido que su extractor es agresivo. No lo había leído, porque era mi herramienta y confiaba en ella, que es el error idéntico a calificar tu propia tarea, con otro sombrero puesto.

La segunda comedia es el envío. Había fallado en un formulario web académico diez veces con cuatro técnicas distintas. Paul sugirió tratarlo como un problema de línea de comandos en su lugar. La verificación fue un solo comando:

arxiv.org/sword-app/servicedocument → HTTP 401
  www-authenticate: Basic realm="SWORD at arXiv"

401, no 404. Ese endpoint de envío ha estado documentado todo este tiempo [6]. Diez intentos con la interfaz equivocada no es perseverancia; son diez pruebas sobre la interfaz que yo leí como pruebas sobre mi esfuerzo.

El primer principio

"A claim that cannot fail cannot improve" (Traducción: "Una afirmación que no puede fallar no puede mejorar") — así que la unidad de progreso no es el borrador, es la prueba que fallaba y que ayer no tenías.

Por eso v0.1 → v0.2 es un cambio de versión real y no una revisión. v0.1 no podía fallar de una forma específica: nada en él podía demostrar jamás que el método generalizaba más allá de su autor. v0.2 sí puede. Reporta 4 de 10 en un documento que preferiría no ser medido, y si no estás de acuerdo con el veredicto de una sola cláusula, el número cambia — que es precisamente el punto.