Finding the Name of the Problem

Building the parser was an important milestone. From Markdown, I could produce an Abstract Law Tree — an ALT — representing titles, chapters, articles, numbered items, and sub-items as nodes in a hierarchy.

If you are coming from part one, this is where the mental model left by Codexivo stops being an analogy and starts running into the actual limits of the domain.

The next decision looked obvious: use the ALT as the canonical representation of a law.

Then amendments entered the picture.

An amendment is not a complete law

A published version of a law describes a complete state. It may contain hundreds of articles and thousands of nodes. An amendment, by contrast, normally publishes only the parts that change.

Imagine a base law:

Complete law
├── Article 1
├── Article 2
├── Article 3
│   ├── Item I
│   ├── Item II
│   ├── Item III
│   └── Item IV
├── Article 4
...
└── Article 500

Now imagine an amendment that changes only one item:

Article 3
└── Item IV
    └── New text

Both documents can become trees, but they are not directly comparable trees. One represents a complete state. The other represents a partial instruction for changing that state.

The operation I needed was conceptually simple:

Base law
    +
amendment
    =
consolidated version

Implementing it was not.

The parser was no longer the problem

The parser was already doing its job. The obstacle now lived around the model:

• How do I find an equivalent node inside a very large law?
• How do I represent context that an amendment omits because it did not change?
• How do I preserve stable identity when text or numbering changes?
• How do I express the temporal validity of content?
• How do I retain metadata, references, and relationships?
• How do I describe a modification as an operation instead of an incomplete tree?

If the ALT became the proprietary model for the entire system, having a tree was not enough. I would also need to build its ecosystem: serialization, persistence, identifiers, queries, diffs, patches, versioning, references, and validation tooling.

The important insight was this: I was not facing a parser problem. I was facing a versionable legislative representation problem.

I just did not know that was its name yet.

Searching without vocabulary

My initial research was what we usually do when we only partly understand a problem: search for descriptions of symptoms.

“Legislative document formats,” “law versioning,” “legal document schemas,” “structured representation of legislation,” “projects for consolidating amendments.”

The results were a mix of abandoned repositories, papers, prototypes, partial specifications, and solutions tied too closely to a particular country, legislature, or platform. There was interesting material, but no clear direction.

The problem was not that knowledge did not exist. The problem was that I did not yet have the domain vocabulary.

And without vocabulary, it is difficult to find work that has already been done.

AI as a research bridge

This is where an AI assistant was especially useful — though not in the spectacular way it is often marketed.

It did not “solve” the system or magically write the consolidator. Its most useful contribution was helping turn an informal description into concepts recognized by a specialized domain.

The question changed from:

How do I build this?

to something more precise:

I need to represent structured legislative documents, preserve the identity of their parts, attach metadata and relationships, manage temporal versions, and express modifications between documents. Are there standards designed for this problem?

Through that conversation and subsequent research, a name surfaced: Akoma Ntoso, also known in the standards ecosystem as LegalDocML.

That moment mattered more than finding a library. Suddenly I was no longer trying to invent, from scratch, how legislation should be modeled. I was learning a language shaped by decades of institutional and technical work.

“Oh, this already exists”

Akoma Ntoso defines an XML representation for parliamentary, legislative, and judicial documents. Its value, however, is not simply “using XML.”

It provides concepts for precisely the things I was trying to design:

• document structure;
• metadata;
• identifiers and references;
• temporality;
• relationships between documents;
• legislative modifications;
• semantic elements from the domain.

The problem rewrote itself in my head.

Before:

How do I design a system that represents legislation?

After:

How do I project the information I already extract into
a standard that has solved much of the model?

The difference is significant. It does not eliminate implementation — there is no pip install mexican-law-consolidator — but it avoids designing every foundational piece blindly.

A name is a tool

This experience reinforced something I find useful about working with AI: one of its best functions is not generating code, but acting as a bridge between “I know what I need” and “I know what the thing I need is called.”

Problem described in natural language
        ↓
domain concepts
        ↓
the right vocabulary
        ↓
standards, literature, and accumulated experience

Finding a good name for a problem is not merely labeling. It changes search results, the questions you can ask, the architectural decisions you consider, and the amount of work you are about to reinvent.

Finding Akoma Ntoso did not finish the project. It provided something more valuable: a specification to think with.

The next article goes into the technical side: why parsing a law is not the same as parsing text, how ALT and Akoma Ntoso coexist, and why an amendment is better understood as a collection of operations than as another complete document.