Por qué ObligationFirst es diferente de LegalRuleML y Akoma Ntoso

Nota: esta publicación fue revisada tras el lanzamiento de la versión v0.5.0 el 25 de julio

Cuando presentamos ObligationFirst, dijimos que no era el primer intento de hacer que el derecho fuera legible por máquinas, pero que sí era, hasta donde sabemos, el primero construido para agentes. Afirmarlo es fácil; demostrarlo, más difícil. Esta publicación es esa demostración, contrastada con la especificación actual (v0.5.0) y no con las intenciones originales.

La comparación se hace con los dos predecesores más influyentes: Akoma Ntoso, el estándar OASIS para documentos legales, y LegalRuleML, el estándar OASIS para las reglas que esos documentos expresan. Ambos son maduros. Ambos funcionan bien para las audiencias para las que fueron creados. Ninguno fue diseñado para un sistema que debe decidir si puede actuar en este preciso momento, y esa diferencia se refleja en las decisiones de campos.

Para qué sirven los predecesores

Akoma Ntoso es un vocabulario XML para documentos legislativos y judiciales: secciones, artículos, párrafos, referencias, enmiendas, firmas. Es un Estándar OASIS desde 2018 y se usa en producción en el Senado italiano, el Congreso brasileño y el parlamento keniano, entre otros. Es excelente para representar lo que es un documento legal y cómo sus partes se conectan con otros documentos.

LegalRuleML es el estándar OASIS para representar normas legales, construido sobre RuleML. Aporta operadores deónticos explícitos (Obligación, Permiso, Prohibición, Reparación) y gestiona la derrotabilidad mediante DefeasibleRule y jerarquías de excepciones. Es la capa de reglas que se sitúa, conceptualmente, por encima de la capa documental.

Estos estándares son maduros y útiles. Cuando ObligationFirst se vincula a ellos, queremos ser explícitos al respecto. Cuando diverge, la divergencia es deliberada, y la audiencia es la explicación.

La diferencia de audiencia

Akoma Ntoso fue diseñado para parlamentos, tribunales y las herramientas de tecnología legal operadas por humanos que procesan su producción. La granularidad refleja eso. Una sección es una sección. Una enmienda es un cambio rastreado. La fidelidad importa porque los consumidores son redactores legislativos y abogados.

LegalRuleML fue diseñado para motores de razonamiento legal y la comunidad de investigación que los construye. Es expresivo por diseño: puede codificar relaciones deónticas complejas, reglas derrotables y jerarquías de excepciones, porque sus consumidores deben manejar casos límite de la misma forma en que lo haría un abogado cuidadoso.

ObligationFirst está diseñado para un agente que decide si debe realizar una acción y cómo hacerlo. Ese agente necesita saber: ¿me aplica este deber?, ¿qué exige?, ¿es exigible hoy? y ¿qué respalda la cita? El presupuesto de expresividad se destina a campos operativos, no a codificar cada matiz que un futuro motor de razonamiento pudiera desear.

Lo que ObligationFirst no duplica

La señal más clara de intención es lo que el esquema se niega a poseer.

Cuando existe una codificación autoritativa en Akoma Ntoso, un registro de ObligationFirst la referencia en lugar de repetirla. El IRI del elemento de Akoma Ntoso viaja en el registro como un cruce tipado akn_uri, nunca como el identificador. eli_uri, urn_lex y citation cumplen la misma función para el European Legislation Identifier, urn:lex y la cita convencional. Las clases de entidad se vinculan a la ontología superior Semantic Arts gist en lugar de inventar una nueva.

Akoma Ntoso modela documentos. ObligationFirst modela el contenido normativo que esos documentos crean. El cruce entre ambos es explícito respecto a esa brecha: para of:Obligation, la columna de Akoma Ntoso indica "sin equivalente directo", porque Akoma Ntoso codifica texto y las obligaciones se derivan del texto mediante interpretación. Esa brecha es la razón misma de ser del esquema.

Granularidad, y su costo

En LegalRuleML, una sola disposición legal puede descomponerse en varias reglas, cada una con su propio operador deóntico, condiciones y estructura de excepciones. Eso es adecuado para el razonamiento, pero incómodo para un agente que necesita una sola respuesta.

ObligationFirst mantiene la obligación como unidad. Un deber, un registro, alcanzable en un IRI estable.

