How a regulation becomes a graph

This is the page that makes this site more than a link farm, and it is the only content here that is unambiguously the project's own rather than a mapping of somebody else's text. It was built first, before any instrument folder, for three reasons: it already existed in publishable form, it makes instruments two through N cheap, and — given that ISO text cannot legally be republished at all — it is the only material that is itself the product.

Build the meta layer first. Every instrument built without it is built twice.

The shape of the answer

A legal instrument is not a document with structure bolted on. It is a structure — chapters containing articles containing paragraphs containing points — and it carries a second, entirely different structure on top: the concepts it defines, the actors it names, the obligations it creates, and the things it refers out to. Those two structures are not the same kind of thing and must not be modelled as the same kind of edge.

                    OUTWARD: ontology
                    concepts, definitions, entities,
                    obligations, risks, external terms
                              ^
                              |
   UPWARD: taxonomy    [ PARAGRAPH ]    the structural spine
   bullet -> paragraph -> article -> chapter -> instrument

The failure this avoids is the common one of modelling both as a single graph, where structural containment and semantic relationship become the same kind of edge. Then a query for what this article contains returns concepts, and a query for what this concept relates to returns paragraph numbers, and neither answer is useful.

The paragraph is the hinge. It is the unit that is small enough to be a real obligation and large enough to be worth citing, and it is the unit both structures attach to. Everything else in this method follows from putting the paragraph in the middle.

Paragraph as folder

The storage design is the model, not a serialisation of it. Every paragraph is a folder; every folder carries its own index; every index carries a hash.

structure/
└── article-026/
    └── paragraph-05/
        ├── text.md          -> positional hash + content hash
        ├── analysis.md      -> cached against the CONTENT hash
        ├── annotations.json -> cached against the CONTENT hash
        ├── references.json
        └── index.json       -> this folder's own index

if the folder has a hash, then we have a master index, and each folder has an index of the items that it has itself… that can be all read and maintained by the other end, but also by code.

The property that makes this worth the trouble:

   amendment arrives -> re-hash -> only changed paragraphs reprocess
   cost scales with CHANGE, not with SIZE

An instrument of 113 articles amended in four places costs four paragraphs of reprocessing, not 113 articles of it. For a corpus whose business argument is “the amendment is the business model”, that is the difference between a living resource and a snapshot that rots.

Two hashes, and why it is two

This is the single most consequential decision in the method, and it is one sentence long: one identity for the slot, one identity for what is in it.

A crosswalk mapping attaches to the positional hash and therefore survives revision. Attach a mapping to text and you have a spreadsheet that rots; attach it to a position and you have an artefact that survives amendment and can report that the text underneath it moved. That single decision is the difference between a maintainable multi-standard library and the usual dead mapping spreadsheet. The crosswalk consequence → · how it becomes a URL →

Provenance: the retrieval record

A quotation says this is what it says. A citation says this is what it says, this is where I got it, this is when, and here is the hash of exactly the bytes I read. This site only publishes the second kind, and the reason is a finding from the project's own probe of the AI Act in the wild.

So every instrument vault carries a source/ layer holding the retrieved bytes unmodified, a .sha256 beside each, and a RETRIEVAL.md recording where, when, by what method and with what response headers. For the EU AI Act that is official Formex XML from CELLAR. For ISO that layer is empty, and the page says why.

Authority anchoring: defer, don't decide

the answer to how you know you are linking to the right one is that you do not decide, you defer. An entity reference terminates at the identifier the Union itself publishes for that body rather than at a node we created and named.

Two consequences worth stating plainly. This site never becomes the authority on what an external body is — it points at the issuer's own identifier, which is both more honest and less work. And multilingual comes close to free for EU instruments, which are published in 24 languages against the same structure:

a concept has one identifier and many labels, one per language, so the concept is language-independent and the word is a projection of it.

Whether to actually ship that is an open question rather than a plan — it is a real differentiator and also a standing maintenance commitment. Q8 →

The acceptance test, and it is not passed yet

A method that holds exactly one instrument is not a method. The corpus supplies its own test, and this site adopts it as the acceptance criterion for this page:

The practical test is whether the same structure holds an ISO standard, a compliance framework and an internal policy without special cases. If it does, the pipeline is real. If it does not, what exists is an AI Act reader.

Prior art — this is not first

A site positioning itself as first in this space would be wrong, and would be caught being wrong. Named, with what each got right:

The rest of the method