Enunciar “evidencia antes que inferencia” como principio de un producto es fácil. Resultó ser una regla mucho más difícil de aplicar al equipo que lo construye.

La filosofía de Alaya incluye un principio de diseño con el que es fácil estar de acuerdo y difícil cumplir a cabalidad: comprender y cultivar la capacidad antes de implementar tecnología. Evidencia antes que inferencia. No dejar que la confianza supere lo que la evidencia respalda.

Es una regla razonable para lo que CIE le dice a un usuario sobre su propia trayectoria profesional. Resultó ser mucho más difícil aplicarla a la propia construcción de CIE, porque la tentación de dejar que un sistema, un informe o un fragmento de proceso reclame en silencio más certeza de la que se ha ganado no queda confinada a una sola capa. Aparece dondequiera que hay evidencia, incluida la que un equipo produce sobre su propio trabajo. Construir CIE significó redescubrir eso una y otra vez, en lugares que nadie fuera del equipo de ingeniería vería jamás.

Antes de que nada fuera código

El caso fundacional vino antes de que nada fuera código. El mecanismo central —que un cuestionamiento dirigido podía hacer emerger capacidad real que una persona ya tenía pero había perdido de vista— se probó primero a mano, en una búsqueda de empleo real, a lo largo de 13 a 15 postulaciones reales. Los puntos de prueba documentados y respaldados por evidencia pasaron de unos 5 a 26 en ese tramo, no porque se inventara nada, sino porque salió a la luz y se confirmó más de lo que ya era cierto. La primera versión funcional del mecanismo central de CIE no fue software. Fue disciplina real, con algo real en juego, antes de que se automatizara nada o se escribiera una sola línea de código.

El mismo modo de falla, con nuevos disfraces

El mismo modo de falla seguía reapareciendo una vez que comenzó la construcción, con nuevos disfraces.

Durante la implementación, un dato de estado —deferredContributions— se guardaba y se reconstruía correctamente. Duradero. Técnicamente cierto. Pero nada más adelante lo leía realmente, de modo que en su turno siguiente el motor de razonamiento se comportaba como si simplemente lo hubiera olvidado. La brecha se nombró sin rodeos: una base de datos puede recordar un hecho que la inteligencia ha olvidado en la práctica. Esa es exactamente la distinción que CIE está hecho para proteger —que la evidencia exista no es lo mismo que la evidencia sea comprendida—, descubierta mientras se construía CIE, dentro del propio código de CIE, sobre el propio código de CIE.

Ese error específico se convirtió en una regla general. Toda nueva salida estructurada que produzca el sistema debe ahora nombrar a su Productor, su Consumidor, su Efecto Conductual y cualquier evidencia sensible a una desconexión, o bien marcarse explícitamente como inerte. “Evidencia antes que inferencia” se convirtió en una lista de verificación de ingeniería literal, y no solo en un principio para lo que el producto les dice a sus usuarios.

La misma disciplina en la escritura

La misma disciplina apareció también en la escritura corriente. En un informe, una observación de muestra pequeña —un resultado de cinco— estuvo a punto de redactarse como una “tasa del 20 %” calibrada. Se detectó y se corrigió a “frecuencia real desconocida”. Es la misma regla que CIE aplica cuando se niega a que una sola frase débil produzca falsa confianza sobre la capacidad de alguien, solo que aplicada a una frase sobre el sistema en lugar de una frase generada por él.

Durante una auditoría independiente de uno de los tramos de trabajo, el auditor detectó el mismo exceso tres veces por separado, en tres piezas de trabajo sin relación: una prueba de reinicio mal rotulada como prueba de desconexión; un rastreo que afirmaba un efecto más amplio del que la prueba citada demostraba realmente; un hallazgo de confiabilidad sobre la salida del sistema que, deliberada y cuidadosamente, nunca se redondeó hasta convertirlo en una tasa declarada. Tres casos independientes de un informe que decía un poco más de lo que su propia evidencia justificaba: la misma enfermedad cada vez, solo que reapareciendo en la prosa sobre el sistema y no en la voz conversacional del propio sistema.

El lente vuelto hacia el proceso

El mismo proceso de revisión terminó por volver el lente sobre sí mismo. La auditoría de otro tramo encontró que un tramo completo de trabajo se había hecho con rigor, pero nunca se había armado un paquete formal de revisión que lo demostrara. Las piezas individuales eran correctas. Faltaba el tejido conectivo que habría hecho esa corrección demostrable ante cualquier otra persona. El patrón exacto de “parece completo, pero faltan las conexiones que lo probarían”, que CIE vigila en un historial profesional, apareció en cambio en el propio proceso de gobernanza del equipo.

Y debajo de todo eso: nada de ese registro de gobernanza —ningún hallazgo de auditoría, ningún informe de revisión, ningún riesgo señalado— se ha editado jamás en silencio para hacerlo desaparecer una vez escrito. Solo se le ha agregado información o se lo ha reemplazado con una referencia cruzada explícita a lo que sustituyó. Es la misma regla que la arquitectura de CIE aplica a la evidencia de cada persona —las correcciones no borran la historia, la amplían—, gobernando la manera en que el equipo que construye CIE lleva su propio registro de esa construcción.

El costo de mantener la regla

Nada de esto aceleró la construcción. Probar un mecanismo a mano antes de automatizarlo, negarse a que la versión automatizada tome atajos que la versión manual nunca pudo tomar, detectar el mismo exceso tanto en una frase como en una base de datos, y auditar el propio proceso de auditoría: todo eso es más lento que omitir cualquiera de esos pasos. Pero un sistema construido sobre la premisa de que la evidencia debe ir antes que la inferencia habría contradicho en silencio su propia razón de ser si no hubiera sometido su propia construcción al mismo estándar.