Show HN: Magistrate – Plaintext legal contracts for developers | Hacker News Reader

Show HN: Magistrate – Plaintext legal contracts for developers

magistrate.khanna.law

279 pointshkhanna101 comments

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.

Open articleView on HN

I used to be Director of Research at "one company that makes some of the leading legal information access products".

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

I thought lawyers were notorious for hanging on to WordPerfect for years after most everyone else had moved to Microsoft Word. If Word is now the de-facto legal document format, I guess that shows that accepted formats can change.

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.

Yeah but even that era is over now. The last time I saw a lawyer using Word Perfect it was a DOJ office maybe 8-10 years ago.

Lawyers needed six kinds of change markup, Word had one. Word added those, and more, lawyers switched.

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.

I have found it impractical to get lawyers to use anything other than Microsoft Word even when there are clear benefits (like online collaboration and shared version history). The reason they give is that they don't want a shared history (need to be able to clean document history for sending to external stakeholders) and that they know the other side will be using Microsoft Word anyways. So it's an equilibrium because they know the other side will use Microsoft word so then they have to use Microsoft Word.

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.

I have felt this exact pain. I think I know the path to overcoming Microsoft Word in the legal world.

It will be a long road, but it will happen sooner or later. I think we can make it happen sooner.

The domination of Word over contract negotiations seems crazy from my engineer's point of view. Just to get a contract through with a few changes, we go through Word diffs, manual review, and these crazy confusing to parse tracked changes. And then when everything is said and done, the lawyers produce a "final PDF" and we have to run another comparison in Acrobat.

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.

I think it's a matter of perspective. I don't think lawyers would typically view Word or ChangePro as being difficult to use - certainly, trying to get them to learn git would be a significantly greater effort. Outside of tech circles, I think that is true of clients as well.

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.

>The domination of Word over contract negotiations seems crazy from my engineer's point of view.

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.

> 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.

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 ?

A glib response to a glib question: frankly, yes.

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.

> A glib response to a glib question: frankly, yes.

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.

Try updating your version of Word, it sounds like you’re having some rather severe technical issues.

It's not a problem with word, it's a problem with anything that allows keyboard input. There's not a week where I don't see a mistakenly removed line for instance when checking a diff before commiting.

I'm going to name the phenomenon you're arguing against "UX projection".

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.

> 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

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.

That's funny, to me it reeks strongly of solutions in search of a problem.

I dropped out of law school before ending up in tech, but my parents are lawyers, my sibling is a lawyer, a large chunk of my social circle are lawyers, and I act as a go-between connecting my lawyer friends and family with non-lawyer friends who need some legal help (and also someone who speaks lawyer fluently enough to translate to normal people). All of this is just to say that the ideas 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.

> 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.

that is exactly my experience with any shared document > 20 pages in word

> The only version of the contract that matters is the most recent one, so we just need a way to track that.

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).

The moment you start doing this, git becomes the better solution, no?

If multiple parties are mailing word documents back and forth (even with date in title), it becomes crazy.

Nah, we do the same thing the parent does with file names. Works just fine.

> The moment you start doing this, git becomes the better solution, no?

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.

+1, Many developers can barely use git.

> 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.

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.

If you ever want to chat about your ideas on contract management, hit me up. I'm an NYC based software engineer, email in profile.

Another (transactional) lawyer here. While I generally agree with this, there are still circumstances in which something like a VC system would be useful. It's not uncommon for documents to go through a dozen or more (sometimes significantly more) iterations before being finalized. It would sometimes be useful to know in which version a particular fragment of language was inserted. But this can be worked out "manually", and indeed I think the real issue is that the value add of a VC system is probably small enough that it's just not worth any significant additional complexity. Having said that, I've long considered doing a lunchtime brownbag session on git, just to blow people's minds about what is possible.

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.

SharePoint has version control for Word documents. It's better suited for that than Git.

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.

> The only version of the contract that matters is the most recent one ...

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.

All you need is the political clout to get a court system or some big agency with quasi-judicial functions or a big city to adopt.

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.