Pagamos un precio real por ello, que recientemente se hizo evidente. Mantener la obligación como unidad tienta a hacer que esa unidad sea demasiado gruesa. Nuestra propia implementación de referencia hizo exactamente eso: EveryAILaw publicó diez conceptos amplios (transparencia, supervisión humana, prevención de sesgos, etc.) como sus registros de obligación, de modo que 134 términos estatutarios colapsaron en diez. Las consultas devolvían una categoría cuando deberían haber devuelto un deber.

La solución, incorporada ahora en v0.5.0, fue un segundo tipo en lugar de uno más laxo. of:ObligationCategory contiene el concepto neutral respecto a la jurisdicción; las obligaciones se vinculan a su categoría mediante skos:exactMatch. Una categoría no lleva jurisdicción, ni titular del deber, ni término creador, porque nadie puede cumplir con una categoría. Dos leyes de distintas jurisdicciones siguen siendo comparables a través de la capa conceptual, mientras que la capa de deberes permanece fiel a lo que realmente exige cada ley.

Esa es la disyuntiva en su forma honesta. La conmensurabilidad entre jurisdicciones es genuinamente valiosa, y pertenece a su propio tipo en lugar de colarse dentro de la obligación.

Lo que ningún predecesor modela en absoluto

La mayor diferencia estructural no es una elección de campos. Es un hilo entero.

LegalRuleML modela la regla, no el asunto legal que depende de ella. No tiene representación formal de un procedimiento, una alegación o un fallo. Akoma Ntoso puede representar el documento de sentencia que produce un tribunal, pero no el asunto que lo originó como objeto consultable.

ObligationFirst añade of:Proceeding, of:Allegation y of:Determination. La separación entre alegado y determinado es el punto clave: una afirmación en un asunto legal está alegada hasta que se decide, y modelar eso como un indicador de estado en una sola entidad obliga a una clasificación prematura. Tres tipos preservan la distinción. Una alegación es lo que se afirmó. Una determinación es lo que se decidió. Un procedimiento acumula ambas cosas a lo largo de su vida.

Esto es lo que permite que un fallo se vincule al deber que interpreta. En las tres implementaciones activas hay actualmente 59 referencias de este tipo entre proyectos, y todas ellas se resuelven correctamente.

Estado, causa, y el salto adicional

Una ley puede estar vigente e ser inaplicable al mismo tiempo. Ambos hechos importan a un agente.

ObligationFirst los divide en dos campos planos en el instrumento. status registra el estado legislativo (proposed, enacted, in-force, amended, sunset, repealed, superseded, withdrawn). enforcement_status registra si los deberes pueden exigirse actualmente (routine, constrained, unsignaled). Son independientes, y cualquier combinación es válida.

Lo que el enum deliberadamente no incluye es la razón. No hay stayed-by-court, ni enjoined, ni pending-rulemaking. La causa reside en el hilo del procedimiento, como una determinación que se ancla a la obligación afectada.

Esto implica un salto adicional para quien quiera mostrar "suspendido a la espera de reglamentación" como una sola frase, y la especificación lo dice explícitamente. Asumimos ese costo a propósito. Las causas de inexigibilidad son abiertas: órdenes judiciales, posturas de agencias, pausas legislativas, acción ejecutiva, declaraciones de emergencia. Cada nueva causa implicaría, de otro modo, una extensión del enum y una migración para los adoptantes. Además, pueden aplicar varias causas a la vez, y un campo escalar solo puede contener una. Separar la causa es también lo que hace comparables a dos jurisdicciones, ya que ambas pueden estar en constrained por razones completamente distintas.

El patrón ha resultado sólido río abajo. PubLedge, de forma independiente, dividió sus propios registros de instrumento en status legal y estado editorial, y añadió un vocabulario de ciclo de vida a nivel de obligación que incluye never-operative, para un deber que fue promulgado pero cuyo instrumento de implementación terminó antes de entrar en vigor. Ningún predecesor expresa esto con claridad.

Sucesión y derrotabilidad

Akoma Ntoso gestiona el versionado mediante enmiendas y versiones consolidadas, con un grafo de enmiendas fiel al proceso legislativo. LegalRuleML lo gestiona mediante condiciones temporales sobre la regla.

ObligationFirst separa dos cosas que es fácil confundir. El reemplazo de un instrumento completo es supersedes, asertado de instrumento a instrumento tras la promulgación, con wouldSupersede para el caso subjuntivo previo a ella. La anulación a nivel de cláusula es defeats, asertada de término a término.

