How we use Git to scale automation of legal documents

Using Git as a version control method for document control and collaboration in the legal industry makes a ton of sense. The current versioning method we are used to is called linear versioning (ex., v1, v2, v3, and so on). The problem that most legal technologists have identified is that linear versioning does not allow multiple parties to simultaneously edit a document because it will create merge conflicts. Linear versioning is fundamentally a turn-based system where only one user can edit a document at a time. Git solves for this with a branch-based versioning framework that allows multiple parties to edit at one time and then merge their edited documents back into the “master” version.

Although Git is the primary version control system used by computer programmers, the legal industry has not adopted it for a variety of reasons. Early pioneers in the Git for legal movement like Simuldocs have resorted to building better products for linear versioning due to this resistance. 

For this reason, we are excited to share an actual, in-production application for Git in legal documents that we developed for our internal use at Athennian to solve issues related to content management in document assembly systems at scale. 

Most law firms and legal departments purchase Athennian because they want to leverage our market-leading document assembly technology. In order to enable our enterprise customers to automate their own set of templates, each customer has their own template administration studio where they can upload and configure their own document templates. 

‍

However, some kinds of templates are centrally administered for all customers. For example, government forms, standard reports, and summary templates are document templates that we centrally manage because all our customers want exactly the same document. 

This dynamic created two challenges. First, how do we manage versions of these standard templates across all client databases? And second, how do we update centralized template resources across a decentralized infrastructure of siloed template administration studios? To illustrate the issue, if we want to update one government form, we would have to upload and configure that template into each of our customer’s template studio. If we have 50 customers in a jurisdiction that uses a particular form, we would upload and configure the same template 50 times. This worked when our customer count was lower. But as we have grown rapidly in recent years, it quickly became unmanageable and clearly would not scale. 

We got to work on the whiteboard and generated a few different concepts of how we could create a system that would scale. We ultimately arrived on using Git as the versioning tool and pipelines for automated deployment to each client. This allows us to create a new branch (version) of a document template in Bitbucket, compare it to the previous version (text redlining) and deploy the new document version automatically. Alongside each template, we include a metadata configuration file, which contains instructions for Athennian to configure things like subtemplates references, pop-up questions, and settings to show the document only in certain workflows or certain jurisdictions. 

With this new process, updating document templates that have sophisticated assembly coding and metadata takes about 2 minutes compared to taking an endless number of hours. In addition to the efficiency, this process also eliminates the headache and risk associated with having a countless number of different template versions. 

As more legal and business documents are being automated in tools, knowledge management is becoming an increasingly important topic for administrators of these systems. 

‍

Hopefully, this article provides legal operations and knowledge management professionals some inspiration for one way use Git to automate the deployment of content across systems.