> Problem is that for [most useful things], you need a benevolent billionaire to fund the lobbying.

I'm really starting to hate this. But what can any of us do?

Why does the editor matter, really? The lawyers can use Word if that's what they are best at. It seems orthogonal to the issue of managing digital signatures. The service can just as easily send an email with a hash/digest of the document version, the /s/ lines for all the signatories, and the document itself attached, as the "fully executed document"

The problem with git for general text work is that it is distributed VCS... even software engineers struggle from time to time with the concept that changes can happen in isolation on separate copies then merge back to the "master copy" in a conflicting way that must be solved.

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.

I think conversion between docx and plaintext is a possible solution, contracts aren’t known for fancy formatting

Outline numbering, cross-references and tables are all common features of contracts which are difficult to capture in plain text.

Also legal entity diagrams, picture appendices, and often math formulas with Unicode

Lawyers aren’t the users here.

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.

I got one set of lawyers to stop using word once. Large game platform holder would send us EULAs in word format with all sorts of nice legal placeholders. Then they had us plug those into the eula tool they developed for the the platform, which only accepted like 5 total html tags and no unicode or smart characters. We had an engineer spend about 2 weeks writing software to convert them and hand checking the eulas. Finally I had a chance to talk with legal on another matter and asked "could you just send this to us in plain text?" they responded, "oh hell we have one of our paralegals spend like 1-2 weeks each game making them really nicely formatted so they look good, does none of that work" me: "no", them "what formatting works", me: about 15 minutes explaining basic html in word parlance. Them "got it, we'll make it look good in Notepad.exe and send those from now on as .txt attachments to emails.

And they did. Saved several weeks of work on both sides per game.

Have you developed a standardised format for expressing a legal contract as plain text (including clause numbers, definitions, etc)? The example I see on your Docs page doesn't include any clause numbering, and says:

> 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.

Thanks for the feedback. I agree there's a lot that remains to be done on formatting, etc. This is, after all, just an MVP.

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/

what a fine line that would be to walk. to add all of these formatting abilities, you move further and further away from plain text. at some point, you've recreated the same issues as Word.

100%. I think about this balance constantly.

Indeed. I argue LaTeX is unreadable for a non-techie.

Maybe Markdown or reStructuredText would provide a starting point. But it would have to have a WYSIWYG editor.

You can look into YAML frontmatter for the things like clause numbers and definitions if you go the markdown path.

I'd suggest you prioritise defining a format earlier rather than later. The format / standard can evolve over time to accommodate the evolution of your product (that backwards-compatible evolution can be defined as part of the first version) but to go from no standard to any standard is much more difficult once people are already using the platform: you'll either break established workflows, or burden yourself with a lifetime of supporting unbounded backwards compatibility (because every client will, by virtue of writing integration code, unintentionally define their own standard).

Is there a legal way to demonstrate the legally binding aspect?

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.

Check out the FAQ there, helpfully answers these questions. tl;dr yes these are legally valid digital signatures.

