Sobre el proyecto
WeaveTrail es un banco de trabajo de investigación para el trabajo que sigue a una alerta de vigilancia de mercado. Un sistema de vigilancia puede señalar un día, una cuenta o un movimiento de precios; WeaveTrail aborda el siguiente paso, donde alguien debe mostrar qué registros produjeron el número, cómo se leyeron esos registros y bajo qué versión de qué regla. Establece claramente que no encuentra nada por sí mismo —el caso es nombrado por otro elemento— y que nunca decide la culpabilidad, infiere la intención ni recomienda una operación. Lo que devuelve es una respuesta computada por código fijo, la aritmética detrás de ella y el registro publicado detrás de cada valor leído.
El proyecto está dirigido a equipos de vigilancia en centros de negociación, revisores de cumplimiento en corredores o bancos, investigadores supervisores y auditoría interna.
El trabajo se organiza por autoridad en lugar de por ubicación, bajo el principio: la IA propone, una persona aprueba, el código decide y la evidencia lo respalda. Se describen cuatro capas. Un modelo restringido lee un archivo desconocido y propone el significado de cada columna, con su razón y su confianza, pero nunca edita una fila, computa un número ni es dueño de una respuesta. Una persona aprueba esa propuesta exacta, vinculada al hash de su artefacto, y cualquier elemento señalado por el modelo requiere una razón escrita antes de poder pasar. El código fijo compara los datos aprobados con umbrales aprobados y devuelve una de tres respuestas: el patrón se mantiene, no se mantiene, o la evidencia no fue suficiente para decirlo —siendo esta tercera una respuesta real y no un fallo. La capa de evidencia resuelve cada comprobación volviendo a las filas originales subyacentes, y un número cuyo origen no puede resolverse se omite en lugar de mostrarse.
Se describen dos reglas que residen en el código en lugar de en una guía: ninguna capa posee dos autoridades (la capa proponente no puede aprobar, la capa aprobadora no puede computar, la capa computadora no puede ampliar lo que se le entregó), y una respuesta conlleva las condiciones bajo las cuales es verdadera —verdadera para esta versión de esta regla, frente a este alcance aprobado, en los umbrales mostrados junto a ella.
El README ilustra el enfoque con un caso práctico fechado el 3 de septiembre de 2026, cuando el KOSPI 200 cerró ligeramente por encima del día anterior pero había cedido mucho más desde su propio máximo. Una persona fija la fecha, el periodo de comparación y qué tan grande debe ser un retroceso antes de que se ejecute cualquier cosa; el código fijo entonces realiza la aritmética e informa la posición del día en ese periodo; cada valor observado abre la fila publicada de la cual fue leído. Ejecutarlo nuevamente con las mismas entradas produce el mismo resultado. Señala que el periodo de comparación y los umbrales fueron elegidos por alguien que ya había visto el día, y presenta eso como parte de cómo debe leerse el resultado.
Sobre la repetibilidad, el límite se describe como un contrato más que como una convención: los registros se reconstruyen desde el archivo almacenado a través de la lectura aprobada, no desde nada que un modelo haya entregado; los precios y umbrales se comparan exactamente, nunca a través de un cociente redondeado; la huella digital cubre la respuesta en lugar de la ejecución, por lo que barajar las mismas filas la deja inalterada mientras que cambiar el alcance o los umbrales la modifica, y quién aprobó qué y cuándo se mantiene en el registro de aprobación; y una comprobación que no puede satisfacerse se detiene y no devuelve respuesta alguna en lugar de una más débil.
Una cadena va desde los registros almacenados hasta la evidencia, tratando cada traspaso entre componentes como un contrato; los componentes están coloreados por autor —modelo, persona o código fijo— para que el diagrama mismo responda quién decidió qué. El README indica que un proponente de casos delimitados está especificado pero aún no construido, y así lo declara.
Un banco de trabajo desplegado abre con un recorrido guiado de un caso en una página de reproducción: leer las filas reales, revisar lo que un modelo propuso que significan las columnas, aprobar esa lectura y el alcance explícitamente, ejecutarlo y abrir un resultado volviendo a las filas en las que se apoya. Un segundo ejemplo contiene una columna que el modelo no puede resolver, por lo que requiere una razón escrita antes de la aprobación, y aprobarla no autoriza el caso. Ejecutar el mismo caso aprobado nuevamente devuelve una segunda huella digital para comparar con la primera. Las aprobaciones y los resultados viven solo en la página abierta, por lo que una actualización comienza sin aprobación. Los casos son sintéticos excepto por los registros de mercado publicados, comprometidos bajo una licencia que lo permite con el origen y la recuperación registrados junto a ellos; por defecto, el paso de lectura se ejecuta desde fixtures almacenados en lugar de llamar a un modelo, y la configuración desplegada no lleva credenciales de modelo.
La documentación cubre arquitectura y límites de confianza, metodología, evaluación, limitaciones, normalización de cotizaciones diarias, despliegue, registros de decisiones y flujo de trabajo de contribución, varios de ellos también en coreano, además de una página de resultados de escenarios esperados tomados del propio motor. También describe una alineación con la guía de IA financiera de Corea, en vigor desde el 22 de junio de 2026, que sostiene que la decisión final y la responsabilidad recaen en una persona, aclarando que se trata de una alineación de diseño y no de una certificación, aprobación o respaldo. El código fuente original y la documentación tienen licencia Apache-2.0, y el proyecto requiere Node 22 o posterior.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.