Documents & Templates - Static, Conditional and Dynamic Content

As you may or may not have noticed, a common theme to my ramblings is planning...knowing what you want...understanding what you are wanting to achieve. You don't just get in a car and start driving, hoping that you get to your destination! You plan it out to ensure you get there in a timely fashion. This article looks at the content of a document or template and how it applies to document assembly to achieve what we want.

Documents, Templates and Content

The aim of document assembly is to create a single template for each document you need to produce and to ensure all questions are asked to allow the template to produce a finalized document. To do this, document assembly takes your precedent documents, combines those precedents that are slight variations of each other and marks the different content that came from each different precedent. The final document assembly system produced will then read the markings, ask a user specific questions so that it can "decide" which of the variations is inserted. While it is not accurate to say a document assembly system will think for you, it is not inaccurate either. It is a process of taking all of the decisions that a lawyer would make in a document, and embedding them into your precedent templates.

For example, you may have three different precedent documents that are used to send to a client a property transfer form to execute. They all largely have the same content with a few minor variations. The first version contains a paragraph confirming that trust monies have been received. The second contains a paragraph advising that trust funds have not been received and the transfer cannot proceed until you have received same. The third is slightly different, advising that their previously supplied documents were executed incorrectly and a new transfer document is enclosed for correct execution.

Under many document production systems, you have these three precedent letters sitting on your network. If your letterhead changes, new legislation comes into effect or any of a host of other factors change, you have three precedents documents to maintain. In addition to this, day to day your users must locate the correct precedent for their purposes or perhaps just create the document from a blank letterhead precedent. Document assembly changes this - instead of three precedents, you have one template, which contains the content from all three precedent documents, with some coding to decide which content is to be included.

Types of Content in Document Assembly Templates

Much like a lawyer will decide what pleadings or contract clauses are appropriate and necessary, programmed documents make similar decisions - because they are modelled on the decisions of your professional staff. Look at the majority of documents you work with from day to day. The content of most documents you look at will fall into 3 major categories:

Static: Boilerplate language that does not change, no matter which client you are drafting the document for. Examples of static content are notices on court documents, required annotative text on property forms and attachments to client care letters. Regardless of who you are drafting a document for, this content is required or considered to be necessary to draft the form correctly.

Conditional: Conditional or optional content is the wording that either appears or does not appear. If it does appear, it may alter slightly depending on the circumstances under which it was included. Examples of conditional content are in everyday letters and documents. If the client has provided money in trust for stamp duty, the letter includes a paragraph confirming receipt. If they have not provided money in trust, a different paragraph is included advising them they must provide for stamp duty before the transfer can proceed.

Dynamic: Content that will change in every draft for every matter. Examples are party names, settlement dates, debt amounts and the like. They are the pieces of information that make each matter unique (but don’t be fooled! The value of the piece of information may be unique, but the way you use that value is not)

The whole concept of document assembly is to identify these three types of content and deal with them appropriately to increase quality and reduce production time. This means that each of these types of content must be dealt with differently to achieve a system that will produce the correct document.

Static Content

Static text will be marked because it is a constant - it is not to be touched, as this content is appropriate and of a high quality for every matter – it applies 100% of the time. That means that static content must be clearly identified so it stays that way: static. It will contain no moveable or variable content, it simply "is".  "Applies 100% of the time" - let me make this absolutely clear, as it has caused me many a headache in the past:

"100%", "always" and "all the time" have literal meanings! A paragraph that appears in 99% of cases does not appear all the time - it appears most of the time. There are very clear lines. Similarly, "never" means "Does not appear. Ever."

Conditional Content

Conditional content will be marked because it needs to change (whether slightly or totally) from matter to matter. In many matters it will be the same, in many others it will be different. It applies some of the time. Higher end document assembly systems are designed not just to "highlight" these areas where content is optional, but also to create that content, fill in the blanks and include the completed content in the finalized document – this is what its all about.

This is a three step process. Firstly, we need to find out from a relevant authority (usually a lawyer who deals with this area of law daily) ALL possible content for this paragraph or phrase - perhaps the three documents we are looking at reflect all content possible...and perhaps not. Either way, we first confirm all possible optional content for this document at this location, then we can then proceed to the second step.

Secondly, we need to devise a question or series of questions that will allow the system to decide which content actually appears in the final document. The template will contain all possible content but will produce a document that contains only the relevant content, based upon a user's answers to these questions. Quite simply, we are combining all the possible permutations into a single document, then presenting an interface for the user to select as appropriate. In this case, we'd probably ask two separate questions: 1) "Have we received trust funds from the client?" and 2) "Are we re-sending these documents due to incorrect execution?". Based upon the answers a user provides, the system will have enough information to decide what wording is produced.

Understanding this concept is critical to good document assembly. Most developers ask questions in such a way that you are requiring the user to know the document content, as a lawyer or paralegal would. An example is "Do you wish to include the paragraph regarding trust funds not having been received?". You are not asking the user a question, you are asking them to include content or not. A good document assembly system should take the 'knowledge requirement' away from the operator. "Has trust money been received?" - the user doens't need to know about what content is included (or not) - they need to be able to answer whether we have trust funds; leave the actual output of that answer to the system - that's what it is there for.

Thirdly, we need to ask any questions that relate to the content chosen, that would not normally appear. For example, if the conditional paragraph referring to re-execution needed to specify the date they erroneously executed the documents – this is an additional date that we'd need to ask whenever the "re-execution" paragraph is chosen.

This is an extremely simple example of document assembly. If it were only useful and able to handle these sorts of simple logical operations, it would not be worth serious amounts of investment. Luckily, this is not the case.

Dynamic Content

The dynamic content needs to be handled differently again. There is always a single golden question to be asked whenever you encounter what appears to be dynamic content: is it truly dynamic? Court pleadings are generally considered to be dynamic but in many cases, they are not. Most certainly, simplistic debt recovery pleadings are rarely dynamic. They may have many options, calculations, pleading types and other questions to be asked, but there are not as many moving parts to the content as may appear at first glance. Another example is leasing. Does each lease need to be hand crafted? In some cases yes, in other cases, no. Many leases can be built to near (if not total) completion by creating a system that stores hundreds of different lease clauses and options and provides the user with an interface to select which are appropriate. Entire sections of possible clauses can be included (or prohibited from being included) based upon any rule you wish – client, lease type, state in which the lease is being drafted etc…

Of course, there are always going to be matters that have sections of documents and templates that are purely dynamic - they must be handcrafted by a knowledgeable and experienced lawyer to suit the matter at hand. However, taking a good hard look at many precedent libraries and repositories, the dynamic content is not as large as may initially be thought. This topic will be covered further in the regular document assembly section.