(former lawyer here and didn't know the answers either!)

Yes, before I wrote my comment, I saw in the FAQ that legal signatures are valid in the US.

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 think you misunderstand the concept of a signature. What matters is that you agreed to something. The signature is just evidence of this agreement.

I accept that I misunderstood the concept, but then you don't need the "signature" at all? Just an email saying "yeah, sounds good. We agree to this." Can we just test that in court?

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

> Just an email saying "yeah, sounds good. We agree to this."

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.

Yes, now my name is in a plaintext file.

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.

Again, it's a matter of evidence. I guess the court would have to get to the truth of the matter, and when they did, the side that was lying would go to jail. IANAL but I'm guessing signature forgery disputes are a very small portion of all corporate lawsuits.

IANAL...

> 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.

IANAL but:

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".

This is a great first step towards better online signing of contracts. I agree with what the FAQ says: "I've always thought that the fake cursive signatures that most electronic signature platforms make you use when e-signing a contract are silly". Quite true. Drawing a cursive signature online is like dancing a waltz in a nightclub. Signing via a simple action like a click / tap / keystroke should be fine.

But I'd expect a tool like this to have mathematically verifiable signatures, for example by using GPG keys, or perhaps by using blockchain. Ideally, the signatures would also be calculated based on a hash of the body of the contract. That would be a real game-changer, it would allow you to prove that a given party signed a given exact version of a contract. Magistrate doesn't appear to have anything like that right now, the signature is literally just the text "/s/ Jane Smith". Unless I'm missing something?

You're exactly right. The signature reflecting some sort of hash of the fully executed document is on the roadmap. There are some nuances around what exactly is fed into the hash. And, there are lots of other great ideas in these comments and outside of them that would make this product better.

I'm going to spend some time reflecting on all of these comments and being deliberate about about what to develop next. Then I'll build it quickly. If you want to know when something comes up, submit your email for updates.

I won't spam you. You'll get emails from me personally and only when there's something interesting to tell you.

I mean, we already literally have verifiable content signing. This is main purpose of GPG isn't it? Why have a line where we pretend someone used a digital pen at all? Just attach the signature?

IMO the problem is that you need a mainstream way to store the keys that even your grandmother could use. Mainstream can’t be expected to manage their GPG keys and create, append and verify signatures manually.

Though maybe in the move to the password less future with WebAuthn integrated into operating systems this may become possible.

This is really really good. If you can build a collaboration ecosystem around this a kind of GitHub meets Seedlegals then you can create a huge amount of value and disrupt an industry.

Where do I invest?

If you're serious, reach out to me at the email in my profile.

Lawyer here. Much like "Smart Contracts" (presently the worst named thing for anything these days), this is that thing where a tech person believes that lawyer problems are like tech problems and they're just not.

Real life lawyer contracts just aren't very much like "code," at all.

Code does exactly what the text says, "perfectly," every time. Therefore, it's important to be succinct and "correct."

Contracts, at best, are the best approximation of what two human beings are agreeing to at any given time -- and here's the important part -- infrequently "do" anything AT ALL; they just kind of shore up what the two people were planning to do anyway.

Contracts are more like a best-guess list of all possible errors and what to do about them when they come up.

Interesting product. Congrats on shipping!

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.

> Disclaimer: I'm a lawyer and software developer.

I'm surprised to see that common misuse (that I'd usually try harder to refrain commenting on) from a lawyer!

This is usually used as a "I'm speaking from this context" instead of a "legal" disclaimer.

Indeed!

Right, but that is absolutely a misuse, since if anything it's the opposite that's meant, it's a 'claimer' - I claim relevant experience or context through being a lawyer and SE.

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.)

You're right. Should've been "disclosure" instead.

This is one of the reasons why lawyers use templates, as a defense against brain farts where we write "disclaimer" instead of "disclosure."

That's right! They often want to integrate with existing processes or products (often Salesforce) to automatically send contracts out for signatures on behalf of the company.

As a Tech founder of a B2B SAAS where we do contracts, I would love to try this!! You are on to something here if you can get this executed well.

This is great - I really hope to see this take hold. I work for a key player in the legal software space, and easily-parsed contracts would be a game-changer for us. Especially in regards to billing reconciliation between two firms, where there can be a lot of back-and-forth over contract terms. Being able to easily parse and present the terms of a contract could change this forever.

I noticed that it seems to be limited to 50 contracts per month currently. Are there plans for larger tiers?

There are! I just had no idea how positive the reception would be. If you're interested in a higher tier, just reach out to the email in my profile and we'll set something up.

I see.

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.

It would be awesome if you used a templating system for the writing process. Then the writers can have templates and just change who ${partyA} is.

That's planned. And it will go further than existing templates where it's just fill in the blank.

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.

It's probably a good idea to implement this with an existing language so that you don't end up making your own programming language. For example you could just make the whole document a JavaScript template string.

This is great! I too have wondered why contracts can't be in plain text since the versioning and back-and-forth between legal and business teams could be handled so much more easily than Word revisions (or worse, PDF comments).

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...

So where is the proof that all parties signed located? On your servers? So do I rely on your company still offering the service if there is a contract dispute 5 years down the line, or how do you proof in court that the contract was signed?

