This is a good example of a legislative workflow constraint.
Many legislative systems split bills into two buckets: metadata and data. Metadata fields for things like long title and bill number are commonplace. So too is the concept of the data itself being an opaque "payload" of metadata workflow checks.
The difference between the two is oftentimes a side-effect of the data/document duality. In order to leverage scalar types for indexing/sorting, duplicates of data in the text of the bill itself are created.
As soon as data is duplicated like this, consistency becomes an issue. In an effort to deal with this, some try to fully leverage data normalization by shredding bills into chunks in an RDB. That approach fixes one problem - consistency - but introduces another : you now have to worry about re-assembling a bill from the chunks, often preserving line/page number fidelity. Not easy!
The answer, in my opinion, is to preserve the sanctity of the document and make sure that any metadata extraction from the document is purely an optimization for workflow engine purposes and is never treated as "normative".