Show HN: Magistrate – Plaintext legal contracts for developers (magistrate.khanna.law)
I made this because I think that if contracts were written in plain text files and managed more like software, from version control to IDEs, lawyers would work more quickly and intelligently for their clients, saving them money.
But the entire practice of transactional law is stuck on Microsoft Word. My clients are mostly technology companies with an appetite for innovation. With their encouragement, I am moving my own legal practice away from formats like Microsoft Word and into plain text.
Electronic signatures of plain text contracts is the starting point for that effort. The MVP is this developer API.
If the reception to this product is positive, I'll continue to release the products that I build. In time, my hope is that plain text will supplant Microsoft Word in the drafting, negotiation and execution of contracts.
106 comments
[ 3.3 ms ] story [ 179 ms ] threadAlso, I like the pricing page-- especially this approach: "Keep this low, early adopter price as new features are added." -- I'll keep this in mind for my own products, I think customers will appreciate being grandfathered in to low prices-- it's a win-win.
To the developer-- Do you have any advice for the following scenario: You invite another developer to work on your product, such as Magistrate. How do you go about ensuring legal compliance with that developer--
A. That they make the appropriate work contributions to obtain the agreed upon equity level. I.e. you worked 1600 hours on the product this year, they worked 400 hours. You've both logged these hours. In terms of the work, you offer 25% equity, but that's if they also put in the same amount of money you've put in (such as for various IT, marketing, administrative costs), as an example of: You retaining 75% equity and giving 25% equity to a partner.
B. That they respect IP protections of the product (i.e. they don't immediately go off and try to build a competitor)
I mean could you, for example, sign a document with your friend, have them purposefully violate it, and then take them to court to prove that the courts will back up the document?
I am asking because the existing digital signature solutions have the benefit of having proved that they are accepted in court.
(former lawyer here and didn't know the answers either!)
However, I am asking is this particular way of signing considered a valid digital signature in the legal sense. I could get a technical response, but how much more powerful would it be to demonstrate that it already has?
As an individual I might risk a project on an unknown signature provider, but I can't imagine saving the money on a "proven" signature.
I say this only because I can see -- IAMAL -- that there are many ways around this. "Yes, but we subsequently changed the deal when I emailed you and said 'we have to delay it," and then you said 'that's terrible. ok.'" etc
That is entirely sufficient to legally demonstrate agreement. An in person conversation is too, but it leaves less evidence.
> I say this only because I can see -- IAMAL -- that there are many ways around this. "Yes, but we subsequently changed the deal when I emailed you and said 'we have to delay it," and then you said 'that's terrible. ok.'" etc
Yep, the purpose of a signature is to have a method of indicating your agreement on the exact version of the document that is being agreed on.
How do you prove it was me that added my name?
With a physical signature you can theoretically compare it to previous signatures using pressure analysis etc, but that’s not a thing for a text string.
> Is there a legal way to demonstrate the legally binding aspect?
I wasn't actually aware that a signature is required for something to be legally binding. I thought all contracts are "legally binding" as long as one party agrees to provide something in exchange to another party. If I send an email that says "confirmed, let's move ahead" then this should be as good as a signature, no? AFAIK, someone's signature is basically just an affirmation for a court to say "do you solemnly swear this is your signature?".
I could be wrong.
That entirely depends on the jurisdiction.
Legal software generally isn't portable across countries due to subtleties like this.
There are jurisdictions that do not accept any electronic signatures whereas in others an email response saying "go ahead" or even a verbal agreement on the phone (which leaves no permanent record) counts as "the parties have contracted".
I'm wondering about the use case of developers actually wanting to send out contracts (on behalf of their employer, I assume). Is this something that your clients who are software developers are asking for?
Disclosure: I'm a lawyer and software developer.
Edit: Correct a brain fart.
I'm surprised to see that common misuse (that I'd usually try harder to refrain commenting on) from a lawyer!
Again not just boring and nit-picking on something so common where I know what's meant; I was just surprised that a lawyer (i.e. someone so familiar with it) would make that error. (Or use it with that (proscribed) meaning, if you prefer.)
This is one of the reasons why lawyers use templates, as a defense against brain farts where we write "disclaimer" instead of "disclosure."
> It's a plain text file so there is no formatting. You can add extra spaces or tabs if you would like and they will appear in the final contract.
So I guess it's up to each drafting lawyer to come up with their own formatting conventions. I think that is potentially a recipe for disaster, unless the intention is that the plain text contract will only ever be edited by way of an interface that enforces standardised formatting conventions (which seems like it defeats the purpose).
Don't get me wrong, the current process of lawyers marking up each other's Word documents is a pain, but at least with Word when you go to enter a new clause it will by default have the same formatting and styling as all the other clauses. Maybe I'm missing the use case though.
Also, just to mention, version control and e-signatures are already available to transactional lawyers, though the solutions are imperfect and I guess they aren't available to everyone (I presume the software is expensive).
I don't mean to be critical or unduly sceptical by the way. I personally would love a move to simple, text-based processes for drafting and negotiating documents. But my own experience tells me that non-technically-inclined lawyers and clients would be slow to adopt a solution like this.
One of the directions I may take this is to allow those things you mention like clause numbers and definitions to be specified, perhaps by some markdown flavor. As you can see, we already enforce one formatting convention: the signature block.
As this is developed, we may enforce other conventions. The Manual of Style of Contract Drafting (4th Ed.) [0] would generally serve as inspiration for me to the extent we enforce any formatting conventions.
[0] https://www.adamsdrafting.com/writing/mscd/
Maybe Markdown or reStructuredText would provide a starting point. But it would have to have a WYSIWYG editor.
There's a couple reasons why I wouldn't switch to Magistrate at this point:
1. eSignatures allows templating. Sometimes tacking on parties at the end isn't enough, because things like products or payment terms need to be parameterized inline.
2. Webhooks that allow taking actions when the contract is either rejected or signed by all parties. It's also nice to be able to attach some metadata to the contract e.g. (a purchase order #) so it comes back in the payload with the web hook.
These may be use cases you don't want to cover yet, but thought I'd list some features I've been relying on as a developer building solutions in this space.
Both of your ideas are on the very near-term feature list.
> Is this legally binding? Yes, if you are in the United States. The Electronic Signatures in Global and National Commerce Act (ESIGN) together with the broad adoption of the Uniform Electronic Transaction Act (UETA) by 47 states ensures the validity of electronic signatures.
> If you are outside the United States, this product is not for you (yet).
I get that that's probably not a priority for a startup, but the risk in someone relying on this for contract-work getting burned by someone exploiting your platform is pretty great (i.e potentially unbounded downside), especially if the detection/response processes don't catch or can't properly identify the adversary.
I'm trying to account for the scenario where an adversary exploits a flaw that allows them to sign a contract on behalf of a client of the service at a time when audit trails aren't thorough enough for the client to repudiate a false signature.
Where do I invest?
An idea I had a couple jobs ago -- which I intend to develop now -- is the ability to encode logic into the templates so that the template can be used in all sorts of business situations.
I have forced our lawyers to use better technologies but then we end up with Microsoft word documents from opposing counsel. So back to Word it is.
There's a gravitational pull that is not worth us spending any % of a $1000/hr bill on; this is a scenario where doing anything different where they have to be trained is costlier than keeping the status quo, where that is a MSFT Word license the fraction of the cost of a billable hour.
It will be a long road, but it will happen sooner or later. I think we can make it happen sooner.
It's always seemed to me that git is the answer, but yeah, you'd need to prevail over the serious network effects of Word, deal with formatting (provision numbering, definitions, etc), and provide ways for lawyers to ignore the history or start from a clean "accept everything" slate at any phase of the negotiation. Not to mention all the back and forth happening over email in between drafts that can sometimes be valuable or even legally useful later on.
The main problem I run into is people using conflicting diff software (eg, you generate a blackline of two Word documents using ChangePro, but you forget to PDF it before it goes to the other side, so they put through some changes on the blackline document in Word tracked changes). These things can be avoided through sane configuration options. Maybe git is an objectively better solution but even if it is there is a huge local maximum problem.
Lawyer here: because your engineer's POV is wrong. I don't know what else to say. It comes from a lack of knowledge of how lawyers actually work and therefore what we actually need for our work. It is not identical to what software engineers need or want for theirs.
The drafting process is the area in transactional practice that least needs "disruption". The process is long-settled and fairly universal. Track changes are not "crazy confusing to parse", they're a simple and easy way to know who edited what and when. Version control? Basically meaningless for lawyers. The only version of the contract that matters is the most recent one, so we just need a way to track that. In actual practice we don't just revert back to some older version; that doesn't even make sense to someone who understands what we're doing.
What really needs disruption, or at least improvement, are contract management platforms. I've worked with all the major ones and they're all pretty bad and clunky in their own way (IME Ironclad is the least-worst but still leaves much to be desired).
If someone could develop a simple, intuitive system for extracting and recording certain agreement content and making that searchable (and transferable!), as well as storing and searching agreement documents generally, it would be amazing.
so every lawyer on earth is able to use word 100% of the time without ever losing data, removing a sentence or closing a comment by mistake ?
This is not an actual problem in real-world practice. Change tracking is easy and fairly universally understood. I see this idea from engineers that what lawyers do is try to slide in secret edits and a lawyer’s job is to be ever-vigilant for these secret attacks, but this is not how lawyers actually work.
Only non-lawyers imagine this is some huge issue that lawyers grapple with and for which they cry out for a solution. Again, it really would behoove any would-be saviors of the legal profession to engage with actual practitioners and listen to what their actual problems are, not what you strongly feel they must be.
that's wild. My experience editing word documents is that you have to have a dozen backups to be sure not to loose something due to basic keyboard / mouse manipulation mistake. I wonder what is their secret.
As a software engineer, when I imagine myself doing a lawyer's job, I would want a tool like this. But that misses the point. Good UX requires first being attentive to the actual problems expressed by users. Otherwise we end up with the pretense of empathy: projection.
That may be a good idea, but not because they’ll tell you what their problems are. Asking people what their problem is leads to responses like ‘faster horses’ instead of ‘cars’, and this whole Word situation reeks strongly of that.
1) change tracking is easy to use and universally understood 2) timestamps in document names solve the version problem, and 3) that emails traded back and forth work as a document history
does not at all mesh with my experience or with the complaints I hear from friends and family in the legal profession. Even just when I'm helping friends in software negotiate contracts, which usually just involves me, one other engineer, and one lawyer, changes pretty frequently get lost or go unnoticed. Versions frequently get mixed up (altho the blame for that usually falls on bad search engines in email clients). Lawyer friends have complained to me about conflicting timestamps and about larger documents with hundreds of changes being tracked that work slowly and are difficult to parse.
I definitely think engineers are too quick to throw a "one easy trick!" at a big messy problem like this that obviously has a bunch of social/network elements in addition to technical challenges, but saying that the current situation is functional for most participants doesn't really seem to be accurate.
that is exactly my experience with any shared document > 20 pages in word
Another lawyer here: This is correct. (To uniquely identify the most recent version, it's extremely helpful to hard-code the date and time into the file name and in a running header. EXAMPLE: "ABC-XYZ-NDA-markup-2022-01-31-1510-CST.docx" (or use UTC if dealing with other countries' time zones).
If multiple parties are mailing word documents back and forth (even with date in title), it becomes crazy.
You think J. Random Lawyer is going to learn, and use, git? ROFLMAO — half the lawyers around don't even know how to use styles in Word, and they think the way to add spacing between paragraphs is to leave a blank line.
I think you are talking about versioning executed contracts, in which case I kind of agree with you, though there are some corner cases where it would be helpful to track all the amendments/restatements to a contract over time.
But I do think versioning of drafts is important in all but the most basic negotiations because parties expect redlines with each draft and different parties may expect different redlines (because not all parties are necessarily recipients of all drafts, eg, if there are some discrete points being negotiated amongst a sub-set of the parties).
But as I have said in another comment, that kind of version control is already available to lawyers. And in general, I agree with you - the actual pain points for lawyers (and their clients) are not the ones that software developers tend to focus on when they talk about disrupting the legal sector. There are a lot of solutions in search of problems.
I do disagree about "Track Changes" though. That quickly becomes an incomprehensible mess. Better to avoid Track Changes (except in very small/simple agreements where you don't expect more than one or two turns, in which case it can be useful) and send a "clean" and redline version (based on the immediately preceding version) on each turn.
Also, mailbox full of back and forth emails with successive versions of document in attachments is also a version control system. It just needs better tooling.
Replying to add that there is a simple reason for this: Virtually every written contract includes an "integration" or "whole agreement" clause that states that the current version is the final version of the contract and that it supersedes any prior oral or written agreements between the parties.
It’s definitely possible. Adobe is a great example of a success story in the space.
Problem is that for plaintext, you need a benevolent billionaire to fund the lobbying.
I'm really starting to hate this. But what can any of us do?
If you were to pick a VCS for non-technical users (e.g. a group who historically just produce word documents), it would probably have to be a non-distributed system like SVN that allows for file locking. Conceptually, central VCS and file locking etc is much easier to understand for non-technical people than distributed VCS and merges in my experience; it's no surprise to me Word offers SVN style locking too for collaboration, which of course is anathema to the way git operates.
Git can for sure solve this problem, I just think its too complex to use for most Word Processor users, especially conflict resolution, and is generally ideologically opposed to providing features to lock shared documents down.
The users of law are normal people and companies that need to transact with untrusted parties.
Well-paid lawyers clinging to Microsoft Word are a cost centre to most businesses, much of which could likely be automated.
This isn’t necessarily a threat to the legal profession. See the history of accountants and spreadsheet software.
And they did. Saved several weeks of work on both sides per game.
Have a look at script-writing software and its auto-formatting. Some are actually open-source and could very well wipe the floor with some bloated, overpriced alternatives.
The scriptwriting community is incredibly anal about format so I think you could benefit from having a look at some of these pieces of software. Things like templates can be molded from community standards.
Kit-scenarist is particularly good but that's my bias as a loyal user for many years. And yes, I write screenplays ever so often.
I noticed that it seems to be limited to 50 contracts per month currently. Are there plans for larger tiers?
Second question: would you sign ndas since a lot of contracts are confidential?
First, yes, it's on our servers. But crucially, all parties also receive a copy of the fully executed contract via email once it's signed. So even if Magistrate were to someday disappear, the timestamped email in your inbox serves as evidence of the contract -- assuming your email provider doesn't go out of business as well.
There may be other ways of dealing with the "are you in business in 5 years" problem that we plan to explore as well.
If plaintext contract acceptance grows then one hopes that the middleman could be cut out and we could eventually see adoption of standard developer versioning tools adopted by in-house legal/IT teams to wrangle the plaintext contracts.
Other than plaintext contract tooling (which I know is a heavy lift), this workflow would then be no different than the current practice of emailing marked-up Word documents to each other directly until the clean copy is ready for execution.
Probably much the same way you "prove" anything: you present your evidence to the court (such as a signed PDF copy, or evidence that the parties acted as if the agreement were signed, etc) and you swear to it under oath. Of course, the other party could do the same to allege that the contract was never signed. But lying to the court can have pretty severe consequences if you are caught, so in a civil case there are generally strong incentives not to do it.
You might also want to connect with 'kemitchell[1], also a former software developer who became an attorney. He recently launched a similar initiative to generate license terms for selling software[2]; essentially another initiative towards easier contract automation & management.
[1] https://news.ycombinator.com/user?id=kemitchell
[2] https://writing.kemitchell.com/2022/01/22/Fast-Path-1.0.0.ht...
Do you see this product serving the lawyer-lawyer use case, lawyer-individual use case, or to an individual-individual market?[0] As an individual, I feel like there may be a lot of friction in drafting and sending a contract for another individual to sign. The chain of custody/assurance of no editing is one aspect that would drive me to do this process through a lawyer (or any other document signing company, but I don't have any experience with them).
Can I request/propose changes to a document sent to me? Or is this more for final drafts to be sent for final signing? Being plain text, I imagine diffing could be very straightforward.
It seems to me there's an assumption that email access is enough to validate you are the person this is intended for. I wouldn't be surprised if other online offerings like this had similar assumptions, but I'm not sure if I agree with the premise. I would imagine an entity sending a contract could include a PGP key, and you signing it could also sign the message, but a lot of this seems like a post-signing check, not a pre-req to sign.
I like that there is a style manual that formats the draft. I know it exists as a guideline for non-digital uses too, but conforming to a standard in the digital representation should make sharing and templating more standardized. Not a question, just something that excites me as not-legal-expert person.
Do you think making a plugin for Microsoft Word that calls your website would be a middle-ground for moving people into your service?
I like how you mention IDEs as well. I truly do not know the current flow for making a contract, and assume it is that there are templates that you change to match the specific situation. Completing templates in a guided manner seems like it could be a big deal, especially if there are sub-templates for each variation that a section would have.
Overall, I'm excited. I think the legal system has a lot of pain points for lawyers and individuals alike. Some of those can't be fixed, but tech can definitely solve some, and I think this is one of the problems tech CAN help with.
[0] Lawyer in this case can also mean a business' or other entity's legal counsel.
You won't likely divorce lawyers from their beloved Word anytime soon. But your approach of plain text API is not what I would call a "solution" but a mere building block that may be used in a future solution. Law firms and sole practitioners will prefer something already finished, an end product. So I would call what you called "MVP" an "advanced feature", whereas your basic solution is still not there until it has a GUI (which may have to look like Word?).
I personally love plain text, but legal documents have structure that ought to be dealt with in a solution for the future. The question is how to do that, and layout/formatting - while good for rendering - is not good for representing that structure.
It's good that you are working on innovating in this space; I would encourage you to talk to customers and to learn about the products in this space [5,6]. Some must-have features like templating have already been mentioned here.
[1] https://mena.thomsonreuters.com/en/products-services/legal/c...
[2] https://www.trustradius.com/contract-management
Plain text does seem to me to be the near-ideal format for legal documents, as it's most likely to be readable for the longest time. I can still easily read plain-text documents created 30 years ago. I can't say the same for WordStar, Wordperfect, or other long-forgotten word processing formats.
Further, they had document management systems that were WP savvy, are notoriously loathe to upgrade systems that are working, however badly. Any money spent on systems doesn't get distributed to the Partners. It's a very direct incentive.