Esa segunda relación es donde conservamos más de LegalRuleML de lo que sugeriría una narrativa de "esquema más simple". defeats tiene dos subpropiedades, rebuts y undercuts, que recogen exactamente la distinción de LegalRuleML: un término "rebutting" afirma la conclusión opuesta, un término "undercutting" niega que la regla se aplique aquí en absoluto, sin contradecirla en otro lugar. No aplanamos la estructura de excepciones. La trasladamos de dentro de una regla a entre términos, donde un agente puede recorrerla.

Colorado es el ejemplo real. La SB 24-205 aparece registrada como ya no operativa, reemplazada por la SB 26-189, que entra en vigor el 1 de enero de 2027. La relación de sucesión se asevera, no se infiere, y una consulta filtrada por fecha devuelve el deber que estaba vigente en la fecha consultada. Nada se sobrescribe en el mismo lugar; el registro anterior permanece disponible para litigantes e historiadores.

El problema que ningún predecesor tenía

Ambos predecesores asumen un documento que se puede señalar directamente. Una federación de conjuntos de datos legales publicados de forma independiente tiene un problema que ninguno de los dos aborda: de quién es el identificador que prevalece.

La respuesta de ObligationFirst es que no prevalece el de nadie. Todo identificador de registro es local al adoptante, opaco y permanente, y las uniones entre conjuntos de datos se apoyan en cruces estándar en lugar de slugs compartidos. Cada editor declara su propia gramática de identificadores en un perfil legible por máquina en /.well-known/obligation-first-naming-profile.jsonld, que especifica el patrón de URI para cada tipo de entidad y qué cruces proporciona. La especificación valida ese perfil; nunca prescribe la gramática.

Esto es poco vistoso y es precisamente lo que hace que el grafo funcione. Tres conjuntos de datos mantenidos de forma independiente, 579 registros, sin registro central, sin renombrado coordinado.

La interoperabilidad es el objetivo

Ninguna de estas diferencias constituye un argumento en contra de LegalRuleML o Akoma Ntoso. Son argumentos a favor de diseñar un esquema en función de su consumidor.

Donde los datos se superponen, el mapeo está dentro del alcance y en parte ya está escrito. El cuarteto deóntico se alinea uno a uno con los cuatro operadores de LegalRuleML, y of:Reparation se mantiene como subclase distinta específicamente para preservar esa alineación. Los documentos de cruce transmiten la lógica de regla de un Término a una codificación de LegalRuleML a través de un campo lrml_encoded_as, aunque conviene ser precisos sobre su estado: eso está documentado en el cruce, aún no es un predicado en el esquema, y si conviene formalizarlo sigue siendo una cuestión abierta en la especificación. of:executableEncoding ya apunta a codificaciones de Catala, Blawx u OpenFisca, de modo que el trabajo de reglas ejecutables de esa comunidad se compone en lugar de competir.

Dos límites honestos. of:Reparation tiene, hasta ahora, cero instancias en las implementaciones activas, por lo que la alineación del cuarto operador está diseñada pero aún no puesta a prueba. Y los mapeos no son gratuitos y no siempre serán exentos de pérdida.

Esperamos que los despliegues maduros ejecuten varios esquemas a la vez, cada uno sirviendo al consumidor para el que fue diseñado. ObligationFirst es la superficie orientada al agente. Los demás siguen siendo útiles detrás de ella.

Qué significa esto para usted

Si está construyendo algo que debe operar dentro de un entorno regulado —un copiloto de cumplimiento, un proceso de auditoría, un panel orientado al regulador—, ObligationFirst está diseñado para sus consultas. Empiece por ahí.

Si realiza investigación rigurosa de razonamiento legal, o construye herramientas para redactores legislativos, LegalRuleML y Akoma Ntoso siguen siendo las herramientas principales adecuadas. Use ObligationFirst como la superficie complementaria donde se necesiten patrones de consulta orientados a agentes.

Si está construyendo infraestructura que otros adoptarán, la existencia de múltiples esquemas es una ventaja. Los puntos de interoperabilidad entre ellos son donde el ecosistema acumula valor, y las contribuciones (pull requests) a la capa de mapeo son bienvenidas.

El enfoque nativo para agentes es la contribución. La interoperabilidad es lo que lo mantiene útil a medida que el ecosistema cambia a su alrededor.

¿Tiene preguntas? Contáctenos o lea nuestra Política de Privacidad.