I'm building https://uscodex.org. In a nutshell, the goal is to collect all US federal law in version control, and cross-link any references between different sections. Currently I have the US Code, CFR, ~30 years of public laws and congressional bills and 25 years of executive orders.
Actually using raw git repos as the main data store which has worked out great since the US Code changes very little between new releases and so it compresses very well. Also makes it easy to generate diffs of sections: https://uscodex.org/usc/d/119-100/119-102not101/16/2201
Hoo boy. It's an awesome idea, don't get me wrong - and it's work that should definitely be done. But I've worked professionally in this space and it is wildly complicated. I've never seen how things are done on the federal side, but US states have various modes of "electronic filing" for rules and codes - and there's a ton of complexity.
It's the kind of thing that sounds insanely boring on the surface, but there's a lot of interesting problems to solve, lots of coordination between various parties, lots of "deep state"[0] politicking - and so it becomes a surprisingly cool area to learn about and work in, and really matters in a way that many software projects do not.
Best of luck - it's a cool problem space.
[0]: I use "deep state" here somewhat ironically, but also just in the literal definitional sense: "people who are not elected but who work for the government and are surprisingly important". 0% intent to use it in the often insulting manner of popular discourse.
Thanks! Super interested in hearing more about some of the battle-scars you've acquired from working in the space if you're open to sharing? Very early in the journey here, so still have a ton to learn!
So far, it seems like the federal space is relatively well-behaved compared to your experience with states. Most agencies standardized on the USLM schema[^1][^2] in 2013. Before that, it's a hodge-podge of XML and plain-text sources.
Also, FWIW, my interactions with federal agencies so far have been insanely positive. When I reported the error I found in the US code at 9pm, a staffer from the OLRC verified the issue and got back to me by 7am the next day, more efficient than most private sector organization's I've interacted with!
I am not sure how much I'm allowed to say publicly between NDAs and contracts and all that fun stuff (I may already be over the line, tbh) - but feel free to drop me an email at the address in my profile and I can point you to a few things that might be of interest.
We need something like git blame to show how legislation evolved over time, who passed it, which lobbyists pushed for or wrote it, who benefited by receiving more money/power, and who had to foot the bill.
This is becoming urgent, now that there's almost no correlation between what laws get passed and their popularity with the public, since Congress mainly only listens to moneyed interests:
Thanks! The primary goal is to make it the best place to research US federal law. All the features I have currently (cross-corpus search, version diffing, backlinks, law lineage, etc) will stay free and open.
Audience is primarily lawyers and legal researchers in fields that rely heavily on statutory law (tax, bankrupty, immigration, etc). I'm blessed to have a plethora of lawyers in my family/friends, so planning on using them as ~guinea pigs~ beta testers. If you (or anyone else reading this) think this is something you might use, I would love to talk more! seb@uscodex.org
In terms of monetization, I'm not really sure yet. My hosting costs are very cheap at the moment, so I'm not in any rush there, but I'm imagining I'll build in some more premium features like an API (for other legal-techs), change monitoring (for anyone relying on specific statutes in their work) or team research features (shared bookmarks, notes, collections etc). Open to suggestions here too! One very cool thing about my data pipeline is I've essentially built a connected graph of federal law with tens of millions of edges across millions across hundreds of thousands of sections, and I think there will be a lot of powerful applications of that dataset
> a connected graph of federal law with tens of millions of edges across millions across hundreds of thousands of sections, and I think there will be a lot of powerful applications of that dataset
I am mostly curious because I built similar graph, but in different domain, so I am wondering what are the applications and what would be go to market strategy.
Yeah, it's a good question, let me know if you figure out a good answer :)
Honestly, my focus right now is to make the site useful rather than profitable. This is a side-project that spawned out of needing something like this for my own research, so haven't figured out how/if I'll monetize it yet. The one idea I have related to the graph structure that I think could be valuable right now is letting users "subscribe" to particular sections of the law, with alerts for when there are new bills in Congress that might affect or alter it. The graph currently goes from bills > public laws > USC > CFR, so users could monitor a regulation and get notified as a bill moves its way through congress
- producing social impact for goodwill and marketing which may materialize into leads eventually: use my platform to solve problems and remove pain points for free, and maybe eventually build paid services on top
The cross-referencing between different corpora has actually been very helpful. I was able to find a typo in the notes to a US Code section through it and submitted it to the OLRC. They fixed it, so now I will forever be bragging about having fixed an error in the US Code haha
1) How much do you know about Policy Genius? Perhaps their trajectory could be instructive in what went well / wrong?
2) What do you think about adding a search for public equities? Type in AAPL, NVDA, etc.. and then UScodex delivers a code analysis that could surface relevant regulatory milestones / capture. If it works this could be a professional insights tool and/or "risk and compliance" software.
The constant "By the way..." from Alexa drove me nuts.
If you say "Alexa, stop by the way", it'll get the device to stop responding with follow-ups for ~24h. I ended up creating a routine that runs every night at 4am to lower the volume to zero, automatically say "stop by the way" to the device, and then raise the volume a minute later, and Alexa has stopped with the follow ups
I just discovered this today, but if you whisper to your Echo, it will skip all of the "by the way" BS (it will also reply in a whisper, which is kind of creepy, but you win some, you lose some).
I've been tickled by the idea of a follow-up version, Send Me To Hell, where users instead throw their phones _downward_. High scores are awarded based on the maximum speed achieved as the phone hits the ground.
The second example for each language sample where the generated squid ends up being “B4aajs” essentially reads as “P0ooop” to a Swedish speaker.
Which is fine, they don’t propose to filter “bad” words in other languages, but kind of funny when that’s one of the highlighted examples, right next to the goal of filtering words. Goes to show how hard it is to filter profanity generally for international audiences
Could you just remove vowels and hit 99.9% of profanity in all languages? Ditto for removing their 0-9 equivalents, if you're really worried about it. Quick out of the box support for that via being able to define a custom alphabet.
Well until we figure out a way to remove pattern matching from humans... use GUIDs if that's an issue. Removing vowels fixes "spelling almost all bad words explicitly", though I'm open to being proven wrong with fun new swears in exotic (to me) languages :)
The problem of "pick any N symbols that don't make any profanity in any language across all time" isn't what this is solving, nor should it have to. Take the same concept but use whitelisted words to build the token if you're that adverse to computer generated, fill in the blank naughty words. Keep "pen" and "island", among other things, off that list ;)
EDIT: My reply below is wrong - you _can_ deal with in-flight requests with E-Tags as well using the if-match header. I had only seen them used with if-none-match. TIL.
E-Tags would probably not help here, because the client won't have a tag to send along with its request until after the original response returns. But the thing we're trying to prevent in the first place is multiple concurrent requests being processed.
The Idempotency-Key header[1] is probably a better fit, but that relies on the server implementing the spec, including properly dealing with multiple in-flight requests with the same header. I found this blog post[2] pretty good for exploring some of the implementation challenges.
The Common Paper app[1], though not quite a git workflow, has always struck me as being pretty close to how an software engineer might approach contracts:
1. An immutable set of standard terms, with variable references.
2. A collection of cover page variables, that modify the standard terms by reference.
3. A structured negotiation workflow, where users "propose changes" to the cover page variables with automatic "diff-ing" (redlining).
It's not a product targeted to software engineers, but has always appealed to me as a way to sneak in some engineering best-practices into the world of lawyering :)
Nisus Writer Pro [0] has been around for 40 years this year IIRC (IANANWP) and has a user base who can vouch for many of the features that HN readers want something to offer.
Actually using raw git repos as the main data store which has worked out great since the US Code changes very little between new releases and so it compresses very well. Also makes it easy to generate diffs of sections: https://uscodex.org/usc/d/119-100/119-102not101/16/2201