Encontrar el nombre del problema

Construir el parser fue un hito importante. A partir de Markdown podía obtener un Abstract Law Tree —un ALT— que representaba títulos, capítulos, artículos, fracciones e incisos como nodos de una estructura jerárquica.

Si vienes de la primera parte, este es el momento en que el modelo mental que dejó Codexivo deja de ser una analogía y empieza a toparse con los límites reales del dominio.

La conclusión parecía obvia: usar el ALT como la representación canónica de una ley.

Y entonces llegaron las reformas.

Una reforma no es una ley completa

Una versión publicada de una ley describe un estado completo. Puede contener cientos de artículos y miles de nodos. Una reforma, en cambio, normalmente publica solo las partes que cambian.

Imagina una ley base:

Ley completa
├── Artículo 1
├── Artículo 2
├── Artículo 3
│   ├── Fracción I
│   ├── Fracción II
│   ├── Fracción III
│   └── Fracción IV
├── Artículo 4
...
└── Artículo 500

Y ahora una reforma que únicamente modifica una fracción:

Artículo 3
└── Fracción IV
    └── Nuevo texto

Ambos documentos pueden convertirse en árboles, pero no son árboles comparables de forma directa. Uno representa un estado completo. El otro representa una instrucción parcial para cambiar ese estado.

La operación que necesitaba era conceptualmente sencilla:

Ley base
    +
reforma
    =
versión consolidada

Implementarla, no tanto.

El parser dejó de ser el problema

El parser ya hacía su trabajo. El obstáculo ahora vivía alrededor del modelo:

• ¿cómo encuentro el nodo equivalente dentro de una ley enorme?
• ¿cómo represento el contexto que una reforma omite porque “no cambió”?
• ¿cómo mantengo una identidad estable cuando cambian textos o numeraciones?
• ¿cómo expreso la vigencia temporal de un contenido?
• ¿cómo preservo metadata, referencias y relaciones?
• ¿cómo describo una modificación como una operación y no como un árbol incompleto?

Si el ALT se convertía en el modelo propietario de todo el sistema, no bastaba con tener un árbol. También necesitaba construir su ecosistema: serialización, persistencia, identificadores, consultas, diff, patch, versionado, referencias y herramientas de validación.

La intuición importante fue esta: no estaba frente a un problema de parser. Estaba frente a un problema de representación legislativa versionable.

Pero todavía no sabía que así se llamaba.

Buscar sin vocabulario

Mi primera investigación fue la que solemos hacer cuando apenas entendemos el problema: buscar frases que describen síntomas.

“formatos para documentos legislativos”, “versionado de leyes”, “legal document schemas”, “representación estructurada de legislación”, “proyectos para consolidar reformas”.

Los resultados eran un poco de todo: repositorios abandonados, papers, prototipos, especificaciones parciales y soluciones demasiado específicas para un país, una cámara legislativa o una plataforma concreta. Había información interesante, pero no una dirección clara.

El problema no era que no existiera conocimiento. El problema era que todavía no tenía el vocabulario del dominio.

Y sin vocabulario es difícil encontrar lo que ya fue pensado antes.

La IA como puente de investigación

Aquí un asistente de IA fue especialmente útil, aunque no de la manera espectacular que suele venderse.

No “resolvió” el sistema ni escribió mágicamente el consolidado. Lo que hizo mejor fue ayudar a convertir una descripción informal en conceptos reconocibles por un dominio especializado.

La pregunta cambió de:

¿Cómo construyo esto?

a algo más preciso:

Necesito representar documentos legislativos estructurados, conservar la identidad de sus partes, asociar metadata y relaciones, manejar versiones temporales y expresar modificaciones entre documentos. ¿Existen estándares diseñados para este problema?

De esa conversación e investigación apareció un nombre: Akoma Ntoso, también conocido en el ecosistema de estándares como LegalDocML.

Ese momento fue más importante que encontrar una librería. De repente ya no estaba intentando inventar, desde cero, cómo modelar legislación. Estaba aprendiendo un lenguaje que décadas de trabajo institucional y técnico ya habían desarrollado.

“Ah, esto ya existe”

Akoma Ntoso define una representación XML para documentos parlamentarios, legislativos y judiciales. Pero su valor no es simplemente “usar XML”.

Aporta conceptos para lo que justamente estaba intentando diseñar:

• estructura del documento;
• metadata;
• identificadores y referencias;
• temporalidad;
• relaciones entre documentos;
• modificaciones legislativas;
• elementos semánticos del dominio.

El problema se reescribió en mi cabeza.

Antes:

¿Cómo diseño un sistema que represente legislación?

Después:

¿Cómo proyecto la información que ya extraigo hacia
un estándar que resolvió gran parte del modelo?

La diferencia es enorme. No elimina la implementación; todavía no existe un pip install mexican-law-consolidator. Pero evita tener que diseñar a ciegas todas las piezas fundamentales.

El nombre como una herramienta

Esta experiencia reforzó una idea que me parece útil para trabajar con IA: una de sus mejores funciones no es producir código, sino servir como puente entre “sé lo que necesito” y “sé cómo se llama lo que necesito”.

Problema descrito en lenguaje natural
        ↓
conceptos del dominio
        ↓
vocabulario correcto
        ↓
estándar, literatura y experiencia acumulada

Encontrar un buen nombre para el problema no es solo un ejercicio de etiquetado. Cambia los resultados de búsqueda, las preguntas que puedes hacer, las decisiones de arquitectura que consideras y la cantidad de trabajo que estás a punto de reinventar.

Encontrar Akoma Ntoso no terminó el proyecto. Me dio algo más valioso: una especificación sobre la cual pensar.

En el siguiente artículo entraré en la parte técnica: por qué parsear una ley no equivale a parsear texto, cómo conviven ALT y Akoma Ntoso, y por qué una reforma se entiende mejor como una colección de operaciones que como otro documento completo.