The fork's front door is no longer the AI assistant - it's a marketing site for a (fictional) law firm called Johnson Law.
MuseLegal/AI-Legal-Platform
MuseLegal is reshaping Mike into a law-firm portal, where a public-facing storefront fronts a permissioned workspace for clients, attorneys, and paralegals.
This fork takes Mike in a distinctly vertical direction: a platform built around how a law firm actually operates. The AI assistant isn't the headline anymore - the headline is the firm itself, with a public marketing site (for a placeholder practice called Johnson Law) acting as the front door and a permissioned workspace sitting behind it.
MuseLegal is the handle behind the work, and beyond that we don't have much to go on - no public identity signal, no stated affiliation. What we can see is the shape of the product they're building: distinct roles for clients, attorneys, and paralegals, each with their own view of matters and documents, and access rules enforced at the database layer rather than left to the UI to police.
The direction is coherent. If you tried this fork today, you'd encounter something that looks less like a general AI assistant and more like the skeleton of a client portal for a small-to-midsize firm - marketing on the outside, role-based matter access on the inside.
What's in it
- Law firm storefront A public landing page positions the product as a law firm's website (Johnson Law) rather than as an AI tool. The AI lives behind the front door, not on it.
- Role-based access for clients, attorneys, and paralegals Each persona gets a distinct key to the building. What a client sees is not what a paralegal sees, and neither sees what an attorney sees.
- Matter-level visibility Access is scoped per matter via a participants model - you see the matters and documents you're explicitly attached to, and nothing else.
- Database-enforced permissions Who can see what is a hard rule at the data layer, not a frontend convention. The UI can't accidentally leak a matter to the wrong user.
Direction
personasmulti-tenantbranding
Activity
✅ #1 Add many-to-many matter participant authorization model +135 23d ago self by
MuseLegal ↗ analysis ↗ GitHub ### Motivation
📝 MuseLegal splits the door: clients, attorneys, paralegals each get their own key 2 commits 23d ago multi-tenantsecurity draft
A new permissions layer reshapes the platform around a law-firm portal, where who you are decides what matters and documents you can see.
An access overhaul moves matter visibility from "the frontend hides it" to a hard rule the database itself enforces.
Threads of work (detailed view)
MuseLegal turns Mike into a law firm storefront
The fork's front door is no longer the AI assistant - it's a marketing site for a (fictional) law firm called Johnson Law.
MuseLegal splits the door: clients, attorneys, paralegals each get their own key
A new permissions layer reshapes the platform around a law-firm portal, where who you are decides what matters and documents you can see.
MuseLegal locks down who can see which matter
An access overhaul moves matter visibility from "the frontend hides it" to a hard rule the database itself enforces.
Pull requests (detailed view)
✅ Merged (1)
by
MuseLegal · opened 23d ago · merged 23d ago by MuseLegal