Second question: would you sign ndas since a lot of contracts are confidential?

The proof is in a couple of places, although I will point out that all conventional electronic signature services suffer from similar issues.

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.

The same set of questions can be applied to DocuSign or other centralized e-signature services. The answer to most of those questions would likely be "yes", but more importantly that doesn't seem to stop the viability of this type of service.

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.

> how do you proof in court that the contract was signed?

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.

Yes, but here there is no signed pdf copy. You get issued an email from the server if supposedly everyone clicked a link. So you have the email, but the other party can claim the server was faulty.

I've used eSignatures.io in the past, which uses Markdown for contracts, and found it to be exponentially easier to use than DocuSign, so I appreciate simpler solutions coming into the space.

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.

This is great. Thank you for letting me know about them!

Both of your ideas are on the very near-term feature list.

I appreciate the concept here, but I have to ask: do you have a security page for this that documents the controls in place?

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.

Congrats !! idea is great. I always fret dealing with clients when it comes to legal stuff as I don't charge that much to afford a lawyer. This could be a very helpful tool for small indie developers like me or even the more established ones, who I have seen fight over petty stuff with clients. It would be helpful if one can see few examples or templates. Also for someone who does less than 2 contracts a month, is there a possibility that for extra free , there could be some custom template depending on the situation ?

From the look of it this product is just an API to distribute the contract you already have and collect esignatures--kinda like Docusign, but with text.

Looks awesome! Greetings from another IT-savvy Harry with a law degree :)

I have to say, I've wanted someone to do this for years. Amazing to see it coming about. Imagine if it were possible to describe more and more things the way Creative Commons does?

standard text format for legal pleadings feels like it has more of a value prop

- for litigants, standardizes the production of documents

- for legal researchers, makes it easier to discover / extract what they need (vs current PDF workflow)

- for hosting tools like PACER, makes it easier to index references and preview docs. for courts who have to accept e-file, lets them do more auto linting / checking on filings

- for people in the judge's office, makes it possible to build summarization tools that simplify reading memos etc

This is interesting! I'm going to throw a few questions your way, please feel free to answer as many or few as you'd like. A lot of these are stream of thought things too, so apologies.

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.

I’ve always wondered if contracts themselves couldn’t be expressed in a parsable domain-specific language.

IANAL, but it seems to me that source code and contracts/legislation/policies are similar in many ways: logic, rules, special words with reserved meaning.

The right DSL might go a long way to automating the boring stuff out of law, and serve to highlight the contentious stuff for human judgement.

Spoken language is as close as we currently get to expressing our thoughts in a standardized way.

It’s not a great standard, lots of variation and duplication, and above all undefined. But it’s what we have.

Agreements are but one use case of spoken language. Therefore you’re looking at reinventing language itself.

Not a bad idea at all. I do think we eventually get there. But it may take years and may need more advanced technology like AI. Until then spoken language it is.

This is a neat idea. So is there a repository where the contract is stored, and does every one have read access to it? Does a version control track changes? I do feel you'd have more success with a web app or desktop app.

Great ideas. This is pretty bare bones at this point. Only one person can create the contract and send it for signature. Planned development includes negotiation of contracts using version control.

I couldnt tell what country and thus legal system this was aimed at, so I've assumed this is geared for the US and not European countries and spent like 20seconds on it before coming back to make this comment.

In the FAQs halfway down the page:

> 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).

20 years ago, you could improve a lawyer's contract workflow in three ways:

Make Word load faster.

Make Adobe Acrobat load faster.

Make the printer print faster.

This hasn't changed much since 2002. If you are to reinvent the wheel, you really need to see it turn.

Very nice concept! Bookmarked, wish you the best with this.

Super cool. I want to see more legal tools for developers to improve workflow efficiency. As a developer I'm especially interested in finding free contracts I can use to create agreements with other developers to work on mutually-owned products/businesses together.

Also, 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)

Whats the point of switching from Word to another website. It's just switching one dependency to another dependency, at least it doesnt depend on the cloud.

Reply on news.ycombinator.com