The Aim of the Game

Ask any programmer of any stripe: its difficult to program when you don't have an end goal in mind. If you don't have something you wish to achieve, you are lost. So what we need here is an aim - define what (I think) a document assembly project should hope to achieve. There are two main aims really. And I will address them separately as "Basic Document Assembly" and "Advanced Document Assembly".

Basic Document Assembly

This relates to the approach defined in the Create Simple Documents article. The aim of the game is simple:

• Create a series of questions that are presented to a user that will fill in the majority of "blanks" (answers) in a template.
• Ensure a user must only enter a specific piece of information ONCE.
• Ensure that any areas that you know will not be finalized when the user has finished answering questions should be marked clearly so that the author of the document can go back to these places and dictate or otherwise fill in the necessary content

Pretty simple! At the most basic level, that's all you really need to do. You need to analyse your templates and create an interview process or series of questions to ensure that as much information as possible is entered, and that data re-entry does not occur.

Advanced Document Assembly

This relates closely with the article Design a Document Producing System. The aim is not so far different from what was listed above. In this case, the aim of the game is to:

• Ensure that the templates you are programming contain the majority of language they will ever need to produce. This optional content will come from finalized versions of documents that were previously drafted.
• Ensure that every piece of conditional content has a distinct and exact rule as to why it is or isn't included. In some cases, this will be rules based upon user data entry and other times it will simply be a flat out question, "Do you want to include the clause regarding ...."
• Create an interview process that will ask the user every single piece of information that will be required to produce the majority of documents from the template you are programming.
• Allow for "user defined" sections, where your pre-programmed options aren't going to cut it. For example, you may draft a litigation library that has a whole host of intelligent pleadings in it. No matter how fixed your client works are, there is always going to be 1 in 20 or 1 in 50 matters that doesn't conform, and will need to be hand drafted. This is where the "majority" comes in. You aren't hoping to program every single Statement of Claim under the sun, you are simply aiming for a Statement of Claim that will automatically produce (in final form) the correct document in around 80-90% of cases.

That's it - the aim is simply to collect as much or as little information as you want, but to ensure that any section that ISN'T finalised by your system is marked as such. In many cases, it is just easier to let the users know that the system doesn't finalise anything, which yields little to no proofreading & mark-up benefits. The documents are produced a tad quicker, but once they are produced, they may as well have been hand typed for all the conformity in final product you'll get.

In reality, the only aim of any document assembly process is to isolate the data that goes into a document from the template content itself. Whether that content is conditional, optional, dynamic - whatever - you need to identify that content, allow it to be included by way of rules & conditions, and finally, allow a user to enter the data that will make up those rules.