Alan Yahya opens with the comparison every programmer makes: a developer can point at any line of code and see who wrote it, when, and what the file looked like on any past day. A lawyer reading a federal statute usually can't, not without an afternoon in the notes at the foot of the section.
His project is essentially git for the US Code, and the interesting part is why that's harder than it sounds.
Why law is not a repository
A commit is a diff. A statute is a diff plus two things git doesn't have: an effective date and a scope.
The effective date is often not the date of enactment. Sometimes it's in a separate note, sometimes in the amendment itself, and where Congress says nothing the default is enactment. Scope is worse: a law can reach backwards, changing the answer for cases that were filed before it passed.
Yahya's example is the definition of a small business debtor in 11 USC § 1182(1). In 2019 the threshold was set; the CARES Act raised it to $7.5 million in March 2020 as a temporary measure; it lapsed in March 2022; in June 2022 Congress restored it for two years, for cases commenced on or after March 2020 and still pending — reaching back over the gap. The higher limit expired again in 2024, and after the 2025 adjustment it stands at $3,424,000.
For a case filed in May 2022, the release point printed at the time gives the lower limit. Only a later Act changes the answer. A versioned text that shows you "the law as of May 2022" is therefore not wrong so much as incomplete: it's missing the fact that a later law went back and rewrote the answer for that date.
That's the difference between version control and legal history. Git tells you what the file said. Law needs to tell you what governed, for which facts, and when that changed.
The AI failure mode is temporal
This matters more now because so much first-pass legal research runs through language models, and models are bad at exactly this.
Yahya cites a 2026 Technical University of Munich study with two findings: models apply rules that were superseded after their training cutoff, and they prefer the newer provision even when an older one governs the facts. One model answered 24% of post-cutoff questions correctly on its own, and 87% when the relevant statutory text was retrieved for it.
That gap is the argument for retrieval — but retrieval of the right-dated text, not just the right section.
There's a second result that should give anyone building legal tools pause. When the same group had a model apply amending laws to earlier versions, the output looked 93–99% similar to the official text, but only half of single amendments and a fifth of chains matched exactly. Experts found legally significant errors in the near misses.
Similarity is not correctness. A statute with one wrong word is a different statute, and 99% is not a passing grade.
How they validated it
The method is straightforward and the validation is the good part: for each pair of release points from 2017 onward, take the public laws enacted in between, apply their amending instructions to the older text in date order, and compare the result with the newer official version.
Of 365 changes across nine titles, 361 reproduced the next release point exactly. The other four are labelled with how far they could be confirmed. Each change carries the law and the effective date: 261 took effect on enactment by default, 72 by an effective-date note, 29 by a date in the amendment itself. One depends on an agency determination that may never come, and they leave it out rather than guess.
Using the official next release as ground truth is the right move. It's an external check, not a self-consistency test, and the four failures are published rather than hidden.
What's still missing
They're explicit about the gap: the system doesn't yet show a later law's reach back onto earlier dates, so for a case filed in the 2022 window it shows the lower limit without warning that the June 2022 Act changed the answer. Effective-date notes are read by pattern, with unusual wording falling back to enactment. Every change links to the law's own words.
That's an honest list, and it points at the real data model. The unit isn't the section text; it's the section text plus a validity interval plus a scope predicate. Anything less is a snapshot pretending to be a history.
The general lesson
The git analogy is seductive because it gets the interface right — point at a line, see its lineage — and the hard part wrong. Software changes forward. Law changes forward, backward, and conditionally on facts.
What Yahya built is closer to a temporal database than a repository, with the added complication that the "commit message" is a public law written in prose and the effective date is sometimes a separate document. The fact that 361 of 365 changes replay exactly is a genuinely good result. The four that don't, and the missing retroactivity, are the parts that would matter to a lawyer.
For AI systems reading law, the implication is blunt: a model that knows the text but not its lineage is not doing legal research. It's doing confident